2013/1/10 Jan Holzhueter <[email protected]> > Hi, > > > Well I am not sure it is fine. > > It usually means that, to be run, your binary requires a system with > > hardware capability AMD_3DNOW. > > See: http://docs.oracle.com/cd/E19082-01/819-0690/chapter2-20/index.html > > > I needed to raise the build level for ffmpeg anyway to build. > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/ffmpeg/trunk/Makefile#L176 > > I'm not sure here if sse is the "same" as AMD_3DNOW but I think they are >
So you will have the same problem I suppose. > > On the other hand ffmpeg does have cpu autodetect. So iirc it only uses > codepath it can use. But builds all code paths. For see I could be wrong > as I added it as flags Well ffmpeg may have cpu autodetect but solaris will refuse to load the binary anyway. See what happens when I am trying to run in under Solaris 10 x86 which can run adm64 binaries: yann@unstable10x:~/opencsw/openssl1/trunk$ /home/jh/opencsw/ffmpeg/trunk/work/solaris10-i386/pkgroot/opt/csw/bin/amd64/ffmpeg ld.so.1: ffmpeg: fatal: /home/jh/opencsw/ffmpeg/trunk/work/solaris10-i386/pkgroot/opt/csw/bin/amd64/ffmpeg: hardware capability (CA_SUNW_HW_1) unsupported: 0x100 [ AMD_3DNow ] Killed If you are sure than ffmpeg can use the good code path at runtime, you need to prevent the hardware capability to be stored into the binary during the compilation or you need to remove it after the compilation. I know you can do the latter using elfedit. See http://docs.oracle.com/cd/E23824_01/html/821-1461/elfedit-1.html section "Example 2 Removing a Hardware Capability Bit". I think now that this problem is eligible to a new checkpkg test. Yann
_______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
