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

[Christof Petig <christof petig-baender de>]

Tor Lillqvist schrieb:
> 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.)

I can understand your position. (I didn't like patching (locally) the 
.def files either ;-) ). But the current 2.2 files are hiqh qualitiy! 
(no problem anywhere - I suspect Cedric Gustin has been here earlier).

> 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.

I'd suggest generating/updating them automatically with an optional 
black list (possible with dll-tool and fgrep -v IIRC)

> 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 usually use

dlltool $OBJS --export-all-symbols --output-def $NAME._def
sed -e 's|@ .*$||' <$NAME._def >>$NAME.def

for this (the second one fixes minor syntactic issues with my cross 
toolchain).
I really consider header sniffing too complicated for this.

Resume: Autogenerating seems to maintain the benefits while beeing 
constant work (O(1) as opposed to O(releases) previously).

   Christof