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

[Hans Breuer <Hans Breuer org>]

At 22:47 14.10.03 +0000, Tor Lillqvist wrote:
>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:
>
If we really care for the win32/msvc build the only working approach
I see is to generate .def files from the binaries built on win32.
Generating them on *nix does partly work for gtk (minus gtk_plug + 
socket, which could be fixed by accepting my rotten patch).

But it can't work reliable for glib (g_win32_*) and even less for
gdk-win32 which won't be build on *nix at all.

Using 'nm -B' (or peexports or ?) on some intermediate file from the 
gcc/win32 build appears to be the only way (beside manually 
tweaking) which can produce the exact symbol list required.

BTW: the imaging library vips does use 'nm -B' during the *nix
build. It does work reasonable well cause the library does
have exact the same exported symboly on *nix and windoze.

> > 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.
>
As I have build from cvs for quite some while now (and kept the
.def files up to date for the msvc build) I would highly dislike
to banish them from cvs. 

Doing so would force all people to work on msvc to either depend 
on your officail builds or duplicate work. This sounds like
effectively dropping the msvc/build alltogether.
 
>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? 
>
Why not try to generate a better .def file with every successfull
mingw build - from the generated binaries - and check them in with 
the other necessary changes ?

> [...]
>But what about those who woul want to build from CVS with MSVC? (Hans
>and others.) That is still an open issue.
>
If the people doing the mingw build (only you?) do care something along
the line of (ripped from vips) :

#!/usr/bin/perl

# update vips.def from "nm" output of the installed
library
# 
# not very portable :-( eg mac os x and win32 will fail
horribly
# 
# pass in the install prefix ... or type "make vips.def"

open
DATA, "nm -B @ARGV[0]/lib/libvips.so |";

while( <DATA> ) {
	next if !
/^[a-f0-9]+ T (im_[a-zA-Z].*)$/ && 
		! /^[a-f0-9]+ T (error_exit)$/;
	push
@names, $1;
}

print "EXPORTS\n";
foreach $i (sort @names) {
	print
"\t$i\n";
}

>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.
>
Again, please don't remove them from 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.
>
Couldn't the sometimes generated (our even only sometimes updated
manually by me) file simply be kept in cvs ?

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