Solaris Intel static libraries required AMD 3D NOW even though the CPU doesn't support

[Bradley Mitchell]

Summary of the bug:

Static lib compiled on Solaris Intel compiles in AMD3DNOW CPU instructions even though the configure explicitly doesn't find a CPU capable of the instructions. Dynamic libraries are fine however (which I am unsure of why).

How to reproduce:

Compile libavutil as a static lib on Solaris Intel with SSE extensions.
Link in libavutil etc to a simple main with the avcodec register init functions.
Run file <output> on the binary to show the required CPU extensions.

Note, I ended up putting a #ifdef around the explicit AMD 3D NOW code in x86/float_dsp_init.c around the INLINE_AMD3DNOWEXT() stuff and the function vector_fmul_window_3dnowext.

[Carl Eugen Hoyos]

Please test current FFmpeg git head, add your configure line, the FFmpeg version you are compiling and the complete error message.

Is this not reproducible if you type ./ffmpeg?

[Hendrik]

Binaries are by default compiled with all instructions enabled, and the appropriate instruction for your CPU picked at runtime. Which instructions are built depends on your compiler supporting them, not your CPU.

This is not a bug, unless you explicitly specify --disable-3dnow (or others) during building.

[Bradley Mitchell]

With regards to reproducible by using ffmpeg, it doesn't appear so. Even running "file ffmpeg" does not show a requirement for the AMD_3dNow extension.

I use the oracle compiler to build on Intel Solaris 10 and have this issue with a C++ built program that includes the libavcodec et al libraries.

I do not have an issue if I use dynamic libraries for some reason.

--

I tried compiling 2.2.2 on Solaris Intel and I'm failing to link ffmpeg.

LD ffmpeg_g
Undefined first referenced

symbol in file

ff_synth_filter_inner_sse2 libavcodec/libavcodec.a(dcadsp_init.o)
ld: fatal: symbol referencing errors. No output written to ffmpeg_g
gmake: * [ffmpeg_g] Error 2

configuring using:
bash ./configure --extra-cflags="-fPIC" --disable-mmx --disable-protocol=udp --disable-encoder=nellymoser --cc=cc --cxx=CC --disable-doc

So I am unable to test if it is an issue with the latest version.

FYI, I did specify --disable-3dnow when it was recompiled.

[Carl Eugen Hoyos]

Replying to bmitchel:

I tried compiling 2.2.2 on Solaris Intel and I'm failing to link ffmpeg.

Please test current FFmpeg git head.

LD ffmpeg_g
Undefined first referenced
symbol in file
ff_synth_filter_inner_sse2 libavcodec/libavcodec.a(dcadsp_init.o)
ld: fatal: symbol referencing errors. No output written to ffmpeg_g
gmake: * [ffmpeg_g] Error 2

I am unable to reproduce this problem with FFmpeg 2.2.2.

bash ./configure --extra-cflags="-fPIC" --disable-mmx --disable-protocol=udp --disable-encoder=nellymoser --cc=cc --cxx=CC --disable-doc

Why are you using --disable-mmx? This seems like a very bad option, don't you agree?
Are --cc and -cxx necessary? Why?

Is your original problem only that the output of file is not satisfying or do you have actual problems with your linked executable?

[Bradley Mitchell]

Replying to cehoyos:

Replying to bmitchel:

I tried compiling 2.2.2 on Solaris Intel and I'm failing to link ffmpeg.

Please test current FFmpeg git head.

I will try this on a later build, but would prefer to use a stable build. To date I have been working with FFMPEG 2.0

LD ffmpeg_g
Undefined first referenced
symbol in file
ff_synth_filter_inner_sse2 libavcodec/libavcodec.a(dcadsp_init.o)
ld: fatal: symbol referencing errors. No output written to ffmpeg_g
gmake: * [ffmpeg_g] Error 2

I am unable to reproduce this problem with FFmpeg 2.2.2.

bash ./configure --extra-cflags="-fPIC" --disable-mmx --disable-protocol=udp --disable-encoder=nellymoser --cc=cc --cxx=CC --disable-doc

Why are you using --disable-mmx? This seems like a very bad option, don't you agree?

I would agree yes, however I cannot get to compile/get to the linking stage without this. Possibly an Oracle Compiler issue, I am unsure but the original article I used to help do an initial compile has stuck:

​http://chrismiles.livejournal.com/25439.html

If i exclude --disable-mmx, I get the compilation issue:

CC libavfilter/vf_mergeplanes.o
CC libavfilter/vf_noise.o
"vf_noise.c", [line_noise_avg_mmx]:ube: error: Cannot allocate register for argument '%5' in GASM Inlining
cc: ube failed for libavfilter/vf_noise.c
gmake: * [libavfilter/vf_noise.o] Error 2

Are --cc and -cxx necessary? Why?

So it doesn't pick up gcc to build with. We don't build with gcc, we build with the Oracle Compiler.

Is your original problem only that the output of file is not satisfying or do you have actual problems with your linked executable?

Original problem is that building a C++ program using the static libs puts a dependency on the CPU requiring the AMD 3d Now instruction set, which is unsupported. Linking with the dynamic libs instead of the static libs does not result in the dependency or seem to have any issues, so it could and is very likely it is a problem with the CC compiler, or I am missing some sort of flag on the compiler to exclude instructions that are not supported by the CPU, if such a flag exists.

[Hendrik]

The presence of the instructions in the avcodec library should not prevent it from running on any system, as its designed to detect the CPU features and only execute the code if supported.

So does it actually fail to run? That seems rather weird. None of the libs should ever execute it if your CPU doesn't support it.

Maybe your C++ compiler/linker somehow scans the static library for all instructions it uses and then somehow flags the resulting library to require these? That seems like a rather crazy thing to do, but what do I know about the oracle tools on Solaris.

[Carl Eugen Hoyos]

Replying to bmitchel:

Replying to cehoyos:

Replying to bmitchel:

I tried compiling 2.2.2 on Solaris Intel and I'm failing to link ffmpeg.

Please test current FFmpeg git head.

I will try this on a later build, but would prefer to use a stable build. To date I have been working with FFMPEG 2.0

Please understand that there is nothing unstable about current git head, it is exactly as stable as a release branch (but contrary to a release branch, we support it also if you are not a distributor).

bash ./configure --extra-cflags="-fPIC" --disable-mmx --disable-protocol=udp --disable-encoder=nellymoser --cc=cc --cxx=CC --disable-doc

Why are you using --extra-cflags="-fPIC"?
Why not --enable-pic (or neither of them)?

Why are you using --disable-mmx? This seems like a very bad option, don't you agree?

I would agree yes, however I cannot get to compile/get to the linking stage without this.

You should first take care about this important issue (that makes your binaries unusable and imo unsupported - at least I consider --disable-mmx a pure debug option).

Possibly an Oracle Compiler issue, I am unsure but the original article I used to help do an initial compile has stuck:

​http://chrismiles.livejournal.com/25439.html

This is so outdated that it has no relevance for your problem.

If i exclude --disable-mmx, I get the compilation issue:

CC libavfilter/vf_noise.o
"vf_noise.c", [line_noise_avg_mmx]:ube: error: Cannot allocate register for argument '%5' in GASM Inlining

(Generally, a line number would help, fortunately it is unneeded here.)

What does the following show?
$ grep HAVE_EB config.h

Could you test forcing one of them to 0?
This should lead to a permanent fix.

cc: ube failed for libavfilter/vf_noise.c
gmake: * [libavfilter/vf_noise.o] Error 2

Are --cc and -cxx necessary? Why?

So it doesn't pick up gcc to build with. We don't build with gcc, we build with the Oracle Compiler.

Please do us all a favor and also test gcc.

[Bradley Mitchell]

Replying to cehoyos:

Please understand that there is nothing unstable about current git head, it is exactly as stable as a release branch (but contrary to a release branch, we support it also if you are not a distributor).

I was not trying to imply it wasn't unstable. Bad use of language there.

Why are you using --extra-cflags="-fPIC"?
Why not --enable-pic (or neither of them)?

I'll use --enable-pic. I started building this on SPARC Solaris, then Intel Solaris and Windows on much older versions so some of these things have stuck.

You should first take care about this important issue (that makes your binaries unusable and imo unsupported - at least I consider --disable-mmx a pure debug option).

I will remove it. Just the way again I've previously compiled.

This is so outdated that it has no relevance for your problem.

Understood. I know this has nothing to do with my issue, it was just the build instructions I've previously used and refined to a certain extent (mainly the configure).

(Generally, a line number would help, fortunately it is unneeded here.)

What does the following show?
$ grep HAVE_EB config.h

barney(bradm) grep HAVE_EB config.h
#define HAVE_EBP_AVAILABLE 0
#define HAVE_EBX_AVAILABLE 1

Could you test forcing one of them to 0?
This should lead to a permanent fix.

I tried changing HAVE_EBX_AVAILABLE to 0 also, and this still resulted in the same error:

CC libavfilter/vf_noise.o
"vf_noise.c", [line_noise_avg_mmx]:ube: error: Cannot allocate register for argument '%5' in GASM Inlining
cc: ube failed for libavfilter/vf_noise.c
gmake: * [libavfilter/vf_noise.o] Error 2

There is no line number specified in the output for the error.

Please do us all a favor and also test gcc.

Absolutely. There is a much older version of gcc installed (3.4.3) which is stock standard installed for Solaris. Any recommendations on a version you would suggest? I'm not overly familiar with the gcc compiler.

[Carl Eugen Hoyos]

Replying to bmitchel:

Why are you using --extra-cflags="-fPIC"?
Why not --enable-pic (or neither of them)?

I'll use --enable-pic.

Why is --enable-pic needed? I believe it caused one of your problems and it would be good to understand the underlying problem better.

You should first take care about this important issue (that makes your binaries unusable and imo unsupported - at least I consider --disable-mmx a pure debug option).

I will remove it. Just the way again I've previously compiled.

This is so outdated that it has no relevance for your problem.

Understood. I know this has nothing to do with my issue, it was just the build instructions I've previously used and refined to a certain extent (mainly the configure).

If ./configure && make does not work, it would be great if you could report that.

What does the following show?
$ grep HAVE_EB config.h

barney(bradm) grep HAVE_EB config.h
#define HAVE_EBP_AVAILABLE 0
#define HAVE_EBX_AVAILABLE 1

Could you test forcing one of them to 0?
This should lead to a permanent fix.

I tried changing HAVE_EBX_AVAILABLE to 0 also, and this still resulted in the same error:

CC libavfilter/vf_noise.o
"vf_noise.c", [line_noise_avg_mmx]:ube: error: Cannot allocate register for argument '%5' in GASM Inlining
cc: ube failed for libavfilter/vf_noise.c
gmake: * [libavfilter/vf_noise.o] Error 2

Sorry, I had forgotten: This was fixed a month ago, as said please test current FFmpeg git head.

Please do us all a favor and also test gcc.

Absolutely. There is a much older version of gcc installed (3.4.3) which is stock standard installed for Solaris. Any recommendations on a version you would suggest? I'm not overly familiar with the gcc compiler.

gcc 3.4.3 is so outdated that it might be better to fix the issues with your current compiler, a suggested version would be gcc 4.8.3.

[Bradley Mitchell]

I ended up getting the latest version of ffmpeg from GIT.

It was configured using the flags:
--disable-protocol=udp --disable-encoder=nellymoser --cc=cc --cxx=CC --disable-doc

I had to make a couple of changes to get this working on Solaris:
1) version.sh I had to change the shell to /bin/bash (could just be something with my environment)
2) I had to change line 205 of libswscale/x86/swscale.c to remove the "return" from a void function, as it appears the Oracle compiler doesn't like this.

After that did compile however, still having an issue with the linked executable containing an instruction set that isn't supported by the CPU.

ld.so.1: test.i386: fatal: test.i386: hardware capability (CA_SUNW_HW_1) unsupported: 0x100 [ AMD_3DNow ]
Killed

The ffmpeg executable linked with the Oracle C compiler doesn't appear to have this same issue.

[Timothy Gu]

Did you check GCC?

[Bradley Mitchell]

I'll check gcc now and report back.
I did find a way around the HWCAP issue with the C++ compiled app, but involves setting the HWCAP directly using the map file:

cat mapfile.i386
hwcap_1 = AVX SSSE3 SSE2 SSE MMX CMOV TSC FPU OVERRIDE;

[Bradley Mitchell]

No dice with GCC at the moment.

gmake
CC      libavutil/file_open.o
libavutil/file_open.c: In function 'av_fopen_utf8':
libavutil/file_open.c:128:5: error: implicit declaration of function 'fdopen' [-Werror=implicit-function-declaration]
     return fdopen(fd, mode);
     ^
libavutil/file_open.c:128:5: warning: return makes pointer from integer without a cast
cc1: some warnings being treated as errors
gmake: *** [libavutil/file_open.o] Error 1

gcc version:

barney(bradm) gcc -v
Reading specs from /opt/csw/lib/gcc/i386-pc-solaris2.10/4.9.0/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/csw/libexec/gcc/i386-pc-solaris2.10/4.9.0/lto-wrapper
Target: i386-pc-solaris2.10
Configured with: /home/maciej/src/opencsw/pkg/gcc4/trunk/work/solaris10-i386/build-isa-pentium_pro/gcc-4.9.0/configure --prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin --sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec --datadir=/opt/csw/share --sysconfdir=/etc/opt/csw --sharedstatedir=/opt/csw/share --localstatedir=/var/opt/csw --libdir=/opt/csw/lib --infodir=/opt/csw/share/info --includedir=/opt/csw/include --mandir=/opt/csw/share/man --enable-cloog-backend=isl --enable-java-awt=xlib --enable-languages=ada,c,c++,fortran,go,java,objc --enable-libada --enable-libssp --enable-nls --enable-objc-gc --enable-threads=posix --program-suffix=-4.9 --with-cloog=/opt/csw --with-gmp=/opt/csw --with-included-gettext --with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw --with-ppl=/opt/csw --with-system-zlib=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas
Thread model: posix
gcc version 4.9.0 (GCC)

Enforcing some standard perhaps?

[Carl Eugen Hoyos]

Replying to bmitchel:

I ended up getting the latest version of ffmpeg from GIT.

Was this a problem?
The reason I ask is that if a documentation update is needed, please tell us!

It was configured using the flags:
--disable-protocol=udp --disable-encoder=nellymoser --cc=cc --cxx=CC --disable-doc

Do I understand correctly that ./configure && make fails? (Or in the case of Solaris bash configure && make.)
Please report this! This is the recommended compilation method and we would like to know if it doesn't work.

I had to make a couple of changes to get this working on Solaris:
1) version.sh I had to change the shell to /bin/bash (could just be something with my environment)

Isn't this documented in https://ffmpeg.org/platform.html#g_t_0028Open_0029Solaris ? Or are you describing another issue?

2) I had to change line 205 of libswscale/x86/swscale.c to remove the "return" from a void function, as it appears the Oracle compiler doesn't like this.

Could you provide the compilation error and the compiler version? This will make committing a fix easier.

After that did compile however, still having an issue with the linked executable containing an instruction set that isn't supported by the CPU.

Sorry, I still didn't understand: If you use the static libraries to link a new executable does it fail? Or when does it fail?

ld.so.1: test.i386: fatal: test.i386: hardware capability (CA_SUNW_HW_1) unsupported: 0x100 [ AMD_3DNow ]
Killed

The ffmpeg executable linked with the Oracle C compiler doesn't appear to have this same issue.

I thought you are only using the Oracle C compiler or do I misunderstand?

[Bradley Mitchell]

I need to lay out all the issues here, as there seems to be a bit of confusion.

Compiling & using FFMPEG with Solaris 10 Intel

Configure with:

	bash ./configure --cc=cc --cxx=CC

I removed --disable-doc etc, and Intel compiled no problems, so there are no issues here.

1) version.sh does not execute properly.

barney(bradm) gmake
./version.sh: syntax error at line 7: `revision=$' unexpected

To fix this, the first line needs to be changed to use bash:

#!/bin/bash

Running "bash version.sh" also works, however, the way version.sh is normally called doens't preclude with the bash shell.

barney(bradm) bash version.sh
N-64012-g61df081

2) libswscale/x86/swscale.c has a compiler error

"libswscale/x86/swscale_template.c", line 777: warning: parameter in inline asm statement unused: %1
"libswscale/x86/swscale_template.c", line 777: warning: parameter in inline asm statement unused: %2
"libswscale/x86/swscale_template.c", line 777: warning: parameter in inline asm statement unused: %3
"libswscale/x86/swscale.c", line 205: void function cannot return value
cc: acomp failed for libswscale/x86/swscale.c
gmake: *** [libswscale/x86/swscale.o] Error 2

At line 205, there is a return from a void function:

static void yuv2yuvX_sse3(const int16_t *filter, int filterSize,
                           const int16_t **src, uint8_t *dest, int dstW,
                           const uint8_t *dither, int offset)
{
    if(((int)dest) & 15){
        return yuv2yuvX_mmxext(filter, filterSize, src, dest, dstW, dither, offset);
    }

To get this to compile, I've moved the return to after the yuv2yuvX_mmxext function call

	if(((int)dest) & 15){
        yuv2yuvX_mmxext(filter, filterSize, src, dest, dstW, dither, offset);
        return;
   }

3) As per the original intention, I have an issue with the Oracle Compiler (we don't use the gcc compiler in our environment, but

I am testing the Solaris compile as requested.

C++ applications (I haven't tried a simple C application) when linked have a CPU requirement for the AMD_3dNow instructions.
The only workaround I've found for this on our own C++ applications is as said in the comments, by using a mapfile to remove the
AMD_3dNow instruction dependency.

barney(bradm) elfdump -H libavcodec/libavcodec.a | grep AMD
       [0]  CA_SUNW_HW_1     0x943  [ SSE AMD_3DNow MMX TSC FPU ]
       [0]  CA_SUNW_HW_1     0x400963  [ SSSE3 SSE AMD_3DNow MMX CMOV TSC FPU ]
barney(bradm) elfdump -H libavdevice/libavdevice.a | grep AMD
barney(bradm) elfdump -H libavfilter/libavfilter.a | grep AMD
barney(bradm) elfdump -H libavformat/libavformat.a | grep AMD
barney(bradm) elfdump -H libavutil/libavutil.a | grep AMD
barney(bradm) elfdump -H libswresample/libswresample.a | grep AMD
barney(bradm) elfdump -H libswscale/libswscale.a | grep AMD
       [0]  CA_SUNW_HW_1     0x1943  [ SSE2 SSE AMD_3DNow MMX TSC FPU ]

libavcodec/libavcodec.a(cavsdsp.o):

Capabilities Section:  .SUNW_cap

 Object Capabilities:
     index  tag               value
       [0]  CA_SUNW_HW_1     0x943  [ SSE AMD_3DNow MMX TSC FPU ]

libavcodec/libavcodec.a(dsputilenc_mmx.o):

Capabilities Section:  .SUNW_cap

 Object Capabilities:
     index  tag               value
       [0]  CA_SUNW_HW_1     0x400963  [ SSSE3 SSE AMD_3DNow MMX CMOV TSC FPU ]

To remove this depedency when building our own C++ executables, the mapfile consists of:

hwcap_1 = AVX SSSE3 SSE2 SSE MMX CMOV TSC FPU OVERRIDE;

Linker flags include:

	-M mapfile.i386

GCC Compile

As requested, I've tried to compile using GCC.

Configure:

	bash ./configure --cc=/opt/csw/bin/gcc --cxx=/opt/csw/bin/g++ --extra-libs=/usr/lib/values-xpg6.o

1) There is a compiler issue in libavutil/file_open.c

CC      libavutil/fifo.o
CC      libavutil/file.o
CC      libavutil/file_open.o
libavutil/file_open.c: In function 'av_fopen_utf8':
libavutil/file_open.c:128:5: error: implicit declaration of function 'fdopen' [-Werror=implicit-function-declaration]
     return fdopen(fd, mode);
     ^
libavutil/file_open.c:128:5: warning: return makes pointer from integer without a cast
cc1: some warnings being treated as errors
gmake: *** [libavutil/file_open.o] Error 1

My question for this is, fdopen is not standard C, is this the issue here? Should I be using -std=gnu99 or something?

[Carl Eugen Hoyos]

Which compiler (which version) fails compilation for libswscale?

[Carl Eugen Hoyos]

Replying to bmitchel:

1) version.sh does not execute properly.

barney(bradm) gmake
./version.sh: syntax error at line 7: `revision=$' unexpected

Could you test if attached patch fixes this problem?

[Bradley Mitchell]

Applied the patch, more errors....

barney(bradm) version.sh
version.sh: null directory
version.sh: !: not found
version.sh: null directory
version.sh: null directory
version.sh: null directory
version.sh: null directory
version.sh: syntax error at line 28: `revision=$' unexpected

Compiler version:

barney(bradm) cc -V
cc: Sun C 5.12 SunOS_i386 2011/11/16

[Carl Eugen Hoyos]

Please try (with the patch attached):

$ gmake libavutil/ffversion.h

[Carl Eugen Hoyos]

The problem in libswscale should be fixed, I sent the patch for version.sh to the development mailing list, it would be great if you could test it.

[Carl Eugen Hoyos]

Replying to cehoyos:

Please try (with the patch attached):

$ gmake version.h

Sorry, I wasn't on my computer when I wrote this.
Please test:

$ gmake libavutil/ffversion.h

[Bradley Mitchell]

Replying to cehoyos:

Replying to cehoyos:

Please try (with the patch attached):

$ gmake version.h

Sorry, I wasn't on my computer when I wrote this.
Please test:

$ gmake libavutil/ffversion.h

As requested

barney(bradm) gmake libavutil/ffversion.h
./version.sh: !: not found
./version.sh: syntax error at line 28: `revision=$' unexpected
gmake: `libavutil/ffversion.h' is up to date.

[Carl Eugen Hoyos]

Replying to bmitchel:

barney(bradm) gmake libavutil/ffversion.h
./version.sh: !: not found
./version.sh: syntax error at line 28: `revision=$' unexpected
gmake: `libavutil/ffversion.h' is up to date.

Thank you for testing!

What does $ git diff show for you? The reason I ask is that with my patch, line 28 of version.sh should not contain the string revision=$.

[Bradley Mitchell]

Replying to cehoyos:

Replying to bmitchel:

barney(bradm) gmake libavutil/ffversion.h
./version.sh: !: not found
./version.sh: syntax error at line 28: `revision=$' unexpected
gmake: `libavutil/ffversion.h' is up to date.

Thank you for testing!

What does $ git diff show for you? The reason I ask is that with my patch, line 28 of version.sh should not contain the string revision=$.

Looks like there was some issue with applying the patch, not sure why. Re applied it with:

git apply patchversionsh.diff

rm libavutil/ffversion.h
gmake libavutil/ffversion.h
GEN     libavutil/ffversion.h
./version.sh: !: not found

barney(bradm) cat libavutil/ffversion.h
#ifndef AVUTIL_FFVERSION_H
#define AVUTIL_FFVERSION_H
#define FFMPEG_VERSION "git-2014-06-17-61df081"
#endif /* AVUTIL_FFVERSION_H */

Looks like it generated it!

[Timothy Gu]

Replying to bmitchel:

gmake libavutil/ffversion.h
GEN     libavutil/ffversion.h
./version.sh: !: not found

What the heck is wrong with Solaris? How come it doesn't even have ! command?

Looks like it generated it!

True, it generated it. But it is still buggy, because a command in version.sh reports not found.

[Timothy Gu]

Replying to bmitchel:

gmake libavutil/ffversion.h
GEN     libavutil/ffversion.h
./version.sh: !: not found

What the heck is wrong with Solaris? How come it doesn't even have ! command?

Looks like it generated it!

True, it generated it. But it is still buggy, because a command in version.sh reports not found.

[Bradley Mitchell]

Replying to Timothy_Gu:

Replying to bmitchel:

gmake libavutil/ffversion.h
GEN     libavutil/ffversion.h
./version.sh: !: not found

What the heck is wrong with Solaris? How come it doesn't even have ! command?

because /bin/sh sucks! version.sh worked for me when I changed the shell to /bin/bash before cehoyos stepped in to do some changes. I guess this is why configure needs to be run under bash.

Looks like it generated it!

True, it generated it. But it is still buggy, because a command in version.sh reports not found.

Could you do something like....

if [ ! -z "`test "$revision"`" ] ; then

[Carl Eugen Hoyos]

Replying to Timothy_Gu:

Looks like it generated it!

True, it generated it. But it is still buggy, because a command in version.sh reports not found.

This was already fixed in the version of the patch sent to the development mailing list.
I will update the patch here as well.

[Carl Eugen Hoyos]

Did you test the configure option --disable-amd3dnow as suggested by Hendrik in comment:2? Does it fix the issue with the invalid instruction set?

[Bradley Mitchell]

Replying to cehoyos:

Did you test the configure option --disable-amd3dnow as suggested by Hendrik in comment:2? Does it fix the issue with the invalid instruction set?

No, it does not. This was one of the first things I tried, hence the original reasoning behind this bug report. Even though I do configure and compile with the --disable-amd3dnow, the instructions are still present.

ffmpeg version git-2014-06-17-61df081 Copyright (c) 2000-2014 the FFmpeg developers
  built on Jun 23 2014 09:31:41 with Sun C 5.12 SunOS_i386 2011/11/16
  configuration: --cc=cc --cxx=CC --disable-amd3dnow
  libavutil      52. 89.100 / 52. 89.100
  libavcodec     55. 67.100 / 55. 67.100
  libavformat    55. 43.100 / 55. 43.100
  libavdevice    55. 13.101 / 55. 13.101
  libavfilter     4.  8.100 /  4.  8.100
  libswscale      2.  6.100 /  2.  6.100
  libswresample   0. 19.100 /  0. 19.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

barney(bradm) elfdump -H libavcodec/libavcodec.a
...
...
libavcodec/libavcodec.a(dsputilenc_mmx.o):

Capabilities Section:  .SUNW_cap

 Object Capabilities:
     index  tag               value
       [0]  CA_SUNW_HW_1     0x400963  [ SSSE3 SSE AMD_3DNow MMX CMOV TSC FPU ]
...
...

[Carl Eugen Hoyos]

Did you try to find out where in the source code your problem is triggered?
Does --disable-everything --disable-amd3dnow allow linking?

[Carl Eugen Hoyos]

Replying to heleppkes:

This is not a bug, unless you explicitly specify --disable-3dnow (or others) during building.

--disable-3dnow (and others) do not disable the compilation of related functions which I consider a bug unrelated to the question if we want to support Solaris or not, try for example nm libavcodec/x86/ac3dsp.o.

[Carl Eugen Hoyos]

Replying to bmitchel:

Replying to cehoyos:

Did you test the configure option --disable-amd3dnow as suggested by Hendrik in comment:2? Does it fix the issue with the invalid instruction set?

No, it does not.

Could you try with the patch I just attached and --disable-amd3dnow?
This "fixes" nm ffmpeg_g|grep 3dnow here.

barney(bradm) elfdump -H libavcodec/libavcodec.a
...
...
libavcodec/libavcodec.a(dsputilenc_mmx.o):

Capabilities Section:  .SUNW_cap

 Object Capabilities:
     index  tag               value
       [0]  CA_SUNW_HW_1     0x400963  [ SSSE3 SSE AMD_3DNow MMX CMOV TSC FPU ]
...
...

This is difficult to understand since libavcodec/x86/dsputilenc_mmx.c does not contain 3DNow-related code afaict.

[Timothy Gu]

@cehoyos in the last hunk of your patch there was an unrelated change that broke compilation.

[Carl Eugen Hoyos]

Replying to Timothy_Gu:

@cehoyos in the last hunk of your patch there was an unrelated change that broke compilation.

Not for the intended test case;-)

Thank you, patch updated.

[Hendrik]

iive found this reference on how to suppress these flags in the first place, and let proper runtime selection take place:

​https://web.archive.org/web/20070210141458/http://blogs.sun.com/alblog/entry/ridding_or_modifying_hardware_capabilities

This would be the proper (and only) solution, instead of riddling the entire code with more conditions

[Carl Eugen Hoyos]

Replying to heleppkes:

instead of riddling the entire code with more conditions

Didn't your comment:2 imply that you consider it a bug if --disable-avx outputs avx functions (that can't be used)?

[Hendrik]

The actual bug here is that he can't run runtime-selective binaries. :p

[Bradley Mitchell]

So what should I be doing in this case, what is the official solution?
Should I be applying a patch and configuring with the disable for amd3dnow or applying a map file at link time?

[Carl Eugen Hoyos]

Please test building with the patch I attached and --disable-amd3dnow to confirm that the issue is understood.

[Bradley Mitchell]

Configured with:

bash ./configure --cc=cc --cxx=CC --disable-amd3dnow

"ffmpeg_vdpau.c", line 311: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned int : "libavcodec/vdpau.h", line 170
        argument : pointer to int
LD      ffmpeg_g
Undefined                       first referenced
 symbol                             in file
ff_avg_pixels8_x2_3dnow             libavcodec/libavcodec.a(hpeldsp_init.o)
ff_avg_pixels8_y2_3dnow             libavcodec/libavcodec.a(hpeldsp_init.o)
ff_avg_pixels8_xy2_3dnow            libavcodec/libavcodec.a(hpeldsp_init.o)
ff_avg_rv40_qpel_h_3dnow            libavcodec/libavcodec.a(rv40dsp_init.o)
ff_put_pixels8_y2_3dnow             libavcodec/libavcodec.a(hpeldsp_init.o)
ff_avg_approx_pixels8_xy2_3dnow     libavcodec/libavcodec.a(hpeldsp_init.o)
ff_float_to_int16_3dnow             libavcodec/libavcodec.a(fmtconvert_init.o)
ff_float_to_int16_interleave6_3dnowext libavcodec/libavcodec.a(fmtconvert_init.o)
ff_avg_rv40_qpel_v_3dnow            libavcodec/libavcodec.a(rv40dsp_init.o)
ff_float_to_int16_interleave6_3dnow libavcodec/libavcodec.a(fmtconvert_init.o)
ff_avg_pixels8_3dnow                libavcodec/libavcodec.a(hpeldsp_init.o)
ff_put_no_rnd_pixels8_y2_3dnow      libavcodec/libavcodec.a(hpeldsp_init.o)
ff_put_no_rnd_pixels8_x2_3dnow      libavcodec/libavcodec.a(hpeldsp_init.o)
ff_float_to_int16_step_3dnow        libavcodec/libavcodec.a(fmtconvert_init.o)
ff_float_to_int16_interleave2_3dnow libavcodec/libavcodec.a(fmtconvert_init.o)
ld: fatal: symbol referencing errors. No output written to ffmpeg_g
gmake: *** [ffmpeg_g] Error 2

[Carl Eugen Hoyos]

Please run make distclean and try again / what does grep AMD3D config.h show for you?

[Bradley Mitchell]

#define HAVE_AMD3DNOW 0
#define HAVE_AMD3DNOWEXT 0
#define HAVE_AMD3DNOW_EXTERNAL 0
#define HAVE_AMD3DNOWEXT_EXTERNAL 0
#define HAVE_AMD3DNOW_INLINE 0
#define HAVE_AMD3DNOWEXT_INLINE 0

[Carl Eugen Hoyos]

The only usage of ff_avg_pixels8_x2_3dnow in libavcodec/x86/hpeldsp_init.c is in line 265 and is protected by #if HAVE_AMD3DNOW_EXTERNAL. Or does the compiler really output a symbol just for the declaration of the function in line 79?

[Bradley Mitchell]

I did a make distclean and reconfigured and tried to compile with the same issue.

Replying to cehoyos:

The only usage of ff_avg_pixels8_x2_3dnow in libavcodec/x86/hpeldsp_init.c is in line 265 and is protected by #if HAVE_AMD3DNOW_EXTERNAL. Or does the compiler really output a symbol just for the declaration of the function in line 79?

Yes, it will output a symbol even if there is a declaration, or rather, a symbol that isn't defined since it has been ifdef'd out in the source.

Declaration is still defined because YASM is defined.