binutils build fails on Ubuntu 13.10

[gcsx]

Hello,

I'm trying to use a 100% fresh install of Ubuntu 13.10 hosted in VMware Workstation 10 on Windows 7 x64 to compile a x64 ffmpeg using your script but the compilation of binutils fails.

Here is the only informations I have :

gcc -DHAVE_CONFIG_H -I. -I../../../source/binutils-2.24.51/binutils -I. -I../../../source/binutils-2.24.51/binutils -I../bfd -I../../../source/binutils-2.24.51/binutils/../bfd -I../../../source/binutils-2.24.51/binutils/../include -DLOCALEDIR="\"/home/gc/sandbox/mingw-w64-x86_64/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT bucomm.o -MD -MP -MF .deps/bucomm.Tpo -c -o bucomm.o ../../../source/binutils-2.24.51/binutils/bucomm.c ../../../source/binutils-2.24.51/binutils/bucomm.c:130:7: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘VPARAMS’ fatal VPARAMS ((const char format, ...)) ^ ../../../source/binutils-2.24.51/binutils/bucomm.c:141:11: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘VPARAMS’ non_fatal VPARAMS ((const char format, ...)) ^ There is no build-log.txt file anywhere. The problem repeats after complete deletion of the sandbox.

Should I try another distrib? Which one did you used?

I'm downloading your precompiled toolchain. I'll update this as soon as I tried.

[Karnith]

Hi GSX,

have you installed build tools?

sudo apt-get install subversion texinfo cmake bison flex cvs yasm automake libtool git g++ curl zlib1g-dev

I would also install build-essential:

sudo apt-get install build-essential

I used Ubuntu for this also, but haven't done so in a while. Try This first, and if you still have an issue I'll look into what is going on.

Karnith

[gcsx]

Hi, Yes, the script asked me to some packages before being usable, but not build-essentials. I'm going to try this right now.

This in what I done in the meanwhile : I tried the precompiled toolchain, but I get some errors about the compiler not being able to compile DLL and a notice to check the MinGW installation.

Then, I ran MXE and let him build MinGW, then I rebound the script to this version, but I get this when compiling libiconv : libtool: compile: unrecognized option -DPACKAGE_VERSION_STRING=\"1.14\"' libtool: compile: Trylibtool --help' for more information.

[gcsx]

Re, I installed build-essential, checked for the other packaes, nuked the sandbox and called the script, but I still have the exactly same message...

Do you need any other information ?

[gcsx]

Here are some fresh news :

I installed MinGW x64 from package, tricked the script be manually creating compiler.done and rebound it to /usr/bin and /usr/bin/x86_64-w64-mingw32.

With this configuration, I can compile everything except x264.exe because of this error : /usr/bin/x86_64-w64-mingw32-gcc -o x264.exe x264res.o x264.o input/input.o input/timecode.o input/raw.o input/y4m.o output/raw.o output/matroska.o output/matroska_ebml.o output/flv.o output/flv_bytestream.o filters/filters.o filters/video/video.o filters/video/source.o filters/video/internal.o filters/video/resize.o filters/video/cache.o filters/video/fix_vfr_pts.o filters/video/select_every.o filters/video/crop.o filters/video/depth.o input/avs.o input/thread.o libx264.a -lshell32 -m64 -Wl,--nxcompat -Wl,--dynamicbase -lpthread libx264.a(osdep.o): dans la fonction « x264_threading_destroy »: /home/gc/sandbox/x86_64/x264/common/osdep.c:68: Undefined reference to « pthread_win32_thread_detach_np » /home/gc/sandbox/x86_64/x264/common/osdep.c:69: Undefined reference to « pthread_win32_process_detach_np » libx264.a(osdep.o): in the function « x264_threading_init »: /home/gc/sandbox/x86_64/x264/common/osdep.c:82: Undefined reference to « ptw32_processInitialized » /home/gc/sandbox/x86_64/x264/common/osdep.c:84: Undefined reference to « pthread_win32_process_attach_np » collect2: ld returned 1 exit status make: *\ [x264.exe] Error 1

I compiled pthread and winpthread and copied them to the MinGW's lib folder but they are ignored...

So I cheated again : I tricked the script and therefore I was forced to remove the --enable-x264 swotch...

With all these workarounds, I finally got my compiled ffmpeg, but without x264 and I need to copy libstdc++-6.dll, libgcc_s_sjlj-1.dll and libwinpthread-1.dll with the ffmpeg executables...

Anything ideas I could try?

[rdp]

Interesting. That is so odd since it seems to work fine here on 13.10... Anyway the script anticipates a mingw that has an internal copy of win32-pthreads. Maybe try uncommenting out this line so that it will build "its own secondary" version...

https://github.com/rdp/ffmpeg-windows-build-helpers/blob/master/cross_compile_ffmpeg.sh#L1043

On Fri, Feb 7, 2014 at 2:45 PM, gcsx notifications@github.com wrote:

Here are some fresh news :

I installed MinGW x64 from package, tricked the script be manually creating compiler.done and rebound it to /usr/bin and /usr/bin/x86_64-w64-mingw32.

With this configuration, I can compile everything except x264.exe because of this error : /usr/bin/x86_64-w64-mingw32-gcc -o x264.exe x264res.o x264.o input/input.o input/timecode.o input/raw.o input/y4m.o output/raw.o output/matroska.o output/matroska_ebml.o output/flv.o output/flv_bytestream.o filters/filters.o filters/video/video.o filters/video/source.o filters/video/internal.o filters/video/resize.o filters/video/cache.o filters/video/fix_vfr_pts.o filters/video/select_every.o filters/video/crop.o filters/video/depth.o input/avs.o input/thread.o libx264.a -lshell32 -m64 -Wl,--nxcompat -Wl,--dynamicbase -lpthread libx264.a(osdep.o): dans la fonction << x264_threading_destroy >>: /home/gc/sandbox/x86_64/x264/common/osdep.c:68: Undefined reference to << pthread_win32_thread_detach_np >> /home/gc/sandbox/x86_64/x264/common/osdep.c:69: Undefined reference to << pthread_win32_process_detach_np >> libx264.a(osdep.o): in the function << x264_threading_init >>: /home/gc/sandbox/x86_64/x264/common/osdep.c:82: Undefined reference to << ptw32_processInitialized >> /home/gc/sandbox/x86_64/x264/common/osdep.c:84: Undefined reference to << pthread_win32_process_attach_np >> collect2: ld returned 1 exit status make: *\ [x264.exe] Error 1

I compiled pthread and winpthread and copied them to the MinGW's lib folder but they are ignored...

So I cheated again : I tricked the script and therefore I was forced to remove the --enable-x264 swotch...

With all these workarounds, I finally got my compiled ffmpeg, but without x264 and I need to copy libstdc++-6.dll, libgcc_s_sjlj-1.dll and libwinpthread-1.dll with the ffmpeg executables...

Anything ideas I could try?

Reply to this email directly or view it on GitHubhttps://github.com/rdp/ffmpeg-windows-build-helpers/issues/31#issuecomment-34507136 .

[gcsx]

Hello,

@rdp : I just tried your suggestion, but I still get the undefined references. I can compile x264.exe if I remove --extra-cflags=-DPTW32_STATIC_LIB, but I would like to obtain a clean, single executable version and help you to find what's going on.

It should be useful if I tell you that: I tell the script to include non-free components. I installed the VMware integration tools on the VM, could this have an impact ?

I prepared the environment this way : Create the VM with an empty 30 GB HDD. Install Ubuntu from ISO. Install VMware tools Install git from apt-get. Git clone this repo in my home dir. sudo the script. apt-get all the packages requested by the script. sudo the script again. Press Y twice (accept ./sandox, accept non-free).

Did I done anything wrong?

[rdp]

Odd. I was able to reproduce the problem building binutils...weird, since it used to work [?] Anyway try it again with git master now... Thank you. -roger-

On Tue, Feb 11, 2014 at 3:34 PM, gcsx notifications@github.com wrote:

Hello,

@rdp https://github.com/rdp : I just tried your suggestion, but I still get the undefined references. I can compile x264.exe if I remove --extra-cflags=-DPTW32_STATIC_LIB, but I would like to obtain a clean, single executable version and help you to find what's going on.

It should be useful if I tell you that: I tell the script to include non-free components. I installed the VMware integration tools on the VM, could this have an impact ?

I prepared the environment this way : Create the VM with an empty 30 GB HDD. Install Ubuntu from ISO. Install VMware tools Install git from apt-get. Git clone this repo in my home dir. sudo the script. apt-get all the packages requested by the script. sudo the script again. Press Y twice (accept ./sandox, accept non-free).

Did I done anything wrong?

Reply to this email directly or view it on GitHubhttps://github.com/rdp/ffmpeg-windows-build-helpers/issues/31#issuecomment-34816870 .

[curtismachek]

@rdp I can confirm I was having this exact issue under the same environment yesterday.

Now, under Ubuntu 13.10, it gets further, although there is an issue with MinGW... this is the output.

MinGW-w64 compiler of some type or other already installed, not re-installing...

Building 32-bit ffmpeg... PKG_CONFIG_PATH=//sandbox/mingw-w64-i686/i686-w64-mingw32/lib/pkgconfig not svn Updating dlfcn-win32 since usually svn repo's aren't updated frequently enough... testing compiler: //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc -shared -o /tmp/test.dll /tmp/test.c ./configure: 153: ./configure: //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc: not found //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc could not create shared file with Windows API functions. Make sure your MinGW system is working properly.

making //sandbox/win32/dlfcn-win32 as $ PATH=//sandbox/mingw-w64-i686/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games make -j 1

Makefile:4: config.mak: No such file or directory make: *\ No rule to make target `config.mak'. Stop.

Any thoughts?

Curtis Machek

[rdp]

Did you nuke your sandbox folder first? you're using git master I presume?

On Wed, Feb 12, 2014 at 7:39 PM, curtismachek notifications@github.comwrote:

@rdp https://github.com/rdp I can confirm I was having this exact issue under the same environment yesterday.

Now, under Ubuntu 13.10, it gets further, although there is an issue with MinGW... this is the output.

MinGW-w64 compiler of some type or other already installed, not re-installing...

Building 32-bit ffmpeg... PKG_CONFIG_PATH=//sandbox/mingw-w64-i686/i686-w64-mingw32/lib/pkgconfig not svn Updating dlfcn-win32 since usually svn repo's aren't updated frequently enough... testing compiler: //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc -shared -o /tmp/test.dll /tmp/test.c ./configure: 153: ./configure: //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc: not found //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc could not create shared file with Windows API functions. Make sure your MinGW system is working properly.

making //sandbox/win32/dlfcn-win32 as $ PATH=//sandbox/mingw-w64-i686/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games make -j 1

Makefile:4: config.mak: No such file or directory make: *\ No rule to make target `config.mak'. Stop.

Any thoughts?

Curtis Machek

Reply to this email directly or view it on GitHubhttps://github.com/rdp/ffmpeg-windows-build-helpers/issues/31#issuecomment-34943003 .

[curtismachek]

I did.

The error above is actually not from a nuked sandbox, but with a nuked sandbox, it's the same result. It just takes longer to get there.

Curtis Machek

[rdp]

Interesting. Does the file //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc exist? does that file exist anywhere on your system?( i686-w64-mingw32-gcc) are you building from the root folder?

On Wed, Feb 12, 2014 at 7:39 PM, curtismachek notifications@github.comwrote:

@rdp https://github.com/rdp I can confirm I was having this exact issue under the same environment yesterday.

Now, under Ubuntu 13.10, it gets further, although there is an issue with MinGW... this is the output.

MinGW-w64 compiler of some type or other already installed, not re-installing...

Building 32-bit ffmpeg... PKG_CONFIG_PATH=//sandbox/mingw-w64-i686/i686-w64-mingw32/lib/pkgconfig not svn Updating dlfcn-win32 since usually svn repo's aren't updated frequently enough... testing compiler: //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc -shared -o /tmp/test.dll /tmp/test.c ./configure: 153: ./configure: //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc: not found //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc could not create shared file with Windows API functions. Make sure your MinGW system is working properly.

making //sandbox/win32/dlfcn-win32 as $ PATH=//sandbox/mingw-w64-i686/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games make -j 1

Makefile:4: config.mak: No such file or directory make: *\ No rule to make target `config.mak'. Stop.

Any thoughts?

Curtis Machek

Reply to this email directly or view it on GitHubhttps://github.com/rdp/ffmpeg-windows-build-helpers/issues/31#issuecomment-34943003 .

[curtismachek]

Ahh wiped the server. I was building from root too.

I've spun up a fresh server, running a build not from root at the moment - will advise results.

[curtismachek]

I didn't build from the root folder this time.

You'll have to forgive me - I'm usually just a PHP developer, so compiling code is not my forté.

I compiled from the root directory / (not the root folder /root/).

It compiled for about 20 minutes, then the console cleared and it spat this out...

Ok, done building MinGW-w64 cross-compiler... Building 32-bit ffmpeg... PKG_CONFIG_PATH=//sandbox/mingw-w64-i686/i686-w64-mingw32/lib/pkgconfig svn checking out to dlfcn-win32 A dlfcn-win32.tmp/test.c A dlfcn-win32.tmp/configure A dlfcn-win32.tmp/dlfcn.c A dlfcn-win32.tmp/COPYING A dlfcn-win32.tmp/testdll.c A dlfcn-win32.tmp/dlfcn.h A dlfcn-win32.tmp/README A dlfcn-win32.tmp/Makefile Checked out revision 37. testing compiler: //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc -shared -o /tmp/test.dll /tmp/test.c ./configure: 153: ./configure: //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc: not found //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc could not create shared file with Windows API functions. Make sure your MinGW system is working properly.

making //sandbox/win32/dlfcn-win32 as $ PATH=//sandbox/mingw-w64-i686/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games make -j 1

Makefile:4: config.mak: No such file or directory make: *\ No rule to make target `config.mak'. Stop.

That file you mentioned does NOT exist. The following files exist in the //sandbox/mingw0w64-i686/bin/ folder...

i686-w64-mingw32-addr2line i686-w64-mingw32-ar i686-w64-mingw32-as i686-w64-mingw32-c++filt i686-w64-mingw32-dlltool i686-w64-mingw32-dllwrap i686-w64-mingw32-elfedit i686-w64-mingw32-gprof i686-w64-mingw32-ld i686-w64-mingw32-ld.bfd i686-w64-mingw32-nm i686-w64-mingw32-objcopy i686-w64-mingw32-objdump i686-w64-mingw32-ranlib i686-w64-mingw32-readelf i686-w64-mingw32-size i686-w64-mingw32-strings i686-w64-mingw32-strip i686-w64-mingw32-windmc i686-w64-mingw32-windres

If you'd like, I can email you root SSH login info for this server environment.

Curtis

[rdp]

Interesting. If I build in the root, I run into "other" problems like

//sandbox/mingw-w64-i686/i686-w64-mingw32/bin/orcc.exe rogerdpack@roger-VirtualBox64:/$ wine //sandbox/mingw-w64-i686/i686-w64-mingw32/bin/orcc.exe wine: cannot find '//sandbox/mingw-w64-i686/i686-w64-mingw32/bin/orcc.exe' rogerdpack@roger-VirtualBox64:/$ //sandbox/mingw-w64-i686/i686-w64-mingw32/bin/orcc.exe wine: cannot find '//sandbox/mingw-w64-i686/i686-w64-mingw32/bin/orcc.exe' rogerdpack@roger-VirtualBox64:/$ //sandbox/mingw-w64-i686/i686-w64-mingw32/bin/orcc.exe^C rogerdpack@roger-VirtualBox64:/$ cd //sandbox/mingw-w64-i686/i686-w64-mingw32/bin/ rogerdpack@roger-VirtualBox64://sandbox/mingw-w64-i686/i686-w64-mingw32/bin$ ls ar bzless iconv.exe orc-bugreport.exe as bzmore ld orcc.exe bunzip2 c++ ld.bfd pkcs1-conv.exe bzcat certtool.exe libpng15-config psktool.exe bzcmp danetool.exe libpng-config ranlib bzdiff dlltool nettle-hash.exe sdl-config bzegrep g++ nettle-lfib-stream.exe sexp-conv.exe bzfgrep gcc nm speexdec.exe bzgrep gnutls-cli-debug.exe objcopy speexenc.exe bzip2 gnutls-cli.exe objdump srptool.exe bzip2recover gnutls-serv.exe ocsptool.exe strip rogerdpack@roger-VirtualBox64://sandbox/mingw-w64-i686/i686-w64-mingw32/bin$ wine ./orc orc-bugreport.exe orcc.exe rogerdpack@roger-VirtualBox64://sandbox/mingw-w64-i686/i686-w64-mingw32/bin$ wine ./orc orc-bugreport.exe orcc.exe rogerdpack@roger-VirtualBox64://sandbox/mingw-w64-i686/i686-w64-mingw32/bin$ wine ./orcc.exe No input file specified rogerdpack@roger-VirtualBox64://sandbox/mingw-w64-i686/i686-w64-mingw32/bin$ cd .. rogerdpack@roger-VirtualBox64://sandbox/mingw-w64-i686/i686-w64-mingw32$ wine bin/orcc.exe No input file specified rogerdpack@roger-VirtualBox64://sandbox/mingw-w64-i686/i686-w64-mingw32$ wine ./bin/orcc.exe No input file specified rogerdpack@roger-VirtualBox64://sandbox/mingw-w64-i686/i686-w64-mingw32$ wine //sandbox/mingw-w64-i686/i686-w64-mingw32/bin/orcc.exe wine: cannot find '//sandbox/mingw-w64-i686/i686-w64-mingw32/bin/orcc.exe' rogerdpack@roger-VirtualBox64://sandbox/mingw-w64-i686/i686-w64-mingw32$ wine /sandbox/mingw-w64-i686/i686-w64-mingw32/bin/orcc.exe No input file specified

So...maybe try it but from /tmp or some other folder than the root root? I'll also try it from the root and see if I can repro your problem...

On Thu, Feb 13, 2014 at 3:15 PM, curtismachek notifications@github.comwrote:

I didn't build from the root folder this time.

You'll have to forgive me - I'm usually just a PHP developer, so compiling code is not my forté.

I compiled from the root directory / (not the root folder /root/).

It compiled for about 20 minutes, then the console cleared and it spat this out...

Ok, done building MinGW-w64 cross-compiler... Building 32-bit ffmpeg... PKG_CONFIG_PATH=//sandbox/mingw-w64-i686/i686-w64-mingw32/lib/pkgconfig svn checking out to dlfcn-win32 A dlfcn-win32.tmp/test.c A dlfcn-win32.tmp/configure A dlfcn-win32.tmp/dlfcn.c A dlfcn-win32.tmp/COPYING A dlfcn-win32.tmp/testdll.c A dlfcn-win32.tmp/dlfcn.h A dlfcn-win32.tmp/README A dlfcn-win32.tmp/Makefile Checked out revision 37.

testing compiler: //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc -shared -o /tmp/test.dll /tmp/test.c ./configure: 153: ./configure: //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc: not found //sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc could not create shared file with Windows API functions. Make sure your MinGW system is working properly.

making //sandbox/win32/dlfcn-win32 as $ PATH=//sandbox/mingw-w64-i686/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games make -j 1

Makefile:4: config.mak: No such file or directory make: *\ No rule to make target `config.mak'. Stop.

That file you mentioned does NOT exist. The following files exist in the //sandbox/mingw0w64-i686/bin/ folder...

i686-w64-mingw32-addr2line i686-w64-mingw32-ar i686-w64-mingw32-as i686-w64-mingw32-c++filt i686-w64-mingw32-dlltool i686-w64-mingw32-dllwrap i686-w64-mingw32-elfedit i686-w64-mingw32-gprof i686-w64-mingw32-ld i686-w64-mingw32-ld.bfd i686-w64-mingw32-nm i686-w64-mingw32-objcopy i686-w64-mingw32-objdump i686-w64-mingw32-ranlib i686-w64-mingw32-readelf i686-w64-mingw32-size i686-w64-mingw32-strings i686-w64-mingw32-strip i686-w64-mingw32-windmc i686-w64-mingw32-windres

If you'd like, I can email you root SSH login info for this server environment.

Curtis

Reply to this email directly or view it on GitHubhttps://github.com/rdp/ffmpeg-windows-build-helpers/issues/31#issuecomment-35032890 .

[gcsx]

Hello,

@rdp I just tried with the latest master after nuking the sandbox and...

It worked! I obtained an all-static (no need to put any DLL along with the exe) x64 version of ffmpeg with non-free codecs, and without having to change anything in the script.

So the problem was just an outdated version of binutils?

[curtismachek]

Trying from /tmp and a non-root account. Will report back.

[curtismachek]

Same issue.

[rdp]

Ok I was able to get it to build fine from the root. Feel free to send on the credentials to rogerdpack@gmail.com

On Thu, Feb 13, 2014 at 4:41 PM, curtismachek notifications@github.comwrote:

Same issue.

Reply to this email directly or view it on GitHubhttps://github.com/rdp/ffmpeg-windows-build-helpers/issues/31#issuecomment-35040381 .

[curtismachek]

Looks like I got it to work. Did a couple things, not sure exactly which one fixed it but...

1. Used a root account, and built from /tmp, rather than /root or directly from /. I think this is what fixed it.
2. Increased the RAM on the box to 1GB from 512MB. Compiling on a DigitalOcean server.

Cheers, Curtis

[rdp]

Yeah for my DO boxes I typically have to add some extra "swap" space RAM (just in case you hadn't done that) which might allow you to do it on a 512MB one, just saying. Glad you got it to work. @gcsx yeah I think...so...though I don't quite understand it since it used to work. Guess I'm already at stage6 LOl http://4loc.wordpress.com/2010/03/13/the-six-stages-of-debugging/

On Sun, Feb 16, 2014 at 1:40 PM, curtismachek notifications@github.comwrote:

Looks like I got it to work. Did a couple things, not sure exactly which one fixed it but...

1.

Used a root account, and built from /tmp, rather than /root or directly from /. I think this is what fixed it. 2.

Increased the RAM on the box to 1GB from 512MB. Compiling on a DigitalOcean server.

Cheers, Curtis

Reply to this email directly or view it on GitHubhttps://github.com/rdp/ffmpeg-windows-build-helpers/issues/31#issuecomment-35211592 .

[gcsx]

@rdp Maybe pthread was updated independently of binutils

[rdp]

OK I did run into this today (when I accidentally forgot to auto mount my new swap partition) so I think we can declare lack of RAM the problem: Ok, done building MinGW-w64 cross-compiler...Building 32-bit ffmpeg... PKG_CONFIG_PATH=/root/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/lib/pkgconfig svn checking out to dlfcn-win32A dlfcn-win32.tmp/test.cA dlfcn-win32.tmp/configure A dlfcn-win32.tmp/dlfcn.c A dlfcn-win32.tmp/COPYING A dlfcn-win32.tmp/testdll.c A dlfcn-win32.tmp/dlfcn.h A dlfcn-win32.tmp/README A dlfcn-win32.tmp/Makefile Checked out revision 37. testing compiler: /root/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/bin/i686- w64-mingw32-gcc -shared -o /tmp/test.dll /tmp/test.c ./configure: 153: ./configure: /root/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i 686/bin/i686-w64-mingw32-gcc: not found /root/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc co uld not create shared file with Windows API functions. Make sure your MinGW system is working properly.

making /root/dev/ffmpeg-windows-build-helpers/sandbox/win32/dlfcn-win32 as $ PATH=/root/d ev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/bin:/usr/local/sbin:/usr/local/bin :/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games make -j 1

Makefile:4: config.mak: No such file or directory make: *\ No rule to make target `config.mak'. Stop. root@small1:~/dev/ffmpeg-windows-build-helpers# df -h df -h Filesystem Size Used Avail Use% Mounted on

On Wed, Feb 19, 2014 at 11:05 AM, gcsx notifications@github.com wrote:

@rdp https://github.com/rdp Maybe pthread was updated independently of binutils

Reply to this email directly or view it on GitHubhttps://github.com/rdp/ffmpeg-windows-build-helpers/issues/31#issuecomment-35528579 .

[rdp]

(if left pane works) for followers, nuking sandbox fixed this for me again today:

orphan-labels -DSTACK_ALIGNMENT=32 -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -o common/x86/dct-32.o common/x86/dct-32.asm yasm -I. -I. -O2 -DARCH_X86_64=0 -I./common/x86/ -f win32 -DPREFIX -Worphan-labels -DSTACK_ALIGNMENT=32 -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -o common/x86/bitstream-a.o common/x86/bitstream-a.asm yasm -I. -I. -O2 -DARCH_X86_64=0 -I./common/x86/ -f win32 -DPREFIX -Worphan-labels -DSTACK_ALIGNMENT=32 -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -o common/x86/sad-a.o common/x86/sad-a.asm yasm -I. -I. -O2 -DARCH_X86_64=0 -I./common/x86/ -f win32 -DPREFIX -Worphan-labels -DSTACK_ALIGNMENT=32 -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -o common/x86/pixel-32.o common/x86/pixel-32.asm rm -f libx264.a /Users/packrd/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/bin/i686-w64-mingw32-ar rc libx264.a common/mc.o common/predict.o common/pixel.o common/macroblock.o common/frame.o common/dct.o common/cpu.o common/cabac.o common/common.o common/osdep.o common/rectangle.o common/set.o common/quant.o common/deblock.o common/vlc.o common/mvpred.o common/bitstream.o encoder/analyse.o encoder/me.o encoder/ratecontrol.o encoder/set.o encoder/macroblock.o encoder/cabac.o encoder/cavlc.o encoder/encoder.o encoder/lookahead.o common/threadpool.o common/win32thread.o common/x86/mc-c.o common/x86/predict-c.o common/opencl.o encoder/slicetype-cl.o common/x86/const-a.o common/x86/cabac-a.o common/x86/dct-a.o common/x86/deblock-a.o common/x86/mc-a.o common/x86/mc-a2.o common/x86/pixel-a.o common/x86/predict-a.o common/x86/quant-a.o common/x86/cpu-a.o common/x86/dct-32.o common/x86/bitstream-a.o common/x86/sad-a.o common/x86/pixel-32.o /Users/packrd/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/bin/i686-w64-mingw32-ranlib libx264.a /Users/packrd/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc -o x264.exe x264res.o x264.o input/input.o input/timecode.o input/raw.o input/y4m.o output/raw.o output/matroska.o output/matroska_ebml.o output/flv.o output/flv_bytestream.o filters/filters.o filters/video/video.o filters/video/source.o filters/video/internal.o filters/video/resize.o filters/video/cache.o filters/video/fix_vfr_pts.o filters/video/select_every.o filters/video/crop.o filters/video/depth.o input/avs.o input/thread.o libx264.a -lshell32 -m32 -Wl,--large-address-aware -Wl,--nxcompat -Wl,--dynamicbase libx264.a(osdep.o): In function x264_threading_destroy': /Users/packrd/dev/ffmpeg-windows-build-helpers/sandbox/win32/x264/common/osdep.c:68: undefined reference topthread_win32_thread_detach_np' /Users/packrd/dev/ffmpeg-windows-build-helpers/sandbox/win32/x264/common/osdep.c:69: undefined reference to pthread_win32_process_detach_np' libx264.a(osdep.o): In functionx264_threading_init': /Users/packrd/dev/ffmpeg-windows-build-helpers/sandbox/win32/x264/common/osdep.c:82: undefined reference to ptw32_processInitialized' /Users/packrd/dev/ffmpeg-windows-build-helpers/sandbox/win32/x264/common/osdep.c:84: undefined reference topthread_win32_process_attach_np' collect2: error: ld returned 1 exit status make: *\ [x264.exe] Error 1

[Jan-E]

What happens if you rm -rf the x264 directory now and try to rebuild x264? I ran into the same errors when I tried this. I solved it by leaving out the --extra-cflags=-DPTW32_STATIC_LIB in the configure line.

There had been a change in the configure options for x264: https://mailman.videolan.org/pipermail/x264-devel/2016-January/011538.html [x264-devel] windows: Use native threads by default

After leaving out the --extra-cflags=-DPTW32_STATIC_LIB this is the result in config.h:

define HAVE_WIN32THREAD 1

define HAVE_THREAD 1

...

define HAVE_BEOSTHREAD 0

define HAVE_POSIXTHREAD 0

Another way to fix compilation is by explicitly including libpthread.a

--extra-cflags=-DPTW32_STATIC_LIB --extra-ldflags=-lpthread

I did not check yet if the end result differs between both fixes.

[rdp]

This just worked fine for me, does it still fail for you?