On 10/08/2009 04:59 PM, DRC wrote: > 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. Have you got a patch that does this? Is this still needed?
You may want to merge this rather simple fix: I had to rename the "fls" function: libtool: compile: gcc -DHAVE_CONFIG_H -I. -O3 -m32 -MT jcdctmgr.lo -MD -MP -MF .deps/jcdctmgr.Tpo -c jcdctmgr.c -fno-common -DPIC -o .libs/jcdctmgr.o jcdctmgr.c:77: error: conflicting types for 'fls' /usr/include/string.h:123: error: previous declaration of 'fls' was here make[5]: *** [jcdctmgr.lo] Error 1 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. > FYI: macports now includes 2.07 by default. Thanks Antoine > 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. >>> >>> ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel