How to convert the libx264.a to libx264.lib

Question

I compile the x264 using the MinGW and get the libx264.a, but I will use it in visual c++ 2012, how can I convert it to libx264.lib?

Answer 1

You may not need a converter, depends on your library you can use it directly:

http://stackoverflow.com/questions/2096519/from-mingw-static-library-a-to-visual-studio-static-library-lib

---

Best regards

Bordon

Note: Posted code pieces may not have a good programming style and may not perfect. It is also possible that they do not work in all situations. Code pieces are only indended to explain something particualar.

Answer 2

I compile the x264 using the MinGW and get the libx264.a, but I will use it in visual c++ 2012

As a general rule, trying to link object code from different compilers or different versions
of the same compiler is prone to problems and not advisable, There is never any guarantee
of object code compatibility. Even if the link process succeeds without error messages,
there can be unforeseen and unpredictable results. Even if the resulting exe appears
to "work" without problems, there may be "hidden" conflicts which could have a negative
impact on reliability.

One common pitfall encountered concerns the lib file's own dependencies. A static lib
may itself be linked to its own dependencies - such as runtime library routines - via
either static libraries or dynamic libraries. That is, MyStatic.lib may call *compiler*
runtime library routines from either a static lib of those RTL functions or from a DLL.

So when MyStatic.lib is linked as part of a project to create an exe, the linker will either:

(a) Use the RTL code already present in this lib if its object modules were statically
linked to that compiler's RTL,

(b) Try to satisfy the external dependencies by invoking a DLL.

If this results in calls to a DLL which has different object code layouts, or conflicting
dependencies, or altered heap management, etc, as a result of using mismatched libraries
and object modules, the results are simply "undefined", unpredictable, and unreliable,

- Wayne

Answer 3

I agree strongly with Wayne. This is simply "a very bad idea". Why try to navigate through a minefield when there is a reliable road nearby...

Stick with one compiler for your application (unless you want to embrace COM or .NET which was explicitly designed to allow different compilers generate code that works with DLL from other compilers).

Answer 4

I compile the x264 using the MinGW and get the libx264.a, but I will use it in visual c++ 2012

As a general rule, trying to link object code from different compilers or different versions
of the same compiler is prone to problems and not advisable, There is never any guarantee
of object code compatibility. Even if the link process succeeds without error messages,
there can be unforeseen and unpredictable results. Even if the resulting exe appears
to "work" without problems, there may be "hidden" conflicts which could have a negative
impact on reliability.

One common pitfall encountered concerns the lib file's own dependencies. A static lib
may itself be linked to its own dependencies - such as runtime library routines - via
either static libraries or dynamic libraries. That is, MyStatic.lib may call *compiler*
runtime library routines from either a static lib of those RTL functions or from a DLL.

So when MyStatic.lib is linked as part of a project to create an exe, the linker will either:

(a) Use the RTL code already present in this lib if its object modules were statically
linked to that compiler's RTL,

(b) Try to satisfy the external dependencies by invoking a DLL.

If this results in calls to a DLL which has different object code layouts, or conflicting
dependencies, or altered heap management, etc, as a result of using mismatched libraries
and object modules, the results are simply "undefined", unpredictable, and unreliable,

- Wayne

So when I build the libx264.a to make it contain all dependent functions, it is OK?

Answer 5

So when I build the libx264.a to make it contain all dependent functions, it is OK?

Did you not read the *first* paragraph of my post?

You can never say with 100% certainty that it's OK, so you won't get any assurances from me.

My example regarding DLLs was as I stated: "*One* common pitfall". I never said that it was
the *only* one you might encounter. No matter how you build the lib, you will inevitably
have to try and have object code from VC++ interact with object code from MinGW. What will
happen in each case is unknown.

Can you say with certainty what happens when the MinGW code allocates memory from the heap?
Or frees it? Does a malloc call from MinGW work on the same heap, and with the same expectations,
as a malloc call from VC++? Are they using the same heap manager, or different ones?

Suppose the MinGW code uses _strdup at some point and the pointer that it returns is propagated
to the calling code from VC++? If your VC++ code subsequently does a free on that pointer,
will the heap be OK?

- Wayne

Answer 6

Yup.... it's a minefield. Wayne has articulated what a few of the mines look like, but there are many others undetected. Are you really sure you want to go in this direction?