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
