The problem has been isolated and worked around. The issue is that the OS X linker doesn't seem to honor the request to align code segments to 16-byte boundaries. This has been a problem all along, but for some reason, when using the OS X 10.4 linker, the problem somehow escaped detection. The workaround, which I found by reading this page:
http://www.nabble.com/--nasm-Bugs-1871199---Mac-OS-X-%28Mach-O%29-misaligned-data-td22143305.html was to add an explicit "align 16" directive at the end of every code segment. NASM 2.07 apparently includes a more robust mechanism for detecting this problem, which is why it was giving me those error messages. Earlier versions of NASM were apparently just failing silently, which is why I got data errors in the JPEG stream. It now works fine using the default nasm version installed with Xcode 3.2 (NASM 0.98.4.) Note that on Snow Leopard, Xcode will try to build a 64-bit version of TigerVNC by default unless you explicitly pass an argument of -m32 to the compiler and linker: configure CFLAGS='-O3 -m32' CXXFLAGS='-O3 -m32' LDFLAGS=-m32 You can now build a 64-bit version as well, though, if that's what you want. Here's the formula: configure --host=x86_64-apple-darwin10.0.0 CFLAGS='-O3' CXXFLAGS='-O3' NASM={path to NASM 2.07 or later} 64-bit builds on Darwin require NASM 2.07 or later. I had to build NASM 2.07 from source because it's too new to have made it into MacPorts yet. If you want to build a backward compatible version of TigerVNC that works on OS X 10.4 Tiger, the magic trick is: configure --x-libraries=/usr/X11R6/lib/ CFLAGS='-isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -O3 -m32' CXXFLAGS='-isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -O3 -m32' LDFLAGS='-isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -m32' CPPFLAGS='-isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4' CC=gcc-4.0 CXX=g++-4.0 CPP=cpp-4.0 DRC Adam Tkac wrote: > On Thu, Oct 01, 2009 at 11:49:50PM -0500, DRC wrote: > >> I've uncovered a pretty serious problem with libjpeg/SIMD whenever it is >> built with Xcode 3.x on OS X 10.5 or 10.6. It basically generates a >> corrupted JPEG stream. This problem occurs only with the SIMD >> extensions enabled, but it also occurs on older revisions of the library >> (prior to any modifications I made.) Curiously, if I build on an older >> system running 10.4 and Xcode 2.5 and bring the binary over to the 10.6 >> system, everything works fine. It's just the act of building on 10.6 >> with Xcode 3.2 or 10.5 using Xcode 3.1 that causes issues. >> >> I've tried building the code both with and without PIC, using the 10.4, >> 10.5, and 10.6 compatibility SDK's, using NASM 0.98, 2.05.01, and 2.07. >> Curiously, with NASM 2.07, it doesn't build at all, giving me the >> following error: >> >> ld: in ./.libs/libjpeg.a(jcsammmx.o), malformed .o file, symbol >> const_base with address 0x1B4 is not with section 2 (__DATA,__const) >> address range of 0x1C0 to 0x1C0 >> >> I suspect the latter may be related to this NASM bug: >> >> http://www.nabble.com/--nasm-Bugs-2840300---Macho-alignment-broken-td25044061.html >> >> However, the more general problem is, I suspect, related to PIC >> generation. I'm not quite sure what may have changed about this in >> Xcode 3.x vs. 2.5, but whatever it was, it seems to have broken our >> build. Hoping someone might have any ideas about other things to try. >> ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
