Does anyone have a working copy of KLayout for Yosemite?
I just upgraded my primary machine from 10.9.2 to 10.10.1, and found my 0.23.3 version of KLayout that I compiled on 10.9.2 does not work anymore . I've tried to recompile but it fails. I've also gone back to the 0.23.2 version on the download page, but it doesn't work either. Any suggestions?
Thanks.
Comments
Hi,
still lacking suitable Mac hardware I do not actively support MacOS. So I can just guess. Why won't it compile? Any error messages?
Matthias
I do have a Macbook running on Yosemite. KLayout is running fine on it. I just used the available dmg file in the download section. The release is 0.24 I guess. Have you tried to use the dmg file instead of compiling everything from the source?
Regards
As for the compile, I was foolish to think it would work. The new machine has QT5 and XCode 6.1.1 loaded. My old script was expecting QT4 and XCode 5.x something. I just ran it without looking at it.
Have you ever compiled with QT5? Suggestions?
I am not sure about QT5, maybe matthias can comment on that. But for my own case I do have both libraries on my Macbook QT4 and QT5. I am quite sure QT4 is required to make it working. I do also have Darwin 14.0.0 system. I also have Xcode installed with the same 6.1.1 version. Again I have used the binary packaged to make it working but if you need more help I can try the compile procedure on my side. Just let me know? I can also make it step by step following your approach to see where is the blocking point?
Kind regards
Hello,
Qt5 is somewhat, but not sufficiently compatible with Qt4, so you can't compile KLayout with Qt5. Sorry.
Matthias
I confirm compilation process is failing.
I have downloaded the last source package named: klayout-r2594.tar.gz
I have tried compiling it with the following command on Yosemite:
./build.sh -platform mac-leopard-gcc-release -qtbin /Developer/Tools/Qt -qtlib /Developer/Tools/Qt -qtlib /usr/lib -pylib /Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib
during the compilation i have got the following error?
gtfUiDialog_moc.cc:11:2: error: "The header file 'gtfUiDialog.h' doesn't include <QObject>."
#error "The header file 'gtfUiDialog.h' doesn't include <QObject>."
this is coming after:
gcc -DQT_THREAD_SUPPORT -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -DHAVE_PYTHON -DHAVE_PYTHON_VERSION_CODE= -DHAVE_RUBY -DHAVE_RUBY_VERSION_CODE=20000 -MM -MG /Users/psalome/Documents/tar_files/KLAYOUT/klayout-r2594/src/tlDeferredExecution.cc -I/Users/psalome/Documents/tar_files/KLAYOUT/klayout-r2594/src -I/Users/psalome/Documents/tar_files/KLAYOUT/klayout-r2594/src -I. -I/usr/include/qt4 -FQtGui -FQtCore -FQtXML -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/include/ruby-2.0.0 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/include/ruby-2.0.0/universal-darwin14 >tlDeferredExecution.d || (rm -rf tlDeferredExecution.d; exit 1)
/Developer/Tools/Qt/moc -o gtfUiDialog_moc.cc /Users/psalome/Documents/tar_files/KLAYOUT/klayout-r2594/src/gtfUiDialog.h
gcc -DQT_THREAD_SUPPORT -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -DHAVE_PYTHON -DHAVE_PYTHON_VERSION_CODE= -DHAVE_RUBY -DHAVE_RUBY_VERSION_CODE=20000 -MM -MG gtfUiDialog_moc.cc -I/Users/psalome/Documents/tar_files/KLAYOUT/klayout-r2594/src -I/Users/psalome/Documents/tar_files/KLAYOUT/klayout-r2594/src -I. -I/usr/include/qt4 -FQtGui -FQtCore -FQtXML -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/include/ruby-2.0.0 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/include/ruby-2.0.0/universal-darwin14 >gtfUiDialog.dm || (rm -rf gtfUiDialog.dm; exit 1)
Do you think there is an issue with the header file?
Kind regards
Hi psalome,
That looks like a mixing of Qt4 and 5 - maybe moc is taken from Qt5 while the includes come from Qt4?
Matthias
Thanks for your feedback. I tried to make it myself from moc. Here is the result:
/****************************************************************************
** Meta object code from reading C++ file 'gtfUiDialog.h'
**
** Created by: The Qt Meta Object Compiler version 63 (Qt 4.8.5)
**
** WARNING! All changes made in this file will be lost!
*****************************************************************************/
#include "gtfUiDialog.h"
#if !defined(Q_MOC_OUTPUT_REVISION)
#error "The header file 'gtfUiDialog.h' doesn't include <QObject>."
#elif Q_MOC_OUTPUT_REVISION != 63
#error "This file was generated using the moc from 4.8.5. It"
#error "cannot be used with the include files from this version of Qt."
#error "(The moc has changed too much.)"
#endif
Sounds like I am not running the right QT4 version. Do you agree? Which version do I need to install to make it working?
Kind regards
Pascal
Hi Pascal,
no, MOC is 4.8.5 which is still Qt4, so that is fine. Maybe it's the other way round and headers come from Qt5 ... I see that there are many -I statements, so maybe one of them leads to Qt headers too. It'd difficult to tell from my perspective. Anybody having a better idea?
Matthias
A binary package for MacOS 10.10.1, Yosemite, is available on trial basis today (2015-01-18):
Regards
Kazzz
thanks I will try it. Can you please shortly describe the procedure to make it working?
Regards
Pascal
I have installed the new binary package easily and it works fine.
Thanks again
Pascal
Hi Pascal,
Thank you for testing the package, which I've made for the first time!
Glad to hear that the binary package works fine.
Regarding your query above, please refer to my memo below.
Hope this also helps you.
Regards,
Kazzz
thanks a lot. From your post I just realized my QT4 install was screwed up by QT5 install (just as Matthias mentioned earlier !!!!). I have reinstalled QT4 using macport and keep standard install for QT5. I tried the same procedure than you for building and it works. In fact I get exactly the same error: see here below
------------------------
g++ -o strm2gds strm2gds.o libklayout.so /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/libruby.2.0.0.dylib -L/opt/local/lib -F/opt/local/lib -framework QtGui -framework QtXML -framework QtCore -framework QtNetwork -framework QtSql -framework QtDesigner -lstdc++ -lz
Undefined symbols for architecture x86_64:
"vtable for db::GDS2Writer", referenced from:
_main in strm2gds.o
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [strm2gds] Error 1
make: *** [all] Error 1
-------------------------------------------------------------------------------
thanks again
kind regards
Pascal
We do have issue while compiling with Yosemite with the file name str2gds.cc file.
The issue seems coming from the line:
tl::InputStream stream (infile);
The definition of infile does not match the constructor definition ( if I am understanding it correctly).
Definition is
tl::InputStream stream (infile);
Do you see any turn around to this problem?
Kind regards
Pascal
Hi Pascal,
the strm2gds target is an optional test utility - if you don't need it you can skip it.
The message basically says that the vtable (which is part of the internals of the compiler's layout of the class) is missing, not the constructor. Apparently that vtable is not exported from the libklayout.so object.
I don't observe that issue on Linux. Maybe there is a substantial difference between MacOS and Linux linker implementations?
Matthias
Hello Pascal,
I think I've found the root cause of the linker error we faced.
The code block below is a patch.
You may apply this patch or manually edit "dbGDS2Writer.cc"
to remove 5 "inline" keywords.
By applying the patch, I could successfully rebuild 0.23.9 on both
(1) Mac 10.10.1 Yosemite
and
(2) Ubuntu Linux 12.04 LTS (64-bit)
including "str*" utility tools.
One minor problem was found in "build.sh" that calls "klayout"
with "-v" and "-h" options at the end.
In Mac environment, the path to "klayout" is not correct.
Since this is a minor problem, I may able to modify "build.sh"
so that it gracefully ends in Mac environment, too.
This patch will be tested and sent to Matthias for future release.
With warm regards,
Kazzz
Thanks for this valuable input. I was working myself on that subject too. I was also able to compile everything but in a different way than you. I only changed the Makefile.rule in order to link manually the failing library. I will try your input but I'd like to understand why on os x the link is not done properly. I will continue searching and come back to you. I wonder if the library is done properly on os x.
Kind regards
Pascal
Thanks, Kazzz. The Linux linker will emit Symbol definitions for inlined Functions too. Apparently the Mac Linker doesn't. I'll check whether removing the inline keyword has a performance impact and remove it if not.
Best regards,
Matthias
Hello Matthias,
I've found that the 21 *.cc files listed below contain the "inline" function-specifier.
I've removed all and rebuilt from scratch on OSX Yosemite.
Building was successful as expected.
As you pointed out, performance is the main concern.
Please let us know about it once you got some views.
Warm regards,
Kazzz
The other turn around would be to change the Makefile.body to insert dbGDS2Writer.o as a dependency for strm2gds and strmclip rules. This will make something like this:
strmclip: strmclip.o dbGDS2Writer.o $(LIBKLAYOUT)
$(LINK) $(LOPT) $@ $+ $(ALL_LIBS) $(LIBS_EXE)
This will not change anything to the performance and compile nicely on Yosemite.
Kind regards
It sounds like compiling a stable release on Yosemite -osX is now solved by considering either way described here above. I start looking into development release. Starting from r2510 to r2631, I got the same error listed below:
src/gsiTypes.h:776:7: error: no matching constructor for initialization of 'gsi::ArgSpecBase'
: ArgSpecBase (other)
src/gsiTypes.h:713:19: note: candidate constructor (the implicit copy constructor) not viable: cannot convert argument of
incomplete type 'const ArgSpec<void>' to 'const gsi::ArgSpecBase'
class KLAYOUT_DLL ArgSpecBase
^
src/gsiTypes.h:720:3: note: candidate constructor not viable: cannot convert argument of incomplete type
'const ArgSpec<void>' to 'const std::string' (aka 'const basic_string<char, char_traits<char>, allocator<char> >')
ArgSpecBase (const std::string &name)
^
src/gsiTypes.h:716:3: note: candidate constructor not viable: requires 0 arguments, but 1 was provided
ArgSpecBase ()
^
src/gsiTypes.h:752:3: note: candidate constructor not viable: requires at least 2 arguments, but 1 was provided
ArgSpecBase (const std::string &name, bool has_default, const std::string &init_doc = std::string ())
Do you think the issue is quite similar to the previous case?
Kind regards
Hi all,
thanks for taking care of that!
I don't think the inline keyword is an issue, but it will hide the implementation in the case of the GDS reader.
The issue mentioned in the last post are related to the clang toolchain. They make sense and they are fixed already, but being found in the Bangalore area currently I have trouble hitting the "upload snapshot" button on my Munich system right now.
See you later,
Matthias
I'd like to keep on progressing on the development version for OS X if possible.
Would it be possible for you to upload the corrected version of the soft ?
I will investigate on the python integration for MAC.
kind regards
The Python integration was a snapshot of a fairly stable version. I'll try to provide a new one if possible, but I have to achieve some stability in the development branch first.
Matthias
Pascal
Hi there,
I have found problems running DRC in KLayout for the Mac and have tried to build KLayout from source using the instructions on this page.
At first I had a problem in that the build script seems to be looking in the wrong place for the "QtGui" framework - or alternatively Mac Ports is installing the framework in the wrong place.
I managed to fix this by creating a whole bunch of symbolic links from
/opt/local/Library/Frameworks
to/opt/local/lib
.Having done this I can build KLayout (albeit crashing on strm2gds as described above).
However, when I run the tool and load some layout, it displays incorrectly. Parts of the layout are missing and other parts of the layout appear to be in the wrong location - and then disappear when one zooms in.
Has anyone else experienced this problem? If so can you give me a clue as to what's going wrong?
Here's some info on my setup:
BTW: Is anyone else having problems running DRC on MacOS KLayout?
Hello,
I have faced a similar problem while building the latest Mac binary package
"klayout-0.23.11-MacOSX-Yosemite-1-Qt487mp.dmg.bz2".
Please note that the whole works have been done on OSX 10.10.3.
Hope this comment will help you.
Kazzz
(1) My setup is as below:
(2) I have modified "build.sh"
(3) I have newly created "Makefile.conf.mac-yosemite-gcc-release" under "config" directory.
(*) The executable links libraries as below.
Hello,
One more comment.
I have not run DRC but found another issue while browsing a GDS2 file.
After several trials, I concluded that the cause was
"too aggressive optimization" with "-O3" in CXXOPT macro, that is compiler issue.
Hence, in "Makefile.conf.mac-yosemite-gcc-release", this has been changed to
CXXOPT=-c -O2 -m64 -o
The latest Mac binary package "klayout-0.23.11-MacOSX-Yosemite-1-Qt487mp.dmg.bz2"
has incorporated this change.
This version might resolve the DRC issue you are facing.
Kazzz