[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some fixes for cygwin

From: Charles Wilson
Subject: Re: Some fixes for cygwin
Date: Sat, 01 Jun 2002 11:58:01 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2

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


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


    * demo/ use -all-static, not -static.
    * depdemo/ ditto
    * mdemo/ ditto
    * pdemo/ ditto

The 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.a (*)
   <prefix>foo.dll (**)
 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:
 Directory #2:

(*) 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
   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; already specifies everything we need to know:

# The name that we can dlopen(3).

# Names of this library.

# The name of the static archive.
# Directory that this library needs to be installed in:

(**) 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 -- 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


+  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'
-  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
I tried to narrow down the problem, but I'm not sure what the fix is.

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"
 if $prefix/bin/mdemo_static $prefix/lib/ $prefix/lib/; then :
@@ -44,4 +46,5 @@
 exit $status

reply via email to

[Prev in Thread] Current Thread [Next in Thread]