[csw-maintainers] Checkpkg database update and new checkpkg tests

[Yann Rouillard]

2013/1/10 Jan Holzhueter <jh at opencsw.org>

> 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20130111/3bfb4de1/attachment.html>