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
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
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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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
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 BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
