Build error on Mac 10.5.8

Comments

• Matthias

  February 2011 edited November -1

  Hi Jimmy,

  I am not quite familiar with MacOS builds (I don't make the MacOS binaries myself), but I found one post which describes a similar problem here:

  http://www.cocoaforge.com/viewtopic.php?f=6&t=21261

  Frankly I don't quite understand what the message is. They mention a bug in Xcode 3.2.

  You also mentioned that is working some versions ago. Maybe it's possible to take the config tree and build script from that version.

  Is there anybody else who could help?

  Best regards,

  Matthias
• jimmy

  February 2011 edited November -1

  After looking around for a while, it seems those errors are due to the newer Qt binaries which were compiled on Mac 10.6, you apparently can't use them to build things from 10.5. I reverted back to Qt 4.5.2. Now I get a different error:
  
  Undefined symbols:
  "QFrame::QFrame(QWidget*, char const*, QFlags<Qt::WindowType>)", referenced from:
  ....
  etc...
  
  I also tried compiling version 0.20.2, since that's the one I successfully built before, but it gives the same error now. So there must be something messed up in my Qt and/or Xcode installation. ?
• Matthias

  February 2011 edited November -1

  Hi Jimmy,

  the QFrame constructor mentioned in the error message is a special one which is only provided if the code is compiled with -DQT3_SUPPORT (which is the case) and the Qt library is built with Qt3 support. Usually that is the case but depending on the origin of your library, that feature may have been switched off.

  BTW: for the next major release I have removed all Qt3 dependencies so Qt3 support is no longer required. However that version is far from being released yet.

  Best regards,

  Matthias
• jimmy

  February 2011 edited November -1

  Matthias,
  Thanks for the help! There are two binary packages for Qt on Mac, a Carbon and Cocoa. The Cocoa one apparently does not have the Qt3Support library included. I installed the carbon version and it builds and runs ok.
  
  However (sorry to keep bothering you), when I try to open an existing GDS, which I saved using a prior version, I get the error:
  HEADER record expected (position=600, record number=0, cell=)
  
  If I open a GDS saved with this version:
  Unexpected end-of-file (position=4, record number=0, cell=)
  
  Saving seems to work ok, because I can open the saved GDS in the 0.20.2 version (which I just rebuilt).
• Matthias

  February 2011 edited November -1

  Hi Jimmy,

  that is really weired. There should not be any difference in GDS files saved by this or other versions.

  The error message indicates that there is something very basic wrong, like something with the fopen function.

  Are you able to open the test files provided in the testdata directory? It would be interesting to know whether you can open oasis or gds2_txt files.

  Best regards,

  Matthias
• jimmy

  February 2011 edited November -1

  Nope, the GDS files in testdata do the same thing. The oasis and gds2_txt files give the error: "Stream has unknown format".
  
  Something must have changed between 0.20.2 and 0.21 that broke it, since I can build and run 0.20.2 fine, but the errors show up on 0.21. This is really strange....
• Matthias

  February 2011 edited November -1

  Hi Jimmy,

  One thing that has changed is the handling of UTF8 encoding locales. But that should make it better, not worse. In the case of GDS files, the reader uses the zlib which I assume is active in your case. I am not aware that zlib is encoding sensitive, especially since the file is opened in binary mode, but maybe it's worth a try to do the following:

  • Open a shell
  • Set the locale to "C": export LANG=C
  • The "locale" command now should indicate that all locales are "C"
  • Run KLayout from the command line

  Best regards,

  Matthias
• jimmy

  February 2011 edited November -1

  Changing LANG=C had no effect. The locale command now produces:
  LANG="C"
  LC_COLLATE="C"
  LC_CTYPE="C"
  LC_MESSAGES="C"
  LC_MONETARY="C"
  LC_NUMERIC="C"
  LC_TIME="C"
  LC_ALL="C"
• jimmy

  February 2011 edited November -1

  Ok, I saw that Mac has its own zlib preinstalled, so on a whim I removed the dependency on the zlib in src/contrib and let it find the built-in one from usr/include. (Adding -lz to the LIBS in the Mac config file so the linker finds it too). Now everything works!
  
  I don't know what the difference is between the two zlibs, or what other repercussions this might have, but it seems to be working this way.
• Matthias

  February 2011 edited February 2011

  Hi Jimmy,

  that is very good input. Thanks for the analysis.

  In fact, you're right. There is something different with respect to the zlib. For 0.21 I was including a copy of the code (zlib 1.2.5). This way it was much more convenient to build on Windows. Apparently there is something wrong with that copy for MacOS 10.5.8 or with my build settings. On 10.6. it seems to work.

  As you mentioned for 10.5.8 or maybe MacOS in general, the best solution is to revert to the zlib provided with the system. I'd do it like this:

  From src/Makefile.body disable line 483 (delete or comment):

  # include $(SOURCE)/contrib/zlib/Makefile.body
  

  In config/Makefile.conf.mac-leopard-gcc-release add -lz to line 30:

  LIBS=-L$(QTLIB) -framework QtGui -framework QtXML -framework QtCore -lstdc++ -lz
  

  I provided this description for others who may have the same problem.

  Thanks and best regards,

  Matthias