Re: Some fixes for cygwin

[Charles Wilson]

Gary V. Vaughan wrote:

> Thanks to the torrent of spam (mainly from Korea it seems) I have turned
> on member-only options on most of the lists I administer.  The plus side
> is that the signal to noise ratio on these lists is sensible once more,
> but unfortunately I don'y have the time to go through 50 or 60 (99% spam)
> non-member postings on 8 or 10 lists every day, and approve or reject
> each posting through the mailman interface.
>
> You can of course subscribe to the lists you wish to post to, and turn
> off delivery ofmail through mailman -- links from the libtool homepage.


Understood.  It's too bad gnu.org doesn't seem to use spamfilters on its 
end; this omission forces list-admins to use the members-only 
sledgehammer...


> > 2002-05-03  Charles Wilson  <address@hidden>
> >
> >     * libtool.m4: use $NM to create the symbol list on cygwin, not
> >     $ltdll_cmds as on mingw.  For all tags, (and host=cygwin) set
> >     allow_undefined_flag="" so that the --auto-import magic
> >     works properly.  For all tags (and host=cygiwn) set
> >     always_export_symbols=no -- it is unnecessary thanks to
> >     binutils' auto-export magic.
>
> Cool. Applied in principle... I have tried to trim your code a little
> thouugh.


'Kay.


> >     * libltdl/ltdl.c: Don't force cygwin to use the LoadLibrary
> >     wrapper; use cygwin's builtin implementatino of dl*.
>
> Fair enough.  I'll relent on this point now.  It is a very long time
> since I had any problems with the cygwin dlopen calls.


<g>


> >     * demo/configure.ac: use -all-static, not -static.
> >     * depdemo/configure.ac: ditto
> >     * mdemo/configure.ac: ditto
> >     * pdemo/configure.ac: ditto
>
> > The configure.ac changes:  libtool 'eats' the "-static" argument; you
> > have to feed "-all-static" to libtool, in order to convince it
> > to put "$link_static_flag" in the gcc command line.  Otherwise, 
> > hell_static.exe is actually linked to the DLL.  I suspect this is 
> > probably true on other platforms, too...
>
> Ah. No.  There must be a win32 based bug in libtool where it fails to tell
> the difference between an import library and a static lib.  The difference
> between -static and -all-static is that the former simply prefers the
> static build of a library, where -all-static forced an all static build 
> (including a complete static copy of libc for example).


I see.  So rather than relying on ld's ability to distinguish between 
implib and static lib, when linking (dynamically) to a libtool library, 
libtool itself should explicitly tell gcc "...  ../lib/libfoo.dll.a 
...", and when linking (statically) it should explicitly tell gcc "... 
../lib/libfoo.a ..." (and not -L../lib -lfoo).

>  We need to figure
> out how to teach libtool to recognise an import library for what it is --
> probably by naming convention.  Didn't we start to set things up to use
> libfoo-dll.a for import libs or something at one point?


Yep.  ".dll.a" == import lib extention.  ld already knows about this; it 
is true for all pei386 platforms that use GNU binutils/gcc: cygwin, 
mingw, pw, etc.   So, passing "-lfoo" to gcc/ld will result in ld 
searching for the following (if -Bdynamic):
 In directory #1
   libfoo.dll.a
   foo.dll.a
   libfoo.a (*)
   <prefix>foo.dll (**)
   libfoo.dll
   foo.dll
   libfoo.a
 In directory #2:
   <same search order as above>

Naturally, if you call ld with -Bstatic (for instance, because you 
called gcc with '-static'), then -lfoo will merely result in the 
following pattern:
 Directory #1:
   libfoo.a
 Directory #2:
   libfoo.a
 ...

(*) Yes, it searches for a "static lib" before trying to link directly 
to the DLL using DJ's on-the-fly-virtual-implib feature.  As explained 
in the binutils source code:

   Try libfoo.a next. Normally, this would be interpreted as a static
   library, but it *could* be an import library. For backwards
   compatibility,
   libfoo.a needs to ==precede== libfoo.dll and foo.dll in the search,
   or sometimes errors occur when building legacy packages.

   Putting libfoo.a here means that in a failure case (i.e. the library
   -lfoo is not found) we will search for libfoo.a twice before
   giving up -- once here, and once when searching for a "static" lib.

However, I don't believe these legacy issues should affect *libtool*. 
The legacy .a implib libraries -- at this point -- are now just things 
outside libtool's control:  libcygwin.a (an import lib for cygwin1.dll, 
despite the lack of a ".dll.a" suffix), for instance, is added to the 
link line by gcc's spec.  In ordinary operation (e.g. without 
--nostdlib) libtool doesn't itself search for -lcygwin.

So, teaching libtool to hunt for .dll.a itself is a safe (and smart) 
thing to do, IMO.  (I know, I know -- when using libtool .la libraries 
-- which is what we're talking about of course -- libtool doesn't need 
to "hunt" for the .dll.a; libfoo.la already specifies everything we need 
to know:

# The name that we can dlopen(3).
dlname='../bin/cygcharset-1.dll'

# Names of this library.
library_names='libcharset.dll.a'

# The name of the static archive.
old_library='libcharset.a'
...
# Directory that this library needs to be installed in:
libdir='/usr/local/lib'

(**) This prefix is set by the ld option, --dll-search-prefix.  On 
cygwin, gcc's spec file uses this option to set the prefix to "cyg". 
Thus, "cygfoo.dll".  This way we can avoid DLL namespace collision 
between the various unixish platforms on Windows -- if every such 
platform chooses (and uses) a different prefix.  Unfortunately, the most 
popular other "platform" -- mingw -- seems to have chosen "lib".  Phooey


> > build-relink2.test: This was one problem with the test -- libl3.la 
> > doesn't get installed into _inst/lib/extra, and it isn't supposed to. So 
> > look for it in the right place, _inst/lib/.  However, that didn't fix 
> > the OTHER problems that cygwin has with that test...
> > -    _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported
> > +    _LT_AC_TAGVAR(allow_undefined_flag, $1)=
>
> allow_undefined_flag="" is the default, so I simply removed the unsupported
> line. 


Okay.


> > +  cygwin*)
> > +    _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | 
> > $global_symbol_pipe | sed '\''s/.* //'\'' | sort | uniq > $export_symbols'
> > +  ;;
>
> This looks like a null operation to me.  cygwin is not matched elsewhere
> in the case statement so it picks up the default setting (identical to what
> you have set explicitly here.


Fair enough.  How about this, tho, for clarity (since mingw and cygwin 
stuff is intermingled a lot, but we *don't* want someone to helpfully 
add cygwin back to the mingw* | pw32* ) case later):

Index: libtool.m
===================================================================
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.258
diff -u -r1.258 libtool.m4
--- libtool.m4 1 Jun 2002 14:09:50 -0000  1.258
+++ libtool.m4 1 Jun 2002 15:35:53 -0000 
        @@ -4387,7 +4387,7 @@
       _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM -BCpg $libobjs 
$convenience | awk '\''{ if (((\[$]2 == "T") || (\[$]2 == "D") || (\[$]2 
== "B")) && ([substr](\[$]3,1,1) != ".")) { print \[$]3 } }'\'' | sort 
-u > $export_symbols'
     fi
     ;;
-  mingw* | pw32*)
+  mingw* | pw32*) # and not cygwin.  Cygwin uses the $NM incantation, below
     _LT_AC_TAGVAR(export_symbols_cmds, $1)="$ltdll_cmds"
   ;;
   *)


> > PASSED:  build-relink
> >
> > build-relink didn't get skipped like it used to be in 20020316-1.
> > We expect a failure here, and we got it -- so technically we PASSED
> > this test.  However, the failure mode was a Win32 popup "procedure 
> > entry point foo could not be located in the dynamic link library 
> > cyghello-2.dll" -- requiring manual intervention to dismiss the 
> > popup...
>
> I don't recall.  And there is no mention of this file in the ChangeLog.  Feel
> free to prove me wrong though ;-)


Well, it's not that big a deal.  Even if this test were skipped, you'd 
still have to monitor the tests -- some of the "real" failures, as with 
modules, generate the same popups and the user has to be there to 
dismiss those, anyway.

> mdemo-inst (mdemo-conf and mdemo-shared):
> -------------------
>
> modules are not installed in the path, nor are they in 
> the same directory as the executable.  So, the test 
> fails because windows can't find the installed DLL.  
> This is a testing error, not a real error.  Setting the 
> $PATH appropriately, and the test succeeds.  Should we
> install wrapper scripts into _inst/bin, or should 
> mdemo-inst.test explicitly set the PATH before attempting 
> to run the executable?


Whaddaya think?  I lean towards "fixing" mdemo-inst.test to set the PATH 
(sample -- but untested -- patch attached) Implication: in "real life", 
after installing a program that hides its modules in 
/usr/share/my_prog/, the user must add /usr/share/my_prog/ to her PATH, 
since my_prog relies on the windows runtime loader to "find" the modules 
(dlls) and PATH is the only way to tell the loader where to look(*). 
This is awkward, true -- but the alternative is to install wrapper 
scripts for "my_prog" that set the path -- but then the wrapper script 
can't be executed from Windows Explorer, while a "normal" exe can.


(*) or, we could always install modules into bindir on windows, which is 
where the executable will (presumably) be installed, thus guaranteeing 
that the windows runtime loader will find the modules even if "bindir" 
isn't in the path.  But that's so **ugly**.  The point of modules is to 
hide them somewhere OTHER than the main bindir...

Or (urgh) the "wrapper script" could be a wrapper *executable* that 
depends on no special libraries, but merely sets the PATH (by appending 
the compiled-in moduledir) and then exec's the real executable?  This 
wrapper *exe* could be run from Windows Explorer...

BTW, Gary -- can you take a look at this message
   http://mail.gnu.org/pipermail/libtool/2002-May/006289.html
I tried to narrow down the problem, but I'm not sure what the fix is.

--Chuck

Index: mdemo-inst.test
===================================================================
RCS file: /cvsroot/libtool/libtool/tests/mdemo-inst.test,v
retrieving revision 1.12
diff -u -r1.12 mdemo-inst.test
--- mdemo-inst.test     3 Mar 2002 03:19:55 -0000       1.12
+++ mdemo-inst.test     1 Jun 2002 15:45:11 -0000
@@ -24,6 +24,8 @@
 $make install || exit 1
 
 echo "= Executing installed programs"
+path_old=$PATH
+PATH=$prefix/lib:$PATH
 
 status=0
 if $prefix/bin/mdemo_static $prefix/lib/foo1.la $prefix/lib/libfoo2.la; then :
@@ -44,4 +46,5 @@
   status=1
 fi
 
+PATH=$path_old
 exit $status