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

[Hans Breuer <Hans Breuer org>]

At 21:31 12.10.03 +0000, 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?
>
My very simple tool is not sniffing headers but C sources. It works
better than manually adding - but not much, especially not for
special case source files, e.g. gtk<plug|socket>.c  which are not
build for win32 or #if 0 ed symbols, which it simply does not 
detect either.

But the main problem apperas to do the complete def file tweaking at
the right point in time, i.e. shortly after the API freeze but before 
the official release. At least I have quite some synchronization
problems with my spare time.

It could be much simpler if the *nix(-like) build (make dist or even 
succesful make all) could generate the def file with the help of
	nm -B lib*.?
and some filtering, i.e. remove 'non portable' stuff like gtk_plug_*

Or even better : just do it only after the successful win32 build so 
there needs to be no extra filtering and MSVC users would have
all in place for a truly API compatible build Gtk+.

Thanks,
	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert