Re: [Fink-devel] building libxine on x86-32 with XCode 3.0
Matthias Ringwald a écrit : 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. I tried some with building an external ffmpeg-package and compiling xine with --with-external-ffmpeg. The next issue was a kdetv-interlacer that I just uncommented. I also took away --enable-macosx-video I'm using it with xine-lib-1.1.10.1 When trying to build gxine, it complains with checking for XINE-LIB version = 1.0.0... *** 'xine-config --version' returned -1717986918.1072798105.-1717986918, but XINE (1072798105.858993459.1076114227) *** was found! If xine-config was correct, then it is best *** to remove the old version of XINE. You may also be able to fix the error *** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing *** /etc/ld.so.conf. Make sure you have run ldconfig if that is *** required on your system. *** If xine-config was wrong, set the environment variable XINE_CONFIG *** to point to the correct copy of xine-config, and remove the file config.cache *** before re-running configure but when I run xine-config on its own, it says: ineiti$ xine-config --version 1.1.10.1 Anyway, I'm trying to compile xfmedia now, to see if I have more luck or if I changed the libxine1.info too much ;) Linus PS: to run, copy the two files to /sw/fink/10.4/local/main/finkinfo and run fink install libxine1 Package: libxine1 Version: 1.1.10.1 Revision: 1027 Description: Xine video/media player library License: GPL Maintainer: Justin F. Hallett [EMAIL PROTECTED] Depends: %N-shlibs (= %v-%r), libpostproc51-shlibs, libavutil49-shlibs, libavformat52-shlibs BuildDepends: fink (= 0.24-1), aalib, arts-dev (= 1.4.0-2041), audiofile, bzip2-shlibs, esound, libflac8-dev , freetype219, gconf2-dev, gettext-bin, gettext-tools, glib2-dev (= 2.8.6-123), gnome-vfs2-ssl-dev | gnome-vfs2-dev, imagemagick-dev (= 6.1.8-1002) | imagemagick10-dev (= 6.1.8-1002), lcms, libbonobo2-dev, libcaca-dev, libcdio-dev, libgettext3-dev, libiconv-dev, libiso9660-dev, libjpeg, libmng2, libncurses5 (= 5.4-20041023-1006), libogg, libpng3, libtheora0, libtiff, libtool14, libvcd-dev (= 0.7.21-10), libvorbis0, libxml2, orbit2-dev, pkgconfig, popt, pth, qt3 (= 3.3.6-1027), sdl (= 1.2.9-1001), slang, speex3, x11-dev, libhowl-dev, libavcodec-dev, libavutil-dev, libpostproc-dev Provides: libxine Conflicts: libxine, libxine-docs Replaces: libxine, libxine-shlibs, libxine-docs Recommends: libdvdcss-shlibs BuildDependsOnly: true Source: http://kent.dl.sourceforge.net/sourceforge/xine/xine-lib-1.1.10.1.tar.bz2 Source-MD5: 83ec06946afff92afbe129774699a25e Patch: %n.patch PatchScript: perl -pi -e 's,-faltivec,-faltivec -maltivec,g' configure perl -pi -e 's,libX11.so,libX11.dylib,g; s,libXv.so,libXv.dylib,g;' configure perl -pi -e 's/-avoid-version/-Wl,-read_only_relocs,warning/g;' src/libffmpeg/Makefile.in src/post/deinterlace/Makefile.in src/post/planar/Makefile.in find . -name \*.c -o -name \*.h | xargs grep balign | cut -d: -f1 | sort -u | xargs perl -pi -e 's,.balign 16,.align 4,g; s,.balign 8,.align 3,g;' # -O3 considered harmful on OSX :P perl -pi -e 's,-O3,-Os,g' configure # perl -pi -e 's|(OPENGL_LIBS=).*|$1-lGL -dylib_file /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib|g' configure SetCPPFLAGS: -fno-common -I%p/lib/freetype219/include/freetype2 -I%p/lib/freetype219/include -I/usr/X11R6/include -I%p/include SetLDFLAGS: -L%p/lib/freetype219/lib -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib SetLIBS: -L%p/lib SetMAKEFLAGS: -j1 NoSetCPPFLAGS: true NoSetLDFLAGS: true NoSetMAKEFLAGS: true ConfigureParams: --with-external-ffmpeg --enable-static --enable-shared --disable-alsa --disable-alsatest --disable-dxr3 --enable-coreaudio --disable-fb --disable-directfb --disable-vis --disable-mlib --libexecdir=%p/lib/libxine --mandir=%p/share/man --disable-sdltest (%m = powerpc) --enable-altivec (%m = i386) --disable-altivec --disable-w32dll --disable-dependency-tracking CompileScript: #!/bin/sh -ev export PATH=%p/lib/freetype219/bin:$PATH export PKG_CONFIG_PATH=%p/lib/freetype219/lib/pkgconfig:$PKG_CONFIG_PATH if [ %m = i386 ]; then export CPPFLAGS=$CPPFLAGS -UHAVE_MMX -UHAVE_MMX2 fi ./configure %c if [ %m = i386 ]; then echo #define HAVE_DARWIN_CDROM 1 config.h fi make InstallScript: make install DESTDIR=%d DocFiles: AUTHORS COPYING CREDITS ChangeLog INSTALL NEWS README TODO SplitOff: Package: %N-shlibs Depends: aalib-shlibs, arts-shlibs (= 1.4.0-2041),
Re: [Fink-devel] building libxine on x86-32 with XCode 3.0
Hi Linus thanks for reporting back. on what platform are you (x86-32/64/powerpc(64))? I've compiled xine-ui yesterday with only a minimal patch (http://marc.info/?l=xine-develm=120610913015518w=2) for quick (successful) tests using xine you can use several minimal xine players. e.g. see http://xinehq.de/index.php/samplecode for x11-based videoutput plugins or my adaption for other outputs like xcb and cocoa at http://libxine-java.svn.sourceforge.net/viewvc/libxine-java/example/ for muxine-cocoa.m you do need the --enable-macosx-video.. :) The problem with most xine based players, is that they are based on the x11 output plugins. however, on my machines, the xv overlay does not work on mac, so the scaling has to be done in software which is very cpu intensive. on my MacBookPro 2 Ghz, I could not watch a .mp4 file in fullscreen without stuttering video. I don't know if the SDL plugin works with hardware support, though. the muxine-cocoa works fine although it hoes no UI to speak of. I normally use mplayer from the console on mac to watch movies btw. I can try to compile gxine and/or xfmedia, but I'm afraid, it will also use the (on mac slow) x11 output. cheers matthias On Mar 22, 2008, at 10:35 AM, Linus Gasser wrote: Matthias Ringwald a écrit : 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. I tried some with building an external ffmpeg-package and compiling xine with --with-external-ffmpeg. The next issue was a kdetv- interlacer that I just uncommented. I also took away --enable-macosx- video - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] building libxine on x86-32 with XCode 3.0
Matthias Ringwald a écrit : Hi Linus thanks for reporting back. on what platform are you (x86-32/64/powerpc(64))? x86-32, I think. Even though ld -v gives ld64-77? It's a MacBook Air with XCode 3.0. I can try to compile gxine and/or xfmedia, but I'm afraid, it will also use the (on mac slow) x11 output. xfmedia is missing some other libraries here that I don't find (exo=0.3). So no luck. I also tried xine-lib-1.1.11, but I have some other problems with the postprocess-library-includes. I think I'll wait to get XCode 3.1 and try it again then... Linus - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] building libxine on x86-32 with XCode 3.0
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] building libxine on x86-32 with XCode 3.0
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/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
