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

[Owen Taylor <otaylor redhat com>]

On Sun, 2003-10-12 at 17:31, Tor Lillqvist wrote: 
> I am getting tired of maintaining the .def files that list entry
> points exported by DLLs. Gcc doesn't really need them anyway. If you
> don't give it any .def file, it exports all global symbols, just like
> Unix compilers/linkers traditionally work. (All the Windows binaries
> of GLib, GTK, GIMP etc distributed from www.gimp.org/win32 are built
> with gcc.)
> 
> The benefits of using .def files are:
> - Building with MSVC needs them, so
> - you can be sure gcc and MSVC builds produce equivalent DLLs
> - Internal functions used by several compilation units in the library
>   (which thus can't be static) won't be visible anyway.
> 
> But keeping them up-to-date is a pain. When you are told that some
> entry point is missing, it's painful to have to tell the user "wait
> for the next release." On the other hand, building and releasing
> intermediate snapshot binaries is not clean or fun either. There is
> always the possibility that some GPL bigot demands an exactly
> corresponding source tarball too, and producing such can be really
> tiresome on Windows.
> 
> Opinions? Hans, are you listening? If I stop maintaining .def files,
> will you keep them up-to-date? Don't you have some automatic
> header-sniffing script for this?

I think the question of whether to keep the .defs files around
is mostly between you and Hans. But a few thoughts:

As James points out, for Unix, we mostly handle intra-module use of
symbols with _gtk prefixing and libtool. This should be extensible
to mingw gcc, though probably not to MSVC.

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.

This would make sure that we never release a GTK+ with missing
symbols.

Regards,
						Owen