x264项目编译

Question

I had downloaded the source of x264 library .

The version of x264 is 148.

For compilation of shared dlls I am using the following command under MSYS Environment:

./configure --disable-cli --enable-shared --prefix=.

The result is following:

platform:      X86_64
byte order:    little-endian
system:        WINDOWS
cli:           no
libx264:       internal
shared:        yes
static:        no
asm:           yes
interlaced:    yes
avs:           no
lavf:          no
ffms:          no
mp4:           no
gpl:           yes
thread:        win32
opencl:        yes
filters:       crop select_every
debug:         no
gprof:         no
strip:         no
PIC:           yes
bit depth:     8
chroma format: all

After execution of make I have the following error:

common/win32thread.o:win32thread.c:(.text+0x60): undefined reference to `_beginthreadex'
common/win32thread.o:win32thread.c:(.text+0x60): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_beginthreadex'
collect2: error: ld returned 1 exit status
Makefile:192: recipe for target 'libx264-148.dll' failed
make: *** [libx264-148.dll] Error 1

My working Environment:

1. Windows 10 Pro
2. MSYS64 with mingw64
3. Microsoft Visual Studio 2015

The configure command was executed without errors, but the make gives me the error described above.

Answer 1

GCC is built by MSYS2/MinGW with different configurations, and bundled with different versions of MinGW-w64 headers/libs.

• MSYS2 only provides the posix thread model (pthreads); dwarf for i686, seh for x86_64.
• MinGW provides posix and win32 thread models; sjlj and dwarf for i686, seh and sjlj for x86_64.

Ergo, MSYS applications need to be built using the pthreads library. You can force an MSYS build of x264 to use the posix thread model, instead of the win32 model like this:

$ ./configure --disable-cli --enable-shared --disable-win32thread

platform: X86_64
byte order: little-endian
system: WINDOWS
cli: yes
libx264: internal
shared: yes
static: no
asm: yes
interlaced: yes
avs: avisynth
lavf: no
ffms: no
mp4: no
gpl: yes
thread: posix
opencl: no
filters: crop select_every
lto: no
debug: no
gprof: no
strip: no
PIC: yes
bit depth: all
chroma format: all

You can run 'make' or 'make fprofiled' now.

The problem is, there is no msys/winpthreads package, so you would first need to cross-compile pthreads-win32 for MSYS2.

---

Having said all that, you say

For compilation of shared dlls

and not

For compilation of .so shared libraries

So this seems like an xY problem to me. I think you should be using MSYS to cross-compile x264 like this:

$ ./configure --host=x86_64-w64-mingw32 --disable-cli --enable-shared --cross-prefix=x86_64-w64-mingw32-

(I would also use --prefix=/usr/local , as well as --disable-opencl for compatability with FFmpeg.

Answer 2

./configure --enable-shared --enable-static --disable-thread

I had the same problem. It works with disabled thread.

Answer 3

I used the following option:

./configure --disable-cli --enable-shared 

But didn't wanted to disable threads, so, what I did is modified win32thread.c like this:

Before:

  #if HAVE_WINRT
  /* _beginthreadex() is technically the correct option, but it's only available for Desktop applications.
   * Using CreateThread() as an alternative works on Windows Store and Windows Phone 8.1+ as long as we're
   * using a dynamically linked MSVCRT which happens to be a requirement for WinRT applications anyway */
  #define _beginthreadex CreateThread
  #define InitializeCriticalSectionAndSpinCount(a, b) InitializeCriticalSectionEx(a, b, CRITICAL_SECTION_NO_DEBUG_INFO)
  #define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
  #else
  #include <process.h>
  #endif

After

  #define _beginthreadex CreateThread

  #if HAVE_WINRT
  #define InitializeCriticalSectionAndSpinCount(a, b) InitializeCriticalSectionEx(a, b, CRITICAL_SECTION_NO_DEBUG_INFO)
  #define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
  #endif

Basically, I replaced _beginthreadex by Windows' native CreateThread . Not sure it's a huge problem for x264, but now I can compile.