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

Michel Bardiaux mbardiaux
Wed May 9 11:42:28 CEST 2007


Diego Biurrun wrote:
> On Wed, May 09, 2007 at 05:21:48PM +0800, 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;
> 
> I thought this only applied to Cygwin..   Are you sure?

Its due to the dll search rule on Windows: first the directory where the 
exe is, then each directory on the $PATH. Since, in fine, you run MS-Win 
executables, whether under Mingw, Cygwin, or 'real' Windows, the rule 
applies in all 3 cases, so the installer should pander to it.

>  Anyway, the fix
> should be as simple as adding
> 
>     shlibdir="$bindir"
> 
> to the MinGW section around line 1153.
> 
>> dll.a doesn't get installed altogether.
> 
> Hmmm, this could be a problem.
> 
>> 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. Again this has nothing to do with
>> simultaneous building of both static and shared libraries.
> 
> Note that VS is unsupported, 

Since when? I thought VS was unsupported as platform to build ffmpeg, 
but that using lavu/c/f in VS projects *was* supported.

> but plain MinGW is supposed to work.
> 
> Diego


-- 
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/




More information about the ffmpeg-devel mailing list