[FFmpeg-devel] Why 'You can only build one library type at once on MinGW'?

[Michel Bardiaux]

Zuxy Meng wrote:
> Hi,
> 
> 2007/5/9, Michel Bardiaux <mbardiaux at mediaxim.be>:
>> Zuxy Meng wrote:
>>> Hi,
>>>
>>> 2007/5/9, Michel Bardiaux <mbardiaux at mediaxim.be>:
>>>> M?ns Rullg?rd wrote:
>>>>> "Zuxy Meng" <zuxy.meng at gmail.com> writes:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I don't understand. IIRC shared and nonshared objects are the same
>>>>>> under Windows,
>>>> No they're not.
>>> Any details?
>>>
>>>>>> while under Linux they're different (shared objects
>>>>>> needs to be compiled with -fPIC and access global data through %ebx?),
>>>> No, PIC is usually not required. PIC just guarantees the dso can be
>>>> relocated to any address. Without that its not possible to run when
>>>> there are conflicts of address ranges.
>>>>
>>>>>> so building the two simultaneously on Windows should be easier! I
>>>>>> removed that warning from configure and succeeded in building static
>>>>>> .a and dynamic .dll at the same time, and full test passed.
>>>>> Look a bit closer at those libraries.  IIRC the linker did some rather
>>>>> crazy things, but the details escape me.
>>>>>
>>>> When using the libraries in Visual-Studio, you need the dll *and* a
>>>> static lib that contains just the exported symbols.
>>>>
>>>> If the .a obtained is bigger than the dll, then its a 'normal' static
>>>> lib and the dll is useless. If it's small, it can be used to link to the
>>>> dll, but not on its own.
>>> Sure. Under each directory I got a .a, a .dll.a (import lib) and a
>>> dll. I don't see there're any problems.
>> It would indeed be nifty to be able to build both shared and static
>> together on mingw. But there is more to test: does make install work
>> correctly? Does linking to the .a work correctly in VisualStudio? Ditto
>> shared?
> 
> For shared libraries, make install on mingw never works, regardless
> whether we build static and shared libraries together or not: dlls
> gets installed under $PREFIX/lib, while it should go to $PREFIX/bin;
> dll.a doesn't get installed altogether.

So mingw is still broken (long time I tried) and requires lots of manual 
babysitting. Sigh. If it were on a Linux platform, it would have been 
fixed a long time ago.

> 
> I don't have a VS for checking right now, but IIRC the VS linker can't
> recognize .a (while mingw binutils can work well with .lib), not to
> mention .dll.a. You have to generate an import library manually by
> using the 'lib' program. 

The .dll.a *is* the export library. I think. Currently I dont have the 
time to try mingw again.

> Again this has nothing to do with
> simultaneous building of both static and shared libraries.

Seems you're right there.

> 
> BTW: I still wonder why objects (.o) for shared and static libraries
> differ in Windows. Can u explain a little bit to me or point me a URL
> explaining this?

Sorry, no.


-- 
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbardiaux at mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/