On Mar 21, 2008, at 12:56 PM, Matthias Ringwald wrote: > hi > > as libxine in fink is quite outdated, I tried the latest releases, had > to fix a display bug for powerpc (in 1.1.9) and then stumbled upon a > compiler/linker issue with XCode 3.0 on Leopard for all libxine > versions. > > > The story is this: libxine builds and links against static libraries > of ffmpeg. ffmpeg uses platform dependent asm code for maximum > performance. this asm code also uses absoute adressing modes on 386-32 > (it uses relative addressing for x86-64). libxine itself is used as a > shared library e.g. in Perian, VLC or in my libxine java bindings > (libxine-java.net.sf). But... the linker of XCode (ld64-77) does not > want to build a shared library if the object files contain absolute > addressing (relocation addresses). > > Note: this problem only shows up on i386-32 when using XCode 3.0... > which is the default resp. required to use Fink on Leopard if I'm not > wrong. xine should compile with XCode 2.5 and it also compiles with > XCode 3.1 from the iPhone SDK. > > How can libxine be packaged? Is there support Fink to request (or > reject) a particular linker version? > > What are other projects doing? > - MPlayer builds an application, so the linker does not complain > - VLC -- I forgot what they did, but it did not solve the problem > - MacPorts is disabling the MMX optimization in ffmpeg before they > link xine against it. > - Perian fixed parts of ffmpeg's assembly code to use relative > addressing and build the static libraries without the -mdynamic-no-pic > flag > > > Discussion on the ffmpeg devel list suggest they are not going to use > relative addressing in the assembly code for the whole library. Also > someone mentioned "... that PIC/i386 is slow..". I cannot comment on > that, I had enough trouble to understand Perian's fix. > > > Disabling MMX support generally or only on XCode 3.0 Intel i386-32 > systems does not look like a good idea. So, stopping the build with a > warning "XCode 3.0 sucks, get the iPhone SDK to compile libxine!" > seams like the best approach - but it's not convincing, is it? > > Any ideas? > > Cheers, > Matthias Ringwald > >
We do have an "xcode" virtual package, so one could spell out a versioned BuildDepend on that. On the other hand, I think people have reported other problems with Xcode 3.1. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
