Use dlltools instead of lib.exe

Message ID 1300356902-25489-1-git-send-email-martin@martin.st
State Superseded
Headers show

Commit Message

Martin Storsjö March 17, 2011, 10:15 a.m.
From: Luca Barbato <lu_zero@gentoo.org>

This way building ffmpeg on mingw won't require windows specific tools
---
Tested that the output .lib files work with MSVC. (Only tested
building on linux but using the binaries in windows.)

I had to add -D to the dlltool parameters for the generated file
to work properly.

Also removed the - as dlltool always should be present.

 configure |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

Comments

Luca Barbato March 17, 2011, 10:55 a.m. | #1
On 3/17/11 11:15 AM, Martin Storsjö wrote:
> From: Luca Barbato<lu_zero@gentoo.org>
>
> This way building ffmpeg on mingw won't require windows specific tools
> ---
> Tested that the output .lib files work with MSVC. (Only tested
> building on linux but using the binaries in windows.)
>
> I had to add -D to the dlltool parameters for the generated file
> to work properly.
>
> Also removed the - as dlltool always should be present.

Thanks for the help =)

lu
Luca Barbato March 18, 2011, 4:25 p.m. | #2
On 03/17/2011 11:15 AM, Martin Storsjö wrote:
> From: Luca Barbato <lu_zero@gentoo.org>
> 
> This way building ffmpeg on mingw won't require windows specific tools
> ---
> Tested that the output .lib files work with MSVC. (Only tested
> building on linux but using the binaries in windows.)
> 
> I had to add -D to the dlltool parameters for the generated file
> to work properly.
> 
> Also removed the - as dlltool always should be present.

I'm about to enqueue this patch and commit it within the day, anybody
has more comments?

lu
Mans Rullgard March 18, 2011, 4:29 p.m. | #3
Luca Barbato <lu_zero@gentoo.org> writes:

> On 03/17/2011 11:15 AM, Martin Storsjö wrote:
>> From: Luca Barbato <lu_zero@gentoo.org>
>> 
>> This way building ffmpeg on mingw won't require windows specific tools
>> ---
>> Tested that the output .lib files work with MSVC. (Only tested
>> building on linux but using the binaries in windows.)
>> 
>> I had to add -D to the dlltool parameters for the generated file
>> to work properly.
>> 
>> Also removed the - as dlltool always should be present.
>
> I'm about to enqueue this patch and commit it within the day, anybody
> has more comments?

Seems fine to me as far as syntax goes.
Le Hong Dang July 6, 2011, 3:23 p.m. | #4
Hi,

On 3/18/2011 11:25 PM, Luca Barbato wrote:
> On 03/17/2011 11:15 AM, Martin Storsjö wrote:
>> From: Luca Barbato<lu_zero@gentoo.org>
>>
>> This way building ffmpeg on mingw won't require windows specific tools
>> ---
>> Tested that the output .lib files work with MSVC. (Only tested
>> building on linux but using the binaries in windows.)
>>
>> I had to add -D to the dlltool parameters for the generated file
>> to work properly.
>>
>> Also removed the - as dlltool always should be present.
> I'm about to enqueue this patch and commit it within the day, anybody
> has more comments?
>
> lu
>

Unfortunately, this change makes the built lib can not be used properly 
with MSVC 2008 (SP1).
I really don't know why but the lib can be used to build in debug mode 
without any notice problem,
but strange behaviors happen when we build our project (that uses libav) 
in release mode:
the build is completed successfully but when we run it will complain 
that it can not find 'some random function' from av*.dll
The 'random function' depends on how we order the input libs when 
linking and is often a function from another library,
for example, those exported functions from gdiplus.lib.
I think there should be something wrong with the produced av*.lib files 
that causes MSVC not to link properly.

We use mingw32 to build libav 0.7 on Windows 7 using MSVC 2008 SP1.

I'm lucky to follow this list so and know about this change so I quickly 
revert this change in the configure script and everything works as expected.

I write this email here just in case someone else face the same problem 
in the future.

Regards,
Le Hong Dang
Martin Storsjö July 6, 2011, 3:39 p.m. | #5
Hi,

On Wed, 6 Jul 2011, Le Hong Dang wrote:

> Unfortunately, this change makes the built lib can not be used properly 
> with MSVC 2008 (SP1).
> I really don't know why but the lib can be used to build in debug mode 
> without any notice problem,
> but strange behaviors happen when we build our project (that uses libav) 
> in release mode:

This is a known issue, and documented in the last paragraph at 
http://www.libav.org/general.html#Using-shared-libraries.

There is also a dlltool bug report at 
http://sourceware.org/bugzilla/show_bug.cgi?id=12633 about this issue.

// Martin
Le Hong Dang July 6, 2011, 3:50 p.m. | #6
On 7/6/2011 10:39 PM, Martin Storsjö wrote:
> This is a known issue, and documented in the last paragraph at
> http://www.libav.org/general.html#Using-shared-libraries.
>
> There is also a dlltool bug report at
> http://sourceware.org/bugzilla/show_bug.cgi?id=12633 about this issue.
>
> // Martin
> _______________________________________________
>
Oops, I should google before posting this.
Thanks for pointing out.
I'm just curious, why don't we reverse this commit like Michael did in 
ffmpeg?

Regards,
Le Hong Dang.
Martin Storsjö July 6, 2011, 3:59 p.m. | #7
On Wed, 6 Jul 2011, Le Hong Dang wrote:

> Thanks for pointing out.
> I'm just curious, why don't we reverse this commit like Michael did in 
> ffmpeg?

The point is that you're able to build a full version of libav for 
windows, including import libraries, without requiring any extra 
proprietary binaries from MSVC - a normal mingw toolchain is enough. If 
you want to link against it with gcc, it works just fine.

Only in MSVC in release mode (unless you add the /opt:noref option), 
there's an issue. If you need to link against it in MSVC, you can generate 
the import libraries yourself. (And hopefully, someone fixes the issue in 
dlltool.)

What could be further improved (which Luca talked about at the time but 
never finished) would be to export the .def files for the DLLs - then it 
would be even easier to create a new import library with lib.exe if you 
have got it. In practice - the one who needs to use these libraries in 
MSVC will have lib.exe, while the one building libav might not have it.

// Martin
Le Hong Dang July 6, 2011, 4:38 p.m. | #8
On 7/6/2011 10:59 PM, Martin Storsjö wrote:
>
> The point is that you're able to build a full version of libav for
> windows, including import libraries, without requiring any extra
> proprietary binaries from MSVC - a normal mingw toolchain is enough. If
> you want to link against it with gcc, it works just fine.
>
> Only in MSVC in release mode (unless you add the /opt:noref option),
> there's an issue. If you need to link against it in MSVC, you can generate
> the import libraries yourself. (And hopefully, someone fixes the issue in
> dlltool.)
>
> What could be further improved (which Luca talked about at the time but
> never finished) would be to export the .def files for the DLLs - then it
> would be even easier to create a new import library with lib.exe if you
> have got it. In practice - the one who needs to use these libraries in
> MSVC will have lib.exe, while the one building libav might not have it.
>
> // Martin
Ah, I see now. That really makes sense.
Adding .def files would be a good solution.
Thanks for your quick answer!

Best regards,
Luca Barbato July 7, 2011, 6:27 a.m. | #9
On 7/6/11 9:38 AM, Le Hong Dang wrote:
> Ah, I see now. That really makes sense.
> Adding .def files would be a good solution.
> Thanks for your quick answer!

I though I did already but _maybe_ just for some custom build,
please ping me after the 15th if nothing happens...

lu - still around USA...
Martin Storsjö July 8, 2011, 1:31 p.m. | #10
On Wed, 6 Jul 2011, Le Hong Dang wrote:

> Ah, I see now. That really makes sense.
> Adding .def files would be a good solution.
> Thanks for your quick answer!

The build system has been updated to install the .def files (and remove 
unnecessary installed DLLs), thanks to Måns, and the documentation has 
been updated (although the version on the website isn't regenerated yet) 
with explanations on how to generate new .lib files from the .def files if 
you want to use them with MSVC:

http://git.libav.org/?p=libav.git;a=blob;f=doc/general.texi;h=c97a7575c802e2755fbab804ca1fc150d9a18b40;hb=a3a94e1498685480800c22fc3ffa20d42ccfd527#l985

// Martin
Le Hong Dang July 8, 2011, 2:12 p.m. | #11
On 7/8/2011 8:31 PM, Martin Storsjö wrote:
> The build system has been updated to install the .def files (and remove
> unnecessary installed DLLs), thanks to Måns, and the documentation has
> been updated (although the version on the website isn't regenerated yet)
> with explanations on how to generate new .lib files from the .def files if
> you want to use them with MSVC:
>
> http://git.libav.org/?p=libav.git;a=blob;f=doc/general.texi;h=c97a7575c802e2755fbab804ca1fc150d9a18b40;hb=a3a94e1498685480800c22fc3ffa20d42ccfd527#l985
>
> // Martin

Kudos to you guys for making it available so fast!
I was also thinking about adding a parameter to configure whether 
dlltools or lib.exe should be use.



Regards,

Patch

diff --git a/configure b/configure
index 15d45a8..c1b26df 100755
--- a/configure
+++ b/configure
@@ -2418,7 +2418,7 @@  case $target_os in
         SLIBSUF=".dll"
         SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)'
         SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)'
-        SLIB_EXTRA_CMD='-lib.exe /machine:$(LIBTARGET) /def:$$(@:$(SLIBSUF)=.def) /out:$(SUBDIR)$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.lib)'
+        SLIB_EXTRA_CMD='$(DLLTOOL) -m $(LIBTARGET) -d $$(@:$(SLIBSUF)=.def) -l $(SUBDIR)$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.lib) -D $(SLIBNAME_WITH_MAJOR)'
         SLIB_INSTALL_EXTRA_CMD='-install -m 644 $(SUBDIR)$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.lib) "$(SHLIBDIR)/$(SLIBNAME:$(SLIBSUF)=.lib)"; \
             install -m 644 $(SUBDIR)$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.lib) "$(SHLIBDIR)/$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.lib)"; \
             install -d "$(LIBDIR)"; \
@@ -2426,6 +2426,7 @@  case $target_os in
         SLIB_UNINSTALL_EXTRA_CMD='rm -f "$(SHLIBDIR)/$(SLIBNAME:$(SLIBSUF)=.lib)"'
         SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def) -Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a) -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base'
         objformat="win32"
+        dlltool="${cross_prefix}dlltool"
         enable dos_paths
         check_cflags -fno-common
         check_cpp_condition _mingw.h "defined (__MINGW64_VERSION_MAJOR) || (__MINGW32_MAJOR_VERSION > 3) \
@@ -3235,6 +3236,7 @@  CPPFLAGS=$CPPFLAGS
 CFLAGS=$CFLAGS
 ASFLAGS=$ASFLAGS
 CC_O=$CC_O
+DLLTOOL=$dlltool
 LDFLAGS=$LDFLAGS
 FFSERVERLDFLAGS=$FFSERVERLDFLAGS
 SHFLAGS=$SHFLAGS