Re: [Tigervnc-devel] Heads up-- problems with JPEG SIMD library on OS X Leopard and Snow Leopard
On 01/13/2010 01:32 PM, DRC wrote: > Antoine Martin wrote: > >> trunk and 1.0.0 can now build fine, I had to patch this file though (for >> both): >> >> It wouldn't be too hard to hook up a patch phase into the build scripts, >> but it may not be worth it as the new libdrm releases should have some >> form of darwin/osx support included in the future surely? >> > Are you trying to build Xvnc on OS/X? Whatever for? > Mostly to satisfy my curiosity. I'll admit that running xeyes and xclock via VNC on a mac is not particularly interesting! Nonetheless, it mostly builds (it is near the end now, xserver proper - really slow box) and someone may be interested in some of this (or not): 1) Had to add this to libpciaccess to build: #define HTOLE_16(x) htons(x) #define HTOLE_32(x) htonl(x) #define LETOH_16(x) ntohs(x) #define LETOH_32(x) ntohl(x) 2) Mesa grabbed the wrong config, had to force it to use "darwin" Then it failed to find libXt when building libGLwDrawA.o, so I just added "-L../../../../../unix/xorg.build/lib/" Cheers Antoine -- 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
Re: [Tigervnc-devel] Heads up-- problems with JPEG SIMD library on OS X Leopard and Snow Leopard
Antoine Martin wrote: > trunk and 1.0.0 can now build fine, I had to patch this file though (for > both): > > It wouldn't be too hard to hook up a patch phase into the build scripts, > but it may not be worth it as the new libdrm releases should have some > form of darwin/osx support included in the future surely? Are you trying to build Xvnc on OS/X? Whatever for? -- 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
Re: [Tigervnc-devel] Heads up-- problems with JPEG SIMD library on OS X Leopard and Snow Leopard
[snip]
I have not seen the
problem with fls() that you describe above. Under what
circumstances do
you see that?
>>> Just a normal build (as above): cd tigervnc-1.0.0/unix&& ./configure&&
>>> make
>>>
>>> Not sure how to build from svn as there is no "./configure" script in
>>> there and automake barfs at me with all sorts of errors on osx.
>>> How do you create a full release tigervnc-X.X.X.tar from an svn tree?
>> In the 1.0 branch, you do
>>
>> cd unix
>> autoreconf -fiv
>> configure {configure arguments}
>> make
>>
>> in trunk, you leave out the 'cd unix' part. The trunk also has
>> convenience scripts under release/ that you can use.
trunk and 1.0.0 can now build fine, I had to patch this file though (for
both):
--- a/unix/xorg/libdrm-2.4.0/shared-core/drm.h2010-01-12
15:04:21.0 -0500
+++ b/unix/xorg/libdrm-2.4.0/shared-core/drm.h2010-01-12
15:04:30.0 -0500
@@ -79,7 +79,7 @@
#define DRM_IOC_WRITE_IOC_WRITE
#define DRM_IOC_READWRITE_IOC_READ|_IOC_WRITE
#define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
-#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
defined(__NetBSD__) || defined(__OpenBSD__) || defined(__DragonFly__)
+#else
#include
#define DRM_IOCTL_NR(n)((n) & 0xff)
#define DRM_IOC_VOIDIOC_VOID
Xelabos-Mac-Pro-2:shared-core MacAdmin$ pwd
/Users/MacAdmin/tigervnc/unix/xorg/libdrm-2.4.0/shared-core
To avoid this error:
gcc -DHAVE_CONFIG_H -I. -I../shared-core -g -O2 -MT xf86drm.lo -MD -MP
-MF .deps/xf86drm.Tpo -c xf86drm.c -fno-common -DPIC -o .libs/xf86drm.o
xf86drm.c: In function 'drmCommandRead':
xf86drm.c:2311: error: 'DRM_IOC_READ' undeclared (first use in this
function)
xf86drm.c:2311: error: (Each undeclared identifier is reported only once
xf86drm.c:2311: error: for each function it appears in.)
xf86drm.c: In function 'drmCommandWrite':
xf86drm.c:2340: error: 'DRM_IOC_WRITE' undeclared (first use in this
function)
xf86drm.c: In function 'drmCommandWriteRead':
xf86drm.c:2369: error: 'DRM_IOC_READ' undeclared (first use in this
function)
xf86drm.c:2369: error: 'DRM_IOC_WRITE' undeclared (first use in this
function)
make[3]: *** [xf86drm.lo] Error 1
It wouldn't be too hard to hook up a patch phase into the build scripts,
but it may not be worth it as the new libdrm releases should have some
form of darwin/osx support included in the future surely?
Antoine
--
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
Re: [Tigervnc-devel] Heads up-- problems with JPEG SIMD library on OS X Leopard and Snow Leopard
On 01/12/2010 12:56 PM, DRC wrote:
> Antoine Martin wrote:
>
>>> How is this related? The bug my E-Mail was referring to was in the OS X
>>> linker, and the patch that worked around it in the TigerVNC build has
>>> been checked in to trunk for quite some time.
>>>
>> Was this before or after 1.0 was released?
>> I was building from the tigervnc-1.0.0.tar and I still get this
>> alignment issue:
>>
>> ld: in ./.libs/libjpeg.a(jiss2int.o), malformed .o file, symbol
>> _jconst_idct_islow_sse2 with address 0x969 is not with section 2
>> (__DATA,__const) address range of 0x970 to 0xA20
>>
> After. I thought that the issue only affected 64-bit builds, but now I
> see that it affects 32-bit builds as well, if NASM 2.07 is used. Thus,
> I created the attached patch which should be applied against the 1.0
> branch to allow it to be built with NASM 2.07 or later on Mac. This is
> a subset of r3910.
>
> It is also necessary to apply r3903 (the fls() rename patch) from trunk
> to get the 1.0 branch to build on OS/X 10.5 or later.
>
Works for me. Thank you very much!
>>>I have not seen the
>>> problem with fls() that you describe above. Under what circumstances do
>>> you see that?
>>>
>> Just a normal build (as above): cd tigervnc-1.0.0/unix&& ./configure&&
>> make
>>
>> Not sure how to build from svn as there is no "./configure" script in
>> there and automake barfs at me with all sorts of errors on osx.
>> How do you create a full release tigervnc-X.X.X.tar from an svn tree?
>>
> In the 1.0 branch, you do
>
> cd unix
> autoreconf -fiv
> configure {configure arguments}
> make
>
> in trunk, you leave out the 'cd unix' part. The trunk also has
> convenience scripts under release/ that you can use.
>
Hah, yes... I was looking for release scripts, and didn't think of
looking in 'release'...
Will now look for a rock to crawl under ;)
[snip]
Thanks
Antoine
--
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
Re: [Tigervnc-devel] Heads up-- problems with JPEG SIMD library on OS X Leopard and Snow Leopard
Antoine Martin wrote:
>> How is this related? The bug my E-Mail was referring to was in the OS X
>> linker, and the patch that worked around it in the TigerVNC build has
>> been checked in to trunk for quite some time.
> Was this before or after 1.0 was released?
> I was building from the tigervnc-1.0.0.tar and I still get this
> alignment issue:
>
> ld: in ./.libs/libjpeg.a(jiss2int.o), malformed .o file, symbol
> _jconst_idct_islow_sse2 with address 0x969 is not with section 2
> (__DATA,__const) address range of 0x970 to 0xA20
After. I thought that the issue only affected 64-bit builds, but now I
see that it affects 32-bit builds as well, if NASM 2.07 is used. Thus,
I created the attached patch which should be applied against the 1.0
branch to allow it to be built with NASM 2.07 or later on Mac. This is
a subset of r3910.
It is also necessary to apply r3903 (the fls() rename patch) from trunk
to get the 1.0 branch to build on OS/X 10.5 or later.
>> I have not seen the
>> problem with fls() that you describe above. Under what circumstances do
>> you see that?
> Just a normal build (as above): cd tigervnc-1.0.0/unix && ./configure &&
> make
>
> Not sure how to build from svn as there is no "./configure" script in
> there and automake barfs at me with all sorts of errors on osx.
> How do you create a full release tigervnc-X.X.X.tar from an svn tree?
In the 1.0 branch, you do
cd unix
autoreconf -fiv
configure {configure arguments}
make
in trunk, you leave out the 'cd unix' part. The trunk also has
convenience scripts under release/ that you can use.
>> I've tried 'port upgrade nasm' and also doing a clean
>> uninstall/reinstall of nasm, but it still gives me 2.05.01.
>>
> I'm new to macports, I'll assume you've run "port sync" recently and
> that your $PATH is correct.
Yes, port sync did the trick. Thanks for the tip.
> PS: this message is off-list, is this intentional?
The list is configured so that you have to Reply-All to get the
replies to go back to the list, and sometimes I forget to do so.
Index: common/jpeg/simd/jimmxfst.asm
===
--- common/jpeg/simd/jimmxfst.asm (revision 3945)
+++ common/jpeg/simd/jimmxfst.asm (working copy)
@@ -495,3 +495,6 @@
pop ebp
ret
+; For some reason, the OS X linker does not honor the request to align the
+; segment unless we do this.
+ align 16
Index: common/jpeg/simd/jcqntmmx.asm
===
--- common/jpeg/simd/jcqntmmx.asm (revision 3945)
+++ common/jpeg/simd/jcqntmmx.asm (working copy)
@@ -269,3 +269,6 @@
pop ebp
ret
+; For some reason, the OS X linker does not honor the request to align the
+; segment unless we do this.
+ align 16
Index: common/jpeg/simd/jfss2fst.asm
===
--- common/jpeg/simd/jfss2fst.asm (revision 3945)
+++ common/jpeg/simd/jfss2fst.asm (working copy)
@@ -399,3 +399,6 @@
pop ebp
ret
+; For some reason, the OS X linker does not honor the request to align the
+; segment unless we do this.
+ align 16
Index: common/jpeg/simd/jiss2fst.asm
===
--- common/jpeg/simd/jiss2fst.asm (revision 3945)
+++ common/jpeg/simd/jiss2fst.asm (working copy)
@@ -497,3 +497,6 @@
pop ebp
ret
+; For some reason, the OS X linker does not honor the request to align the
+; segment unless we do this.
+ align 16
Index: common/jpeg/simd/jf3dnflt.asm
===
--- common/jpeg/simd/jf3dnflt.asm (revision 3945)
+++ common/jpeg/simd/jf3dnflt.asm (working copy)
@@ -315,3 +315,6 @@
pop ebp
ret
+; For some reason, the OS X linker does not honor the request to align the
+; segment unless we do this.
+ align 16
Index: common/jpeg/simd/ji3dnflt.asm
===
--- common/jpeg/simd/ji3dnflt.asm (revision 3945)
+++ common/jpeg/simd/ji3dnflt.asm (working copy)
@@ -447,3 +447,6 @@
pop ebp
ret
+; For some reason, the OS X linker does not honor the request to align the
+; segment unless we do this.
+ align 16
Index: common/jpeg/simd/jsimdcpu.asm
===
--- common/jpeg/simd/jsimdcpu.asm (revision 3945)
+++ common/jpeg/simd/jsimdcpu.asm (working copy)
@@ -100,3 +100,6 @@
pop ebx
ret
+; For some reason, the OS X linker does not honor the request to align the
+; segment unless we do this.
+ align 16
Index: common/jpeg/simd/jcsammmx.asm
===
--- common/jpeg/simd/jcsammmx.asm (revision 3945)
+++ common/jpe
Re: [Tigervnc-devel] Heads up-- problems with JPEG SIMD library on OS X Leopard and Snow Leopard
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
Re: [Tigervnc-devel] Heads up-- problems with JPEG SIMD library on OS X Leopard and Snow Leopard
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
Re: [Tigervnc-devel] Heads up-- problems with JPEG SIMD library on OS X Leopard and Snow Leopard
Adam Tkac wrote: > Hm, this is a nasty problem and finding the solution will be even nastier. > > I have no experience with Xcode but I would recommend to build library > without all optimizations (disable both compiler and nasm > optimizations) and check if it is still broken. > Yep. Still broken. > If yes then I don't know better approach than compile libjpeg > with no optimizations via old and new Xcode, disassemble affected > parts of code (probably simd/*.o object files) and try to figure > differences and isolate what exactly is broken. I can help you (hopefully) > if you upload old/new files somewhere. > OK, that sounds like a reasonable approach. > Hm, PIC code shouln't be needed at all in our project because we are > shipping no libraries. In GNU build chain it is possible to disable > PIC generation with `--disable-shared` configure flag. Is it possible > to disable PIC code in Xcode as well? > 'configure --without-pic' prevents PIC from being defined in NASM, but jsimdext.inc overrides this for Mac platforms. I gather that PIC generation is the default on Mac. If I manually disable it in jsimdext.inc, the resulting binary seg faults. -- Come build with us! The BlackBerry® 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/devconf ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Heads up-- problems with JPEG SIMD library on OS X Leopard and Snow Leopard
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. Hm, this is a nasty problem and finding the solution will be even nastier. I have no experience with Xcode but I would recommend to build library without all optimizations (disable both compiler and nasm optimizations) and check if it is still broken. If yes then I don't know better approach than compile libjpeg with no optimizations via old and new Xcode, disassemble affected parts of code (probably simd/*.o object files) and try to figure differences and isolate what exactly is broken. I can help you (hopefully) if you upload old/new files somewhere. > 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 I'm quite sure you are right. > 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. Hm, PIC code shouln't be needed at all in our project because we are shipping no libraries. In GNU build chain it is possible to disable PIC generation with `--disable-shared` configure flag. Is it possible to disable PIC code in Xcode as well? Regards, Adam -- Adam Tkac, Red Hat, Inc. -- Come build with us! The BlackBerry® 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/devconf ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
