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

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

On 13/10/2003 5:31 AM, Tor Lillqvist wrote:

- Internal functions used by several compilation units in the library (which thus can't be static) won't be visible anyway.

Does the libtool option -export-symbols-regex work on Windows? GTK passes this option on platforms other than Windows to limit which symbols are exported (it's effectiveness varies from platform to platform).

If so, you could alter configure.in to always pass -export-symbols-regex, which would also have the benefit that the list of exported symbols would be the same on Windows and Linux (which also means that if there was breakage on Windows related to exported symbols there would likely be breakage on Linux too, which would be give a greater incentive to fix things).

James.

On Mon, 2003-10-13 at 03:49, James Henstridge wrote:

Does the libtool option -export-symbols-regex work on Windows? GTK passes this option on platforms other than Windows to limit which symbols are exported (it's effectiveness varies from platform to platform).

If nothing else, isn't it true that all non-static functions beginning with _ should not be exported and all others should be exported, so the .defs should be fully automatable in the same way exports on Linux are, no?

Havoc

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

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

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.c which are not build for win32 or #if 0 ed symbols, which it simply does not detect either.

As others (and yourself) have pointed out, the best approach is to work from object or archive files.

Is it really the case that MSVC can't create DLLs without .def files ? I'm pretty sure I've seen DLLs created with MSVC with no .def files.

Arno