I'm getting: ffmpeg.c:4514: undefined reference to `avdeviceregisterall' when -disable-static -enable-shared is used, it seems to only happen when -disable-static -enable-shared is used, static builds fine. I believe it is related to the leading underscore before avdeviceregisterall but I can't confirm that. I'm building for Windows and the toolchain is not the issue. I gave this a critical priority because FFmpeg will not build a shared version for Windows. I'm unsure of what patch broke this, but the last proven working build I know of is git-39dbe9b.

The problem is SDL/ffplay related. I narrowed it down and the issue only occurs when ffplay is built, along with -disable-static -enable-shared. Also, the command you gave me 'make ffmpeg' is not valid, I'm not sure if it's a windows thing or what, but I think you might have meant 'make ffmpeg.o' but I'm not going to assume anything. 1) I'm using the latest git, 2) I build out of the source directory, the build directory is removed and rebuilt before configure is run. 3) LDFLAGS='-L/home/kyle/software/ffmpeg/packages/sdl/sdl-1.2.14-win32/lib' PKGCONFIGPATH='/home/kyle/software/ffmpeg/packages/sdl/sdl-1.2.14-win32/lib/pkgconfig' CFLAGS='-I/home/kyle/software/ffmpeg/packages/sdl/sdl-1.2.14-win32/include' crossprefix=i686-w64-mingw32- targetos=mingw32 arch=x86./source/ffmpeg-git/configure -disable-static -enable-shared -enable-gpl -enable-version3 -enable-memalign-hack -enable-runtime-cpudetect 4) Attached. Yes I realize that it is a failing link command for ffmpeg, but the issue only occurs when sdl is in the LDFLAGS and CFLAGS, meaning it only occurs when FFmpeg is able to build ffplay. After doing some more reading it might not be rawdec.o, it appears that (the patch) doesn't actually display all the changes in that commit.

A possible solution can be found here: Here is a patch that can fix the issue but I have NOT been able to test if this breaks the build for Linux./libavdevice/avdevice.h.orig 2011-09-12 02:85547 -0400./libavdevice/avdevice.h 2011-09-12 03:82012 -0400 @@ -41,12 +41,12 @@ /. Return the LIBAVDEVICEVERSIONINT constant./ -unsigned avdeviceversion(void); +declspec(dllexport) unsigned avdeviceversion(void); /.

Return the libavdevice build-time configuration./ -const char.avdeviceconfiguration(void); +declspec(dllexport) const char.avdeviceconfiguration(void); /. Return the libavdevice license. @@ -57,7 +57,7 @@. Initialize libavdevice and register all the input and output devices. @warning This function is not thread safe./ -void avdeviceregisterall(void); +declspec(dllexport) void avdeviceregisterall(void); #endif /.

Ffmpeg-user Missing Packages For Building Ffmpeg 2.1 Without

AVDEVICEAVDEVICEH./ I'm open to a different solution to this problem, but would really like to get this bug closed. I do not see any reasonable explanation, and I cannot reproduce it. However what seems to happen according to the reported facts is that avdeviceregisterall is not exported from avdevice-54.dll. You can check that by running objdump -x libavdevice/avdevice-54.dll The interesting part is 'The Export Tables (interpreted.edata section contents)' If it was generated correctly, it should have a part looking like this: Ordinal/Name Pointer Table 0 avdeviceconfiguration 1 avdevicelicense 2 avdeviceregisterall 3 avdeviceversion The previous suggested hack of adding declspec(dllexport) should not be necessary, the information that these and only these functions should be exported comes from libavdevice/libavdevice.ver. That file in turn is generated from libavdevice/libavdevice.v. It is specified via the -Wl,-version-script,libavdevice/libavdevice.ver option when linking the dll file.

This compilation step also generates a libavdevice/avdevice-54.def which should look like this: EXPORTS avdeviceconfiguration @1 avdevicelicense @2 avdeviceregisterall @3 avdeviceversion @4 There is one very crazy theory how this could go wrong with SDL: Without setting -DDECLSPEC SDL will use dllspec(dllexport) and dllspec(dllimport) instead of version/def/dll.a files. This might mean that the linker ends up with some symbols being marked up via dllspec while also getting a version script, and due to some bug it might end up ignoring the version script. It seems very unlikely though, but if you want to investigate you will probably want to experiment with the commandline used to link the avdevice dll. $ cat sandbox/win32/ffmpeggit/libavcodec/.def EXPORTS ZN6CCodec14CreateInstanceEjPKc @1 ZN6CCodec14DeleteInstanceEPS @2 These methods come from the 'utvideo' package, I believe. So it must be leaking symbols. According to unless -export-all-symbols is explicitly stated, if any symbol is found that is marked with marked with the declspec(dllexport) then it won't export 'any other symbols' which must be happening here. Maybe to avoid this type of rampant confusion -export-all-symbols could be added.

Will keep investigating. Pax creative drivers for mac. Just read the documentation on the version-script option: It is partially supported on PE platforms, which can use version scripts to filter symbol visibility in auto-export mode: any symbols marked local in the version script will not be exported. That seems to indicate that it ignores which symbols are marked as 'global'. At the same time, while not documented, it seems like -export-all-symbols does not override the 'local' settings in the version file, so adding that might indeed be a workaround (though the whole behaviour seems broken to me, and contradicts the documentation which suggests that version-script should be ignored when not using auto-export mode). However that brings me to another point, that I think the libSDL/utvideo build systems are broken. I presume you link against a static build of these libraries.

Ffmpeg-user Missing Packages For Building Ffmpeg 2.1 With Windows

However, when building static libraries they should not mark those functions as 'dllexport', as the name says it is supposed to be for when you build DLLs. You certainly don't want these functions to be exported when you just use the functionality. For example, if the SDL DLL was build statically against utvideo (of course not the case, just an example) it would end up exporting the utvideo functions, which would then cause symbol collisions if an application would try to use both the SDL DLL and a utvideo DLL.