libtool
[Top][All Lists]
Advanced

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

Re: Some fixes for cygwin


From: Gary V. Vaughan
Subject: Re: Some fixes for cygwin
Date: 01 Jun 2002 15:01:37 +0100

Hi Chuck,

You'll be pleased to hear that your paperwork has arrived, and I am in
the process of committing your patches.

On Tue, 2002-05-07 at 01:04, Charles Wilson wrote: 
> I tried sending these to libtool patches, but it's been four days and 
> the moderator still hasn't allowed them to be posted,

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.

> so I'll try here. 
>   There are two patches; the next one will follow.
> 
> 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.

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

>      * cdemo/Makefile.am: the downside of unsetting
>      'allow_undefined_flag' -- we must include -no-undefined
>      in the _la_LDFLAGS variable.

This should already have been done for other hosts anyway.

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

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

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

Cheers,
        Gary. 
-- 
  ())_. Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk      
,_())____
  / )=  GNU Hacker          http://www.gnu.org/software/libtool  \'     
`&
`(_~)_  Tech' Author        http://sources.redhat.com/autobook  
=`---d__/




reply via email to

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