AW: ld --auto-import for cygwin and libtool

["Ralf Habacker" <Ralf dot Habacker at saght dot tessag dot com>]

> I've cc'd this for wide exposure.
>
> I'm looking for any tests that folk would like to see on Paul
> Sokolvsky's auto-import PE hack in order to consider it for inclusion in
> binutils. Libtool could benefit from this patch, as it would allow fully
> automatic dll building on cygwin, _but_ the patch should be widely
> available for that to be worth considering.
>
> Paul a while back made a rather neat hack to pe to allow automatic
> importing of symbols without needing decoration. This allows libraries
> to be built with out any decoration in the headers - ie in standard UNIX
> format. AFAIK the patch has languished due to no one reviewing it.
>
> So... I've spent some time putting it through it's paces, and it seems
> to work without any issues at all. There were some teething issue, due
> to the patch not being developed for Cygwin, but for pw32. Thats been
> resolved (see below).
>
> I'm very happy with the way the patch performs, it builds all the
> existing decorated code I could find without trouble, and quite happily
> builds fully non-decorated code. Ralf Habacker has built KDE 1 with it,
> with a modified libtool.
>
> I've uploaded to my homepage a modified libtool 1.4 that uses
> gcc -shared and Paul's auto-import ld. This libtool passes all tests
> including tests that fail with the current production cygwin code except
>
> 1) build-relink.test spits out
> "shlibpath_overrides_runpath should be set to yes."
> I'm not sure what that should be for cygwin, so I'm referring the
> question to the libtool list :]. I'm happy to dig further if the issue
> is a bug, but if setting this to yes is the correct action there's
> little to do :].
> 2) quote.test - which I have discussed in the copied email below.
>
> My homepage can currently be found at
> http://users.bigpond.net.au/robertc
>
> I've also uploaded a binutils src tarball with the modified ld. I've
> modified it a little further to avoid some cygwin dll symbols it was
> picking up by mistake. A patch for that against a recent binutils is
> there as well. My patch also differs from Paul's original in that I've
> left disabled the auto-image-base option, which can cause issues with
> cygwin, due to a issue previously discussed. That option isn't part of
> the auto-import logic and thus shouldn't be part of this discussion IMO.
> (And should not be enabled by default!).
>
> I may well have broken libtool stuff, and there are things that can be
> tidied a bit, but this should work for anyone with the modified ld. Also
> the ld indenting is probably naffed, but it should be good enough for
> review by anyone interested.

In a previous mail I told about segmentation faults with the auto-import ld
on compiling kde2-libs.
This segmentation fault is caused be xmalloc thich returns a zero pointer.
I have analysed the stackdump and recognized that the exception occured in
the cygwin dll in the mount_info::conv_to_win32_path function

0x610346a6 in mount_info::conv_to_win32_path (this=0x1a010000,
src_path=0x25ce914
"/home/Habacker/tmp/kde/kde-2/kdelibs/kdeui/.libs/libkdeui.la.closure",
dst=0x25ceb74 "¬V¼\031Ñ}C",  devn=@0x25cec84, unit=@0x25cec88,
flags=0x25ce6e4) at ../../../../src/winsup/cygwin/path.cc:1251

stackframe:
(gdb) l *0x6103468E
0x6103468e is in mount_info::conv_to_win32_path(char const *, char *,
unsigned long &, int &, unsigned
0x610329fc is in path_conv::check(char const *, unsigned int, suffix_info
const *)
0x61054087 is in _unlink (../../../../src/winsup/cygwin/sigproc.h:84).
0x6107f062 is in unlink
(../../../../../src/newlib/libc/syscalls/sysunlink.c:12).
0x419fc2 is in remove_output (./ldmain.c:158).
0x477135 is in xatexit_cleanup (xatexit.c:80).
0x4767c5 is in xexit (xexit.c:40).
0x46eb94 is in xmalloc (xmalloc.c:90).
0x46ebc0 is in xmalloc (xmalloc.c:104).
0x42bc29 is in pe_walk_relocs_of_symbol (pe-dll.c:943).
0x4256a6 is in pe_find_data_imports (ei386pe.c:847).
0x425931 is in gld_i386pe_after_open (ei386pe.c:902).
0x41f988 is in ldemul_after_open (ldemul.c:65).
0x417834 is in lang_process (ldlang.c:4112).
0x41aa54 is in main (./ldmain.c:353).
0x61003aca is in dll_crt0_1(void)
(../../../../src/winsup/cygwin/dcrt0.cc:859).

Unfortunally running ld with gdb causes a segmentation fault in gdb, so that
post mortem debugging isn't available.

Currently I'm unsure if this is a general ld problem or if it relates only
to the auto-import-feature. I can't link the kdelibs with a default ld
because kde compiling depends on the auto-import feature.

In the ld source (pe-dll.c:pe_find_data_imports()) I have read about
trashing memory and generation of duplicate symbols. Does this relay to this
error:

848               /* we replace original name with __imp_ prefixed, this
849               1) may trash memory 2) leads to duplicate symbol
generation.
850               Still, IMHO it's better than having name poluted. */

Can anyone tell, what I can do ?

>
> I'm not subscribed to binutils, but am to libtool - if you just reply to
> binutils I'll miss your reply.
>
> Rob
>
> ----- Original Message -----
> From: "Robert Collins" <robert.collins@itdomain.com.au>
> To: "Gary V.Vaughan" <gary@oranda.demon.co.uk>
> Sent: Monday, June 11, 2001 9:19 PM
> Subject: libtool that passes all tests
>
>
> > I'm down to depdemo-nofast with no failures. I think that by the time
> I
> > go to bed tonight I'll likely have a nearly-no-failures cygwin libtool
> > here. Are you interested in a tarball of such a thing (with a copy of
> > Paul's ld ?)
> >
> > (the failures are: quote.test is failing, "error on mkdir .libs" but I
> > think thats because cygwin returns an error when you mkdir an existing
> > directory - does unix return an error for that? build-relink.test is
> > also failing, and thats my current target. )
> >
> > I ask whether you want that in preference to a patch, because with the
> > MLB merge, I imagine that any patch will be outdated before I can
> blink.
> > Also I don't know if I've broken any other things or not :].
> >
> > I have one change that definately isn't a proper solution - and thats
> > the extra_LIBS thing I asked about on the list a few days ago. The
> .dll
> > needs to go in the search path, or the test script needs to add the
> > libs/extra dir to the normal path when the test is run on  cygwin, for
> a
> > proper solution.
> >
> > Of course, the ld needs proper peer review, but I figured that a fully
> > functional libtool would be a good starting point for saying "well it
> > seems to work" :]
> >
> > Rob
> >
>
>