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" 

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 
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.


> 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
> 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
Tigervnc-devel mailing list

Reply via email to