In an earlier thread you (tml) once suggested that it would be nice to have an alternative to libtool on win32. I now have something that works with a few special cases - like libxml2-2.5.10 and libglade-2.0.1. It's written in perl and only support --mode=compile and --mode=link. I've atteched the perl code - it's not ready for general usage - but it can be used with mingw to build libraries that libtool fails to build. It also automatically generates *.def files for the libraries it builds. I don't mind building things with Mingw before building it with msvc - would this be a problem for all the others ?? BTW: For those who use mixed msvc 6/mingw builds - gettext and libiconv - and possibly some other libraries should be modified to use trio instead of the ms supplied implementations of stdio. This seems to remove a lot of otherwise nasty bugs - in particalar gettext/libintl works much better with trio. Best regards Espen Harlinn > Espen Harlinn writes: > > Could you not use dlltool/pexports to generate the def > files and put > them into the ditribution? > > Yes, something along those lines is what people have > suggested. I particularily liked Owen's suggestion: > > > I don't think it would be too hard to set things up so > that > on Linux, 'make check' makes sure that all exported > symbols for > libgtk are listed either in gtk.defs or in a > gtk-exclude.defs. > > I think it could be set up so that no .def files would be in > CVS, but they would be generated when a new GLib etc release > is built (on a Linux machine), and then included in the > official source tarballs. > > But this would mean that an "official" .def file would be > available only after each new release of GTK. When I and > others build from CVS before that, and want to be able to use > new functionality not yet in the .def file from the previous > release, would ld's auto-export then have to do? > > I just now tested building the GDK DLL without a .def file, > and the resulting DLL exported exactly one (1) symbol: > gdk_threads_mutex. This variable is marked with > __declspec(dllexport) in the sources, and "info ld" says: > > --export-all-symbols > If given, all global symbols in the objects used to build a DLL > will be exported by the DLL. Note that this is the default if > there otherwise wouldn't be any exported symbols. When > symbols are > explicitly exported via DEF files or implicitly exported via > function attributes, the default is to not export anything else > unless this option is given. > > libtool doesn't use that flag, which means that as there is > one explicitly exported symbol (gdk_threads_mutex, which > presumably has to be explicitly marked for export/import, as > it is a variable), ld won't export anything else. > > Passing -Wl,--export-all-symbols to the libtool --mode=link > command line fixes this. But this causes the symbols from the > non-GTK-related static libs to be exported, too: The symbols > from libie55uuid.a and libwntab32x.a, the GDK internal > symbols (those starting with _), and a couple of ones that > aren't marked as static, presumably by mistake: > current_dest_drag and event_poll_fd from gdk/win32 and > default_display from gdkdisplaymanager.c. > > The files from the archive libs can be taken care of using > ld's --exclude-libs flags. The GDK internal symbols are a bit > more problematic, as there are quite a lot of them, and they > would all have to be listed in an --exclude-symbols option. > Too complicated. But OK, it doesn't really matter, as this is > only when people like myself build from CVS. When building > from an officially released source tarball, the .def file > generated by the "make check" would be used. > > But what about those who woul want to build from CVS with > MSVC? (Hans and others.) That is still an open issue. > > I guess it is possible to set up Makefile.am to use the .def > file if present, otherwise -Wl,--export-all-symbols and > -Wl,--exclude-libs. > > So, to summarize: > > - It sounds like a good idea to generate the canonical .def files at > "make check" time when building a release. They would be included in > the source distribution. No .def files would be in CVS. > > - When building from CVS with mingw (i.e., gcc and GNU ld), no .def > file is needed. The resulting DLLs export some extra symbols, but as > DLLs built from CVS aren't supposed to be distributed, doesn't > matter. DLLs for distributions should be built from release > tarballs. > > - When building from CVS with MSVC, one still needs .def > files. This is > a problem. > > --tml > > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list gnome org > http://mail.gnome.org/mailman/listinfo/gtk-> devel-list >
Attachment:
libtool.zip
Description: Zip compressed data