GNOME Bugzilla – Bug 557305
.lib files for GStreamer should be built on Windows
Last modified: 2010-03-09 12:14:34 UTC
Alter configure script to generate libtool which would call Microsoft's lib.exe tool to create lib-files to be linked while developing GStreamer applications in MSVC. Other information: Patch to configure: *** configure Fri Oct 3 01:54:25 2008 --- configure.my Tue Oct 21 18:14:49 2008 *************** *** 8651,8657 **** echo EXPORTS > $output_objdir/$soname.def; cat $export_symbols >> $output_objdir/$soname.def; fi~ ! $CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib' else ld_shlibs=no fi --- 8651,8663 ---- echo EXPORTS > $output_objdir/$soname.def; cat $export_symbols >> $output_objdir/$soname.def; fi~ ! $CC -shared --output-def $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib;~ ! tmpcdir=$(pwd);~ ! fname=$(echo $soname | sed -e 's/.dll//');~ ! cd $(pwd)/$output_objdir;~ ! cp $soname.def $fname.def;~ ! lib /machine:i386 /def:$fname.def /out:$fname.lib || echo "lib failed";~ ! cd $tmpcdir;~' else ld_shlibs=no fi Patch is flawed however: 1) because MSys mangles file names and paths, it is impossible (or not?) to call /def:<absolute or relative file name>. Instead current directory has to be changed before a call to lib (which then could be called with /def:<file name>), and restored back afterward 2) file name is being extracted from $soname (shouldn't it be available as a separate variable?) 3) script assumes that .dll is the library extension (not critical, as it will only work on Windows anyway) 4) script creates a copy of $soname.def (is it really necessary? I don't know, maybe naming the .lib file accordingly is enough, never tested) 5) /machine:i386 is hardcoded (should be defined by a variable?) 6) script creates "libXXX-major.minor-0.lib" instead of "libXXX-major.minor.lib". I don't know where the zero comes from (nano?), as dll files don't have it.
Created attachment 129823 [details] A script for .lib-generation Since we can't rely on libtool for that, we have to use lib.exe. Also, one of the libtool devs suggested that it would be best to supply .def files instead of actual .lib files, because with lib.exe it is always possible to create import libraries. So i made a script that does just that: * generates .lib files from .def files, and/or installs .def files (and .lib files if generated) in MSys. * generates .lib files from .def files in CMD. It could be possible to do the same thing via makefiles and such, but: 1) I have no idea how to do that 2) Makefiles can't be conveniently distributed along with .def files
Can't really say I entirely understand what this is about, but patching configure doesn't really seem like the right solution to me ..
Yeah, it isn't. Hence the python script i've made. Libtool developers told me that i should not rely on libtool for .lib generation, and that build-time .lib generation is not reliable by itself (it's more portable to generate .lib files from .def files on the machine where GStreamer-based software development will take place).
*** Bug 589880 has been marked as a duplicate of this bug. ***
Bug #589880 talks about generating .lib files the same way as GLib does. Maybe this is a better solution (or is it the same)?
Reopening as I can't see any open question for the reporter. If this is an issue that needs to be fixed, NEW would be appropriate, else WONTFIX.
Tobias: thanks for pinging the bug, but the question for the reporter was whether the solution in bug #589880 would be a better solution. The reporter is a developer and should be able to answer that.
I guess it can be closed as 'wontfix'. GLib uses separate set of makefiles that use cl.exe and other MS tools and are able to build GLib itself and its import libraries - obviously no one is going to take a burden to maintain such thing for GStreamer, so it's not a solution. The best way of fixing this bug is to add a separate vcproj that would do only one thing - generate .lib files from .def files (.lib files are only needed for MSVS users, and it's safe to assume that these users do have MSVS to build that vcproj). But since i'm not THAT interested in MSVS (and since i have my handy Python script in case i do need .lib import libraries again), i am not willing to tinker with Visual Studio. Ask the guy who maintains gstreamer/win32/* part of the source tree.
Closing as per last comment.