RE: OK to stop using .def files for Windows builds with gcc?

[Tor Lillqvist <tml iki fi>]

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