Hi, not strictly a question but here goes. I had problems building ffmpeg from the svn checkouts without some modifications. First of all the configure script fails the libx264 detection. My x264 install is built with pthreads. The configure script fails to test libx264 with gcc -o /tmp/ffmpeg-conf-13885-2672-28731 /tmp/ffmpeg-conf-21387-2672-28548.o -lm -lz -lpthread -lx264 .... undefined reference to `_imp__pthread_join' .... undefined reference to `_imp__pthread_create' .... undefined reference to `_imp__pthread_num_processors_np' .... undefined reference to `_imp__pthread_mutex_lock' .... undefined reference to `_imp__pthread_mutex_unlock' .... etc, error messages about undefined reference to pthread functions. Modifying configure at line 1576 and adding -lpthread AFTER -lx264 works. The new test would pass "-lm -lz -lpthread -lx264 -lpthread" to gcc. What is going on? Also libavformat/vocenc.c would fail to compile. `ENOTSUP' undeclared (first use in this function). Adding #define ENOTSUP 48 would fix it. ENOTSUP is also defined in pthread.h. Will anybody be fixing it?
JonY wrote:
Hi, not strictly a question but here goes.
I had problems building ffmpeg from the svn checkouts without some modifications. First of all the configure script fails the libx264 detection. My x264 install is built with pthreads. The configure script fails to test libx264 with
gcc -o /tmp/ffmpeg-conf-13885-2672-28731 /tmp/ffmpeg-conf-21387-2672-28548.o -lm -lz -lpthread -lx264
.... undefined reference to `_imp__pthread_join' .... undefined reference to `_imp__pthread_create' .... undefined reference to `_imp__pthread_num_processors_np' .... undefined reference to `_imp__pthread_mutex_lock' .... undefined reference to `_imp__pthread_mutex_unlock' .... etc, error messages about undefined reference to pthread functions.
Modifying configure at line 1576 and adding -lpthread AFTER -lx264 works. The new test would pass "-lm -lz -lpthread -lx264 -lpthread" to gcc. What is going on?
Are you using static pthreads? You shouldn't, as pthreads-win32 is badly designed and requires a startup and cleanup call for static libraries, which FFmpeg doesn't run. Also, pthreads must be enabled for x264 to work, if x264 was compiled with pthreads. All works fine here with: shared pthreads-win32 static x264 ffmpeg: configure --enable-pthreads --enable-libx264 --enable-gpl --enable-memalign-hack Ramiro Polla
Ramiro Polla wrote:
JonY wrote:
Hi, not strictly a question but here goes.
I had problems building ffmpeg from the svn checkouts without some modifications. First of all the configure script fails the libx264 detection. My x264 install is built with pthreads. The configure script fails to test libx264 with
gcc -o /tmp/ffmpeg-conf-13885-2672-28731 /tmp/ffmpeg-conf-21387-2672-28548.o -lm -lz -lpthread -lx264
.... undefined reference to `_imp__pthread_join' .... undefined reference to `_imp__pthread_create' .... undefined reference to `_imp__pthread_num_processors_np' .... undefined reference to `_imp__pthread_mutex_lock' .... undefined reference to `_imp__pthread_mutex_unlock' .... etc, error messages about undefined reference to pthread functions.
Modifying configure at line 1576 and adding -lpthread AFTER -lx264 works. The new test would pass "-lm -lz -lpthread -lx264 -lpthread" to gcc. What is going on?
Are you using static pthreads? You shouldn't, as pthreads-win32 is badly designed and requires a startup and cleanup call for static libraries, which FFmpeg doesn't run.
Also, pthreads must be enabled for x264 to work, if x264 was compiled with pthreads. All works fine here with: shared pthreads-win32 static x264 ffmpeg: configure --enable-pthreads --enable-libx264 --enable-gpl --enable-memalign-hack
Ramiro Polla _______________________________________________ ffmpeg-user mailing list ffmpeg-user at mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Hi, I'm using shared pthreads, pthreadGC2.dll to be precise. --enable-pthreads is also passed to configure. The problem is due to dependency link order. I found out for gcc to use shared libs correctly, libraries that depend on others must be passed in order. Since x264 was compiled with pthreads, the resulting libx264 import library will have undefined references to pthreads, therefore -lpthread must come after -lx264, eg: gcc -o encoder object.o -lx264 -lpthread, but configure passed '-lpthread -lx264' to gcc.
JonY wrote:
Ramiro Polla wrote:
JonY wrote:
Hi, not strictly a question but here goes.
I had problems building ffmpeg from the svn checkouts without some modifications. First of all the configure script fails the libx264 detection. My x264 install is built with pthreads. The configure script fails to test libx264 with
gcc -o /tmp/ffmpeg-conf-13885-2672-28731 /tmp/ffmpeg-conf-21387-2672-28548.o -lm -lz -lpthread -lx264
.... undefined reference to `_imp__pthread_join' .... undefined reference to `_imp__pthread_create' .... undefined reference to `_imp__pthread_num_processors_np' .... undefined reference to `_imp__pthread_mutex_lock' .... undefined reference to `_imp__pthread_mutex_unlock' .... etc, error messages about undefined reference to pthread functions.
Modifying configure at line 1576 and adding -lpthread AFTER -lx264 works. The new test would pass "-lm -lz -lpthread -lx264 -lpthread" to gcc. What is going on?
Are you using static pthreads? You shouldn't, as pthreads-win32 is badly designed and requires a startup and cleanup call for static libraries, which FFmpeg doesn't run.
Also, pthreads must be enabled for x264 to work, if x264 was compiled with pthreads. All works fine here with: shared pthreads-win32 static x264 ffmpeg: configure --enable-pthreads --enable-libx264 --enable-gpl --enable-memalign-hack
[...]
Hi,
I'm using shared pthreads, pthreadGC2.dll to be precise. --enable-pthreads is also passed to configure.
The problem is due to dependency link order. I found out for gcc to use shared libs correctly, libraries that depend on others must be passed in order.
Since x264 was compiled with pthreads, the resulting libx264 import library will have undefined references to pthreads, therefore -lpthread must come after -lx264, eg: gcc -o encoder object.o -lx264 -lpthread, but configure passed '-lpthread -lx264' to gcc.
Your message lacks valuable bug reporting information. *Clean your system* and tell us how to reproduce it, like: using gcc version X, either compiled by yourself or obtained from Y cd pthreads-win32 make clean gc <install somehow> cd x264 configure <whatever> make && make install cd ffmpeg configure <...> make Ramiro Polla
Ramiro Polla wrote:
JonY wrote:
Ramiro Polla wrote:
JonY wrote:
Hi, not strictly a question but here goes.
I had problems building ffmpeg from the svn checkouts without some modifications. First of all the configure script fails the libx264 detection. My x264 install is built with pthreads. The configure script fails to test libx264 with
gcc -o /tmp/ffmpeg-conf-13885-2672-28731 /tmp/ffmpeg-conf-21387-2672-28548.o -lm -lz -lpthread -lx264
.... undefined reference to `_imp__pthread_join' .... undefined reference to `_imp__pthread_create' .... undefined reference to `_imp__pthread_num_processors_np' .... undefined reference to `_imp__pthread_mutex_lock' .... undefined reference to `_imp__pthread_mutex_unlock' .... etc, error messages about undefined reference to pthread functions.
Modifying configure at line 1576 and adding -lpthread AFTER -lx264 works. The new test would pass "-lm -lz -lpthread -lx264 -lpthread" to gcc. What is going on?
Are you using static pthreads? You shouldn't, as pthreads-win32 is badly designed and requires a startup and cleanup call for static libraries, which FFmpeg doesn't run.
Also, pthreads must be enabled for x264 to work, if x264 was compiled with pthreads. All works fine here with: shared pthreads-win32 static x264 ffmpeg: configure --enable-pthreads --enable-libx264 --enable-gpl --enable-memalign-hack
[...]
Hi,
I'm using shared pthreads, pthreadGC2.dll to be precise. --enable-pthreads is also passed to configure.
The problem is due to dependency link order. I found out for gcc to use shared libs correctly, libraries that depend on others must be passed in order.
Since x264 was compiled with pthreads, the resulting libx264 import library will have undefined references to pthreads, therefore -lpthread must come after -lx264, eg: gcc -o encoder object.o -lx264 -lpthread, but configure passed '-lpthread -lx264' to gcc.
Your message lacks valuable bug reporting information. *Clean your system* and tell us how to reproduce it, like: using gcc version X, either compiled by yourself or obtained from Y
cd pthreads-win32 make clean gc <install somehow>
cd x264 configure <whatever> make && make install
cd ffmpeg configure <...> make
Ramiro Polla _______________________________________________ ffmpeg-user mailing list ffmpeg-user at mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Hi, The same problem appeared when I was using gcc 3.4.2, 3.4.5, and 4.2.1. Currently using 4.2.1. All were obtained from the mingw project. Pthread was built with make clean gc, pthreadsGC.dll was redid to avoid unnecessary runtime relocation. Installed pthreadGC.dll pthread.h sched.h semaphore.h and libpthreadGC.a. libpthreadGC.a was later renamed to libpthread.a. x264 was configured with ./configure --enable-avis-input --enable-mp4-output --enable-pthread --prefix=/mingw ffmpeg was configured as with ../configure --enable-network --enable-liba52 --enable-libgsm --enable-libmp3lame --enable-gpl --enable-libfaac --enable-libfaad --enable-libx264 --enable-libxvid --enable-shared --disable-static --enable-libogg --enable-libvorbis --enable-libtheora --enable-memalign-hack --prefix=/mingw --enable-avisynth --enable-swscaler --enable-libamr-nb --enable-libamr-wb --arch=i686 --cpu=pentium4 --enable-pthreads --disable-strip Which errors out when it complains about libx264. I was only able to configure ffmpeg when I modified configure to pass -lpthread after -lx264. No further problems were encountered during compile and linking. I believe it is a simple problem with configure not passing link flags to gcc in the correct order. Inter-library dependency calculation is usually done by libtool and pkg-config. Maybe configure should use pkg-config to check x264.pc?
Hello, JonY wrote:
Ramiro Polla wrote:
JonY wrote:
Ramiro Polla wrote:
[...]
Are you using static pthreads? You shouldn't, as pthreads-win32 is badly designed and requires a startup and cleanup call for static libraries, which FFmpeg doesn't run.
!!! [...]
I'm using shared pthreads, pthreadGC2.dll to be precise. --enable-pthreads is also passed to configure.
No, you're not. [...]
Pthread was built with make clean gc, pthreadsGC.dll was redid to avoid unnecessary runtime relocation. Installed pthreadGC.dll pthread.h sched.h semaphore.h and libpthreadGC.a. libpthreadGC.a was later renamed to libpthread.a.
FFmpeg (and possibly x264 too) is linking to static pthreads-win32. Files that end in .a are static libraries. For Windows, there are .dll.a files too, that are import libs to shared libraries (dlls), but this is not the case here. You're linking to libpthread.a, a static library. I've said more than once that FFmpeg doesn't support static libraries for pthreads-win32, which is badly designed. Even if you get it to compile, ffmpeg will crash at the first call to any pthreads-win32 function because it hasn't been properly initialized. Google for PTW32_STATIC_LIB to find more about this issue. If you want to fix this in FFmpeg in a non-intrusive manner, patches are welcome. Ramiro Polla
Ramiro Polla wrote:
Hello,
JonY wrote:
Ramiro Polla wrote:
JonY wrote:
Ramiro Polla wrote:
[...]
Are you using static pthreads? You shouldn't, as pthreads-win32 is badly designed and requires a startup and cleanup call for static libraries, which FFmpeg doesn't run.
!!!
[...]
I'm using shared pthreads, pthreadGC2.dll to be precise. --enable-pthreads is also passed to configure.
No, you're not.
[...]
Pthread was built with make clean gc, pthreadsGC.dll was redid to avoid unnecessary runtime relocation. Installed pthreadGC.dll pthread.h sched.h semaphore.h and libpthreadGC.a. libpthreadGC.a was later renamed to libpthread.a.
FFmpeg (and possibly x264 too) is linking to static pthreads-win32. Files that end in .a are static libraries. For Windows, there are .dll.a files too, that are import libs to shared libraries (dlls), but this is not the case here.
You're linking to libpthread.a, a static library. I've said more than once that FFmpeg doesn't support static libraries for pthreads-win32, which is badly designed. Even if you get it to compile, ffmpeg will crash at the first call to any pthreads-win32 function because it hasn't been properly initialized. Google for PTW32_STATIC_LIB to find more about this issue.
If you want to fix this in FFmpeg in a non-intrusive manner, patches are welcome.
Ramiro Polla _______________________________________________ ffmpeg-user mailing list ffmpeg-user at mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Hi, I am using pthreads-w32-2-8-0-0-release. From the make output, $ make Run one of the following command lines: make clean GC (to build the GNU C dll with C cleanup code) make clean GCE (to build the GNU C dll with C++ exception handling) make clean GC-inlined (to build the GNU C inlined dll with C cleanup code) make clean GCE-inlined (to build the GNU C inlined dll with C++ exception handling) make clean GC-static (to build the GNU C inlined static lib with C cleanup code) make clean GC-debug (to build the GNU C debug dll with C cleanup code) make clean GCE-debug (to build the GNU C debug dll with C++ exception handling) make clean GC-inlined-debug (to build the GNU C inlined debug dll with C cleanup code) make clean GCE-inlined-debug (to build the GNU C inlined debug dll with C++ exception handling) make clean GC-static-debug (to build the GNU C inlined static debug lib with C cleanup code) I never installed the static lib, 'make clean GC' and 'make clean GC-static' both produce libpthreadGC2.a (along with pthreadGC.dll only for GC). There are no other import libs produced. The one installed in /mingw/lib is from 'make clean GC' $ nm /mingw/lib/libpthread.a |grep __imp__|sort 00000000 I __imp__pthreadCancelableTimedWait 00000000 I __imp__pthreadCancelableWait 00000000 I __imp__pthread_attr_destroy 00000000 I __imp__pthread_attr_getdetachstate ... ... To clear up any further confusion, here is the command I used to produce pthreadGC.dll. $ gcc -D__CLEANUP_C -O3 -finline-functions -shared -o pthreadGC2.dll attr.o barrier.o cancel.o cleanup.o condvar.o create.o dll.o errno.o exit.o fork.o global.o misc.o mutex.o nonportable.o private.o rwlock.o sched.o semaphore.o signal.o spin.o sync.o tsd.o version.o -lwsock32 -Wl,-export-all-symbols,-out-implib,libpthreadGC2.a Creating library file: libpthreadGC2.a $ nm ./libpthreadGC2.a |grep __imp__|sort 00000000 I __imp__pthreadCancelableTimedWait 00000000 I __imp__pthreadCancelableWait 00000000 I __imp__pthread_attr_destroy 00000000 I __imp__pthread_attr_getdetachstate ... ... While the static library is produced via running make: ar -rv libpthreadGC2.a pthread.o version.o a - pthread.o a - version.o c:\mingw\bin\ar.exe: creating libpthreadGC2.a $ nm ./libpthreadGC2.a |grep __imp__|sort produces an empty output. The confusion comes from the fact that gcc doesn't really check if it is really a shared import lib or a static one, it just searches for the .dll.a then .a if the former is not found. While this is the proper action for gcc if it is to produce dlls properly, this is only for applications developed to use autotools. pthread-w32 was not developed with autotools and does not conform to the standard ./configure && make procedure, hence there is no option to install both shared and static libs. You can put both libpthread.a from 'make GC-static' and libpthread.dll.a from 'make GC' but linking to the static lib requires passing -DPTW32_STATIC_LIB explicitly while compiling C source files that include pthread.h. Here's the actual snip from pthread.h. #ifndef PTW32_STATIC_LIB # ifdef PTW32_BUILD # define PTW32_DLLPORT __declspec (dllexport) # else # define PTW32_DLLPORT __declspec (dllimport) # endif #else # define PTW32_DLLPORT #endif I hope that cleared the confusion.
Hello, JonY wrote:
I never installed the static lib, 'make clean GC' and 'make clean GC-static' both produce libpthreadGC2.a (along with pthreadGC.dll only for GC). There are no other import libs produced.
Sorry. I hadn't seen that pthreads-win32 does: dlltool -k --dllname pthreadGC2.dll --output-lib libpthreadGC2.a ^^^^^^^^^^^^^^^ So what I thought was static is in fact an import lib, with a name different from what other libraries use. This works: $ cd pthreads-w32-2-8-0-release $ make clean GC $ cp pthread.h sched.h /mingw/include $ cp pthreadGC2.dll /mingw/lib/libpthread.dll $ cd ../ffmpeg $ ./configure --enable-memalign-hack --enable-gpl --enable-pthreads --enable-libx264 Use pthreadGC2.dll to link to instead of libpthreadGC2.a. If binutils can't resolve the dependencies in some other order, that's a bug on their side. If you have a good reason to not follow this (use the dll directly to link to), you may try issuing a bug report for M?ns to fix. I doubt you'll get his sympathy though. Ramiro Polla
Ramiro Polla wrote:
Hello,
JonY wrote:
I never installed the static lib, 'make clean GC' and 'make clean GC-static' both produce libpthreadGC2.a (along with pthreadGC.dll only for GC). There are no other import libs produced.
Sorry. I hadn't seen that pthreads-win32 does: dlltool -k --dllname pthreadGC2.dll --output-lib libpthreadGC2.a ^^^^^^^^^^^^^^^
So what I thought was static is in fact an import lib, with a name different from what other libraries use.
This works: $ cd pthreads-w32-2-8-0-release $ make clean GC $ cp pthread.h sched.h /mingw/include $ cp pthreadGC2.dll /mingw/lib/libpthread.dll $ cd ../ffmpeg $ ./configure --enable-memalign-hack --enable-gpl --enable-pthreads --enable-libx264
Use pthreadGC2.dll to link to instead of libpthreadGC2.a. If binutils can't resolve the dependencies in some other order, that's a bug on their side.
If you have a good reason to not follow this (use the dll directly to link to), you may try issuing a bug report for M?ns to fix. I doubt you'll get his sympathy though.
Ramiro Polla
_______________________________________________ ffmpeg-user mailing list ffmpeg-user at mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Hi, Sorry that I missed your mail for quite some time. I could never get libpthreadGC2.a to be detected so I renamed it to libpthread.a. I thought the dependency order was gcc's known behavior? I'll try linking directly to the dll as suggested in the mean time. Thanks.
JonY wrote:
Ramiro Polla wrote:
Hello,
JonY wrote:
I never installed the static lib, 'make clean GC' and 'make clean GC-static' both produce libpthreadGC2.a (along with pthreadGC.dll only for GC). There are no other import libs produced.
Sorry. I hadn't seen that pthreads-win32 does: dlltool -k --dllname pthreadGC2.dll --output-lib libpthreadGC2.a ^^^^^^^^^^^^^^^
So what I thought was static is in fact an import lib, with a name different from what other libraries use.
This works: $ cd pthreads-w32-2-8-0-release $ make clean GC $ cp pthread.h sched.h /mingw/include $ cp pthreadGC2.dll /mingw/lib/libpthread.dll $ cd ../ffmpeg $ ./configure --enable-memalign-hack --enable-gpl --enable-pthreads --enable-libx264
Use pthreadGC2.dll to link to instead of libpthreadGC2.a. If binutils can't resolve the dependencies in some other order, that's a bug on their side.
If you have a good reason to not follow this (use the dll directly to link to), you may try issuing a bug report for M?ns to fix. I doubt you'll get his sympathy though.
Ramiro Polla
_______________________________________________ ffmpeg-user mailing list ffmpeg-user at mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Hi,
Sorry that I missed your mail for quite some time. I could never get libpthreadGC2.a to be detected so I renamed it to libpthread.a.
I thought the dependency order was gcc's known behavior? I'll try linking directly to the dll as suggested in the mean time.
Thanks.
Hi, Linking directly to the dll seems to work, are there any known side effects from skipping the import library? Thanks for helping.
JonY wrote:
Hi,
Linking directly to the dll seems to work, are there any known side effects from skipping the import library?
*Read http://sourceware.org/binutils/docs-2.18/ld/WIN32.html "*Given the massive improvements in memory requirements during linking, storage requirements, and linking speed, we expect that many developers will soon begin to use this feature [linking directly to dlls] whenever possible."
On Sat, Oct 13, 2007 at 11:33:58AM -0300, Ramiro Polla wrote:
JonY wrote:
Hi,
Linking directly to the dll seems to work, are there any known side effects from skipping the import library?
*Read http://sourceware.org/binutils/docs-2.18/ld/WIN32.html
to use static pthreads you need x264 with static pthread and attached patch, ffmpeg.c patch can be safely added to upstream, the configure change is a quick hack to make it work on my compile. I have same problem while building mplayer I think there is no way to detect if pthread it's static but an idea can be passing PTW32_STATIC_LIB as extra defines or an option like --enable-pthreadw32-static or something like Bye -- Gianluigi Tiesi <sherpya at netfarm.it> EDP Project Leader Netfarm S.r.l. - http://www.netfarm.it/ Free Software: http://oss.netfarm.it/
Gianluigi Tiesi wrote:
On Sat, Oct 13, 2007 at 11:33:58AM -0300, Ramiro Polla wrote:
JonY wrote:
Hi,
Linking directly to the dll seems to work, are there any known side effects from skipping the import library?
*Read http://sourceware.org/binutils/docs-2.18/ld/WIN32.html
to use static pthreads you need x264 with static pthread and attached patch, ffmpeg.c patch can be safely added to upstream, the configure change is a quick hack to make it work on my compile. I have same problem while building mplayer I think there is no way to detect if pthread it's static but an idea can be passing PTW32_STATIC_LIB as extra defines or an option like --enable-pthreadw32-static or something like
Bye
------------------------------------------------------------------------
_______________________________________________ ffmpeg-user mailing list ffmpeg-user at mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Hi, thanks for the patch, but I'm not planning to use static pthreads any time soon. Patch to ffmpeg.c looks OK. The problem arises due to how gcc parses for import library dependency during the lix264 test. The attached patch is more portable but it is the best I can come up with. I have only basic understanding of bash scripting. It still looks a bit messy but works for now. Comments and improvements welcome. It checks if "$targetos" is mingw AND if pthread is enabled. If so add -lpthread after -lx264. I can't speak for non-mingw builds, so this patch will only affects mingw users. It shouldn't break ffmpeg if a non-pthread enabled libx264 is used but pthread is enabled for ffmpeg, or if pthread is totally unused at all. Also, I saw this warning, "#warning You must include stdint.h or inttypes.h before x264.h" in config.err, unrelated but is it OK to ignore it?
participants (3)
-
10walls＠gmail.com -
mplayer＠netfarm.it -
ramiro＠lisha.ufsc.br