Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-20 Thread Charles Wilson 
Ralf Wildenhues wrote:
 +# func_tr_sh
 +# turn $1 into a string suitable for a shell variable name
 +# result is stored in $func_tr_sh_result
 +func_tr_sh ()
 +{
 +  func_tr_sh_result=`echo $1 | $SED -e 's/[^A-Za-z0-9_]/_/g'`
 +  # ensure result begins with non-digit
 +  case $func_tr_sh_result in
 +[A-Za-z_][A-Za-z0-9_] ) ;;
 +* ) func_tr_sh_result=_$func_tr_sh_result ;;
 +  esac
 +}
  ]])
 
 Let's not waste processes when we don't have to, with something like
 this untested bit:
 
 func_tr_sh ()
 {
   case $1 in
 [!a-zA-Z_]* | *[!a-zA-Z_0-9]*)
   func_tr_sh_result=`$ECHO $1 | $SED 's/^[^a-zA-Z]/_/; 
 s/[^a-zA-Z0-9]/_/g'`
   ;;
 *)
   func_tr_sh_result=$1
   ;;
   esac
 }

Your version will confuse '1dumblibraryname.a' and '2dumblibraryname.a'
by turning both into '_dumblibraryname_a'.  How about this:

# func_tr_sh
# turn $1 into a string suitable for a shell variable name
# result is stored in $func_tr_sh_result.  All characters
# not in the set a-zA-z0-9_ are replaced with '_'. Further,
# if $1 begins with a digit, a '_' is prepended as well.
func_tr_sh ()
{
  case $1 in
  [0-9]* | *[!a-zA-Z_0-9]*)
func_tr_sh_result=`$ECHO $1 | $SED 's/^\([0-9]\)/_\1/;
s/[^A-Za-z0-9]/_/g'`
;;
  * )
func_tr_sh_result=$1
;;
  esac
}
Which makes it clear exactly what we're trying to do:
  1) replace all bad chars with _
  2) prepend _ if $1 begins with a digit
There is still a slight inefficiency in the above: IF $1 has all valid
characters, but happens to begin with a digit, then we fork a sed simply
to prepend the '_'. I doubt this will occur much. or ever -- and if it
does, the penalty is an extra fork, not wrong behavior.

 --- a/libltdl/config/ltmain.m4sh
 +++ b/libltdl/config/ltmain.m4sh
 
 @@ -1988,7 +1988,7 @@ extern \C\ {
eval '$GREP -f $output_objdir/$outputname.exp  $nlist  
 $nlistT'
eval '$MV $nlistT $nlist'
case $host in
 -*cygwin | *mingw* | *cegcc* )
 +*cygwin* | *mingw* | *cegcc* )
eval echo EXPORTS ' $output_objdir/$outputname.def'
eval 'cat $nlist  $output_objdir/$outputname.def'
;;
 
 Is this fixing a bug?  If yes, then it should be a separate patch,
 documented in the ChangeLog entry, done likely in all other such
 instances of missing '*' (I haven't found any), and would be obviously
 correct and ok to push.  Please, please don't mix heavy patches with
 such cleanups.  It only leads to cleanups being delayed.

It is not a bug fix, exactly. I just noticed the lack of symmetry, AND
that '*cygwin' never appears anywhere else, and figured it was a typo.
The actual cygwin $host patterns we see AFAIK all match *cygwin -- but
by convention we (libtool) allow extensions on triples for variant
$hosts. This violated that convention, but wasn't /exactly/ a bug.

I can prepare a separate patch and push, if you prefer.

 In your take 3 of this patch series, you have this hunk:
 
 | @@ -2217,7 +2217,7 @@ func_win32_libid ()
 |  ;;
 |*ar\ archive*) # could be an import, or static
 |  if eval $OBJDUMP -f $1 | $SED -e '10q' 2/dev/null |
 | -   $EGREP 'file format (pe-i386(.*architecture: 
 i386)?|pe-arm-wince|pe-x86-64)' /dev/null; then
 | +   $EGREP 'file format (pei?-i386(.*architecture: 
 i386)?|pe-arm-wince|pe-x86-64)' /dev/null; then
 |win32_nmres=`eval $NM -f posix -A $1 |
 | $SED -n -e '
 | 1,100{
 
 Now, my memory is really bad about win32 semantics, but wasn't it
 exactly pei-i386 libraries that we wanted to not match here?

Originally (before the introduction of [func_]win32_libid()), we had
pei*-i386:

 cygwin* | mingw* | pw32*)
  lt_cv_deplibs_check_method='file_magic file format
pei*-i386(.*architecture: i386)?'

When win32_libid() was first introduced, we moved the pei*-i386
incantation as-is into win32_libid():
grep -E 'file format pei*-i386(.*architecture: i386)?' /dev/null ; then
in 6da15e03aa1127eb42652a1f7e15ee42633dbfdf Thu Oct 31 00:52:39 2002

This was changed to
grep -E 'file format pe-i386(.*architecture: i386)?' /dev/null ; then
in 709bbb17317c67d28cf7ec8f0baaef16c4137ad0 Mon Feb 17 18:55:45 2003
Supposedly, this was part of a rewrite to improve speed. Looking at
the mailing list history from that era:
http://lists.gnu.org/archive/html/libtool-patches/2003-02/msg00048.html
No explanation was given for that particular change (my fault).

Looking at the original version of win32_libid() -- after 6da15e03 but
before 709bbb17 -- it originally did this:

  if eval $OBJDUMP -f $1 2/dev/null | \
 grep -E 'file format pei+-i386(.*architecture: i386)?' /dev/null ;
then
win32_libid_type=x86 DLL
  else
if eval $OBJDUMP -f $1 2/dev/null | \
  grep -E 'file format pei*-i386(.*architecture: i386)?' /dev/null
 then
  win32_libid_type=x86
  if eval file $1 2/dev/null | \
 grep -E 'ar archive' /dev/null; then
win32_libid_type=$win32_libid_type archive
if eval

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-19 Thread Ralf Wildenhues 
Hello Charles,

I haven't looked at your patches in detail yet, but a couple of things
caught my eye:

* Charles Wilson wrote on Sat, Jan 03, 2009 at 02:39:15AM CET:
 diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
 index 4bc304c..c4de91a 100644
 --- a/libltdl/config/general.m4sh
 +++ b/libltdl/config/general.m4sh
[...]
 +# func_tr_sh
 +# turn $1 into a string suitable for a shell variable name
 +# result is stored in $func_tr_sh_result
 +func_tr_sh ()
 +{
 +  func_tr_sh_result=`echo $1 | $SED -e 's/[^A-Za-z0-9_]/_/g'`
 +  # ensure result begins with non-digit
 +  case $func_tr_sh_result in
 +[A-Za-z_][A-Za-z0-9_] ) ;;
 +* ) func_tr_sh_result=_$func_tr_sh_result ;;
 +  esac
 +}
  ]])

Let's not waste processes when we don't have to, with something like
this untested bit:

func_tr_sh ()
{
  case $1 in
[!a-zA-Z_]* | *[!a-zA-Z_0-9]*)
  func_tr_sh_result=`$ECHO $1 | $SED 's/^[^a-zA-Z]/_/; 
s/[^a-zA-Z0-9]/_/g'`
  ;;
*)
  func_tr_sh_result=$1
  ;;
  esac
}

 --- a/libltdl/config/ltmain.m4sh
 +++ b/libltdl/config/ltmain.m4sh

 @@ -1988,7 +1988,7 @@ extern \C\ {
 eval '$GREP -f $output_objdir/$outputname.exp  $nlist  
 $nlistT'
 eval '$MV $nlistT $nlist'
 case $host in
 - *cygwin | *mingw* | *cegcc* )
 + *cygwin* | *mingw* | *cegcc* )
 eval echo EXPORTS ' $output_objdir/$outputname.def'
 eval 'cat $nlist  $output_objdir/$outputname.def'
 ;;

Is this fixing a bug?  If yes, then it should be a separate patch,
documented in the ChangeLog entry, done likely in all other such
instances of missing '*' (I haven't found any), and would be obviously
correct and ok to push.  Please, please don't mix heavy patches with
such cleanups.  It only leads to cleanups being delayed.


In your take 3 of this patch series, you have this hunk:

| @@ -2217,7 +2217,7 @@ func_win32_libid ()
|  ;;
|*ar\ archive*) # could be an import, or static
|  if eval $OBJDUMP -f $1 | $SED -e '10q' 2/dev/null |
| -   $EGREP 'file format (pe-i386(.*architecture: 
i386)?|pe-arm-wince|pe-x86-64)' /dev/null; then
| +   $EGREP 'file format (pei?-i386(.*architecture: 
i386)?|pe-arm-wince|pe-x86-64)' /dev/null; then
|win32_nmres=`eval $NM -f posix -A $1 |
| $SED -n -e '
| 1,100{

Now, my memory is really bad about win32 semantics, but wasn't it
exactly pei-i386 libraries that we wanted to not match here?

More generally, I have a feeling that this function is badly
conditioned: it needs adjustment fairly often, it is unclear to me which
cases exactly it tries to exclude (for starters: why is the file format
test needed at all?), and when things fail here, they do so very
unobviously for the libtool user.  These issues could IMVHO be
ameliorated by having some test cases that show the fine line between
import libraries that are acceptable, and static ones that are not.
So that when we port this to the next w32 system, we just have to run
the test suite and fix it until it passes.  What do you think?

Thanks,
Ralf

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-15 Thread Peter Rosin 

Den 2009-01-13 16:41 skrev Charles Wilson:

Peter Rosin wrote:

Den 2009-01-06 02:06 skrev Charles Wilson:

Maybe under that name. But a libbfd-ified version of impgen (as a
replacement for the IMO totally broken -- but part of mingw-utils-0.3 --
reimp program), that happens to also supply an --identify foo
--identify-ms functionality? Not so far-fetched.

Right, but it still seems as if this new fixed impgen tool is closer
to MinGW than to MSYS proper. However, as you say, better ask on a better
list...


After playing with this idea for a while, it made more sense actually to
separate the impgen2 functionality from the dllname stuff. It's not yet
ready for prime time (and I'm trying to keep it in sync with on-going
changes to dlltool in binutils HEAD), but I'll send my latest version of
 these new tools to you offlist.  They compile with both cygwin-gcc
(using libiberty and libbfd from 20080624), and with mingw-gcc-3.4.5
(not sure what binutils version I have; one of the more recent releases
from mingw/sourceforge I'm sure).


Works for import libs built by MSVC 2005, didn't test any other version.


I'm only saying that from the binutils p.o.v. it makes at least some
sence to report all imported dlls. At least optionally, but again, this
was just a minor point...


A new patch to binutils' dlltool was accepted that makes the following
changes to --identify:
  1) automatically determines -- and operates with -- MS-style or
binutils-style implibs


I thought that I did build three dependent libraries A-B-C using MSVC
and MinGW alternatingly  (MSVC for A and C, MinGW for B, or the other way
around) just for testing interoperability, but that was a long
time ago... And I'm not sure I really did it or if it worked. I guess
I should do it again (if I did it, otherwise I should just do it).


  2) by default, lists all imported DLLs
  3) new --identify-strict flag causes multiple imported DLLs to be
reported as an error
http://sourceware.org/ml/binutils/2009-01/msg00152.html


Cool.

I'm hoping for this to get into MSYS 1.0.11 (or 12...) so that we can
rely on its presence.

Cheers,
Peter

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-13 Thread Charles Wilson 
Peter Rosin wrote:
 Den 2009-01-06 02:06 skrev Charles Wilson:
 Maybe under that name. But a libbfd-ified version of impgen (as a
 replacement for the IMO totally broken -- but part of mingw-utils-0.3 --
 reimp program), that happens to also supply an --identify foo
 --identify-ms functionality? Not so far-fetched.
 
 Right, but it still seems as if this new fixed impgen tool is closer
 to MinGW than to MSYS proper. However, as you say, better ask on a better
 list...

After playing with this idea for a while, it made more sense actually to
separate the impgen2 functionality from the dllname stuff. It's not yet
ready for prime time (and I'm trying to keep it in sync with on-going
changes to dlltool in binutils HEAD), but I'll send my latest version of
 these new tools to you offlist.  They compile with both cygwin-gcc
(using libiberty and libbfd from 20080624), and with mingw-gcc-3.4.5
(not sure what binutils version I have; one of the more recent releases
from mingw/sourceforge I'm sure).

 Also, it will not fail for Vfw32.Lib, it will instead list the three
 dlls it imports (AVICAP32.dll, AVIFIL32.dll, MSVFW32.dll).
 Well, we probably want it to fail. 
 
 So, for the sake of argument, I agree that it should fail. But then I
 think it should fail in libtool, not in the tool that digs out the
 dll name(s) from the import library. But that's a minor point...

 Well, see this and the following thread:
 http://sourceware.org/ml/binutils/2008-11/msg00078.html
 
 I'm only saying that from the binutils p.o.v. it makes at least some
 sence to report all imported dlls. At least optionally, but again, this
 was just a minor point...

A new patch to binutils' dlltool was accepted that makes the following
changes to --identify:
  1) automatically determines -- and operates with -- MS-style or
binutils-style implibs
  2) by default, lists all imported DLLs
  3) new --identify-strict flag causes multiple imported DLLs to be
reported as an error
http://sourceware.org/ml/binutils/2009-01/msg00152.html

--
Chuck

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-05 Thread Charles Wilson 
Peter Rosin wrote:
 Den 2009-01-05 06:24 skrev Charles Wilson:
 Interesting! Meanwhile, I have done some experiments on my own, as I
 don't like the dependence on anything that comes with MinGW when
 dealing with libtool and MSVC.

I kind of suspected that. What about the attached?  This version needs
to link against libbfd and its dependencies -- so has to be compiled
using mingw gcc.  But if this executable was included as part of msys?

 (Speaking of dependencies, I don't think the current MinGW code
  in libtool requires 'file' to be present, and I don't think it is
  part of a minimal MSYS install. It's not in my install anyway.)

Only because its been over two years since msys 1.11 will be ready
RSN. It is intended that the file package be included in the minimal
1.11 install.

 I have found that for MSVC import libraries the simplest thing is
 to list the archive members to get to the dll name. I have tried
 with:
   lib -nologo -list $implib | grep -v '\.obj$' | sort -u
 or, in gnu speak:
   ar t $implib | grep -v '\.obj$' | sort -u

I noticed that, but wasn't sure if self-compiled (using MSVC) import
libraries were the same.

 This works for all troublesome implibs that you have listed above
 (at least those that I have easy access to, but I have at least one
 from each class of problems) and a few others. Except for MAPI.lib,
 but my MS provided dumpbin.exe (VS 2005) says
   MAPI.lib : warning LNK4048: Invalid format file; ignored
 for that one so I too think it is a pathological case.

Ack.

 Also, it will not fail for Vfw32.Lib, it will instead list the three
 dlls it imports (AVICAP32.dll, AVIFIL32.dll, MSVFW32.dll).

Well, we probably want it to fail. dlpreopen is supposed to work like
dlopen -- and you'd need to dlopen each of the three DLLs separately.
But if you -dlpreopen Vfw32.Lib, you'd need to determine which symbols
IN Vfw32.Lib came from which DLL, and generate three different groups in
you LT_LTX_*[] structure, to register those symbols with their effective
dlopen source:
   { AVICAP32.dll, 0 }
   {  symbols  }
   { AVIFIL32.dll, 0 }
   {  symbols  }
   { MSVFW32.dll, 0 }
   {  symbols  }
I don't think this is going to work well.

 Using MS tools (instead of file or objdump -f) to identify if a .lib
 is an import lib or a static lib seems to be trickier. One thing
 that appears to work is to look for an __IMPORT_DESCRIPTOR_* symbol,
 but that can obviously be thwarted by a devious (or ignorant) user...

That's ok. Rule #486: don't deliberately try to undermine your tools,
and then expect them to work.

 BTW, those symbols also identifies the imported dll (but that breaks
 when that which is imported isn't named foo.dll). E.g.
   dumpbin -symbols $lib | grep '| __IMPORT_DESCRIPTOR_'
 
 (output for Vfw32.Lib
   001  SECT2  notype   External |
 __IMPORT_DESCRIPTOR_MSVFW32
   001  SECT2  notype   External |
 __IMPORT_DESCRIPTOR_AVIFIL32
   001  SECT2  notype   External |
 __IMPORT_DESCRIPTOR_AVICAP32
 )
 
 or, in gnu speak:
   nm $lib | grep 'I __IMPORT_DESCRIPTOR_'
 (output for Vfw32.Lib
    I __IMPORT_DESCRIPTOR_MSVFW32
    I __IMPORT_DESCRIPTOR_AVIFIL32
    I __IMPORT_DESCRIPTOR_AVICAP32
 )

Yeah, I wanted to avoid assuming that non-libtool shared libraries
always in in *.dll, because many packages (especially ones that do
dlopen/dlpreopen) still name their modules foo.so even on
cygwin/mingw. Take ImageMagick, for instance.

 But...I also dislike for fixes to existing bugs, in existing platforms,
 to be held up by not-yet-in-master support for other compilers. So, can
 we get back to discussing the original patch, under the predicates of
 cygwin and mingw (not msvc) $hosts?
 
 Hey, I'm not opposed to the patch, I didn't intend to make that impression
 either, sorry if I did. I'm just trying to determine what needs to be
 done in the MSVC branch to keep up. Just poking and asking questions,
 so thank you very much for your valuable input!

Oh, ok.  Thanks.

--
Chuck

/* dllname.c -- tool to extract the name of the DLL associated with
   an import library.
   Copyright 2008 Charles S. Wilson

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA
   02110-1301, USA.  */

#include stdio.h
#include stdarg.h
#include bfd.h
#include ansidecl.h
#include unistd.h

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-05 Thread Peter Rosin 

Den 2009-01-05 06:24 skrev Charles Wilson:

Charles Wilson wrote:

Charles Wilson wrote:

Peter Rosin wrote:

I'm primarily trying to determine what impact this has on my
MSVC branch...

Ran some experiments on the libraries shipped with the Windows SDK. The
attached script worked ok on most of them. After eliminating the static
libraries and the import libraries to '*.dll' and '*.DLL' (241
successes in all), I'm left with the following 13 odd ducks:

These are correct, but are a reminder that import libraries exist for
objects other than those named foo.dll. So that's 5 more successes:

KSProxy.Lib :x86 archive import FOR ksproxy.ax
bthprops.lib :x86 archive import FOR bthprops.cpl
irprops.lib :x86 archive import FOR irprops.cpl
NetSh.Lib :x86 archive import FOR NETSH.EXE
WinSpool.Lib :x86 archive import FOR WINSPOOL.DRV

These are the true failures:

For the following 6 libraries, it is the LAST archive member with a
.idata$6 section, not the first one, that specifies the DLL.

GdiPlus.lib :x86 archive import FOR u.GdiplusStartup
MSTask.Lib :x86 archive import FOR .._setnetscheduleaccountinformat...@12
WS2_32.Lib :x86 archive import FOR ..inet_pton
ksuser.lib :x86 archive import FOR ..KsCreateTopologyNode
shell32.lib :x86 archive import FOR =.WOWShellExecute
windowscodecs.lib :x86 archive import FOR q.WICSetEncoderFormat_Proxy

This one imports symbols from multiple DLLs. One of them happens to be
in the last archive member, but...

Vfw32.Lib :x86 archive import FOR -.StretchDIB

I have no idea what this one is. objdump can't grok it:

MAPI.Lib :MAPI.Lib: Microsoft Visual C library
$ objdump -f MAPI.Lib
objdump: MAPI.Lib: File format not recognized

So that's 246 PASS, 8 FAIL.


So, I've prepared a patch for dlltool which adds an '--identify-ms'
flag, which modifies the behavior of the '--identify implib' option.
It searches for .idata$6 instead of .idata$7, AND attempts to
disambiguate between the one that specifies the DLL name and all the
other ones that list the symbols by inspecting the flags.

In almost all cases, the one that specifies the DLL name has the flag
value 0x0123
   SEC_ALLOC | SEC_LOAD | SEC_DATA | SEC_HAS_CONTENTS
The other ones have flag values 0x00204103
   SEC_ALLOC | SEC_LOAD | SEC_HAS_CONTENTS | SEC_IN_MEMORY | SEC_KEEP

This version of dlltool was able to operate on all of the import
libraries in the Windows SDK, except for:

MAPI.Lib: MAPI.Lib: Microsoft Visual C library
  === again, because bfd has no idea how to parse this one

Vfw32.Lib: Import library `Vfw32.Lib' specifies two or more dlls:
`MSVFW32.dll' and `AVIFIL32.dll'

And the following:

WebPost.Lib: x86 archive import FOR WEBPOST.DLL
ddao35.lib: x86 archive import FOR ddao35.dll
ddao35d.lib: x86 archive import FOR ddao35d.dll
ddao35u.lib: x86 archive import FOR ddao35u.dll
ddao35ud.lib: x86 archive import FOR ddao35ud.dll
More on these, later.

Note that this dlltool /succeeded/ on
GdiPlus.lib
MSTask.Lib
WS2_32.Lib
ksuser.lib  
shell32.lib
windowscodecs.lib
where the script in my previous post failed. Dlltool can handle the case
where the one that specifies the DLL name is not first.

The five new failures (where the script succeeded) are interesting. In
each case, the rule above (the one has flag value 0x0123, and
the others do not) was incorrect:


$ ~/dlltool.exe --identify WebPost.Lib --identify-ms
flags: 0x0123   datasize: 000c  data: 'WEBPOST.DLL'
  5745 4250 4f53 542e 444c 4c00   WEBPOST.DLL.

flags: 0x0123   datasize: 0010  data: ''
  0400 5770 4269 6e64 546f 5369 7465 4100 ..WpBindToSiteA.

/home/cwilson/dlltool: Import library `WebPost.Lib' specifies two or
more dlls: `WEBPOST.DLL' and `'


The error message is a little confusing: `WEBPOST.DLL' and `'? The
empty name is because the data contains the unprintable character \004
followed by '\0'.  Recall for symbols, the first two bytes are a
little-endian count. So this is symbol 0x0004. I *guess* I could check
that both offset 0 and offset 1 contain printable characters. But that's
still just a heuristic, because a really big DLL might have
  01my_symbol
where the first two bytes are 0x30 0x31 ('01') representing symbol
number 0x3130 or 12352.

But this wierd case occurs only when the import library appears to NOT
follow the pattern most of them do. In fact, in these five import
libraries, ALL of the .idata$6 sections have flag 0x0123, not just
the one we want.

But, what are they? Do we care?

The ddao35 libraries are the Microsoft JET 3.5 DAO C++ libraries, for
DOS-Win16 (!).  Microsoft shipped the Jet 4.0 libraries with WinME and
W2k, and recommends against using ones older than that. Do we care that
you won't be able to dlpreopen (or dlltool --identify) these ancient
import libraries?)

Webpost.Lib (-- webpost.dll) seems to be part of the Web Publishing
Wizard API. I

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-05 Thread Peter Rosin 

Den 2009-01-05 15:08 skrev Charles Wilson:

Peter Rosin wrote:

Den 2009-01-05 06:24 skrev Charles Wilson:
Interesting! Meanwhile, I have done some experiments on my own, as I
don't like the dependence on anything that comes with MinGW when
dealing with libtool and MSVC.


I kind of suspected that. What about the attached?  This version needs
to link against libbfd and its dependencies -- so has to be compiled
using mingw gcc.  But if this executable was included as part of msys?


Works for me (also works for import libs produced with the msvc branch).
How likely is dllname to make it into msys 1.11? Or will that have to
wait until 1.12? (I'm asking what you think, I know that definitive
answers to such questions are in short supply...)

However, from where I'm sitting adding a tool to MSYS proper that really
only benefits MSVC users (MinGW users could just as well have it
distributed with MinGW) seems a bit far fetched. Or? There are ways to
dig out the info using the dumpbin and lib programs, so it's not a
showstopper if this is not added to MSYS, even if the code in libtool
will be a wee bit longer. When there is an alternative, it seems even
more far fetched to have dllname added to MSYS. But *I* wouldn't say no
to it of course...

BTW, my libiberty is probably old, I had to take out the expandargv
call and add this CONST_STRNEQ definition:
#define CONST_STRNEQ(STR1,STR2) (strncmp (STR1, STR2 , sizeof (STR2) - 1) == 
0)


(Speaking of dependencies, I don't think the current MinGW code
 in libtool requires 'file' to be present, and I don't think it is
 part of a minimal MSYS install. It's not in my install anyway.)


Only because its been over two years since msys 1.11 will be ready
RSN. It is intended that the file package be included in the minimal
1.11 install.


Oh, ok. Good enough for me.


I have found that for MSVC import libraries the simplest thing is
to list the archive members to get to the dll name. I have tried
with:
  lib -nologo -list $implib | grep -v '\.obj$' | sort -u
or, in gnu speak:
  ar t $implib | grep -v '\.obj$' | sort -u


I noticed that, but wasn't sure if self-compiled (using MSVC) import
libraries were the same.


They are (at least mine...)


Also, it will not fail for Vfw32.Lib, it will instead list the three
dlls it imports (AVICAP32.dll, AVIFIL32.dll, MSVFW32.dll).


Well, we probably want it to fail. dlpreopen is supposed to work like
dlopen -- and you'd need to dlopen each of the three DLLs separately.
But if you -dlpreopen Vfw32.Lib, you'd need to determine which symbols
IN Vfw32.Lib came from which DLL, and generate three different groups in
you LT_LTX_*[] structure, to register those symbols with their effective
dlopen source:
   { AVICAP32.dll, 0 }
   {  symbols  }
   { AVIFIL32.dll, 0 }
   {  symbols  }
   { MSVFW32.dll, 0 }
   {  symbols  }
I don't think this is going to work well.


I don't really see why this is not going to work well, but I'm not a
heavy libltdl user (yet...) so I'm pretty ignorant on the subject.

So, for the sake of argument, I agree that it should fail. But then I
think it should fail in libtool, not in the tool that digs out the
dll name(s) from the import library. But that's a minor point...

Cheers,
Peter

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-05 Thread Peter Rosin 

Den 2009-01-04 03:35 skrev Charles Wilson:

Peter Rosin wrote:

I'm primarily trying to determine what impact this has on my
MSVC branch...

Den 2009-01-03 02:39 skrev Charles Wilson:
*snip*

+*cygwin* | *mingw* | *cegcc* )

We should strive to have fewer of these in ltmain.m4sh, not more.


Yep. But the problem is, there are really two BIG categories of
platforms: those that support ELF-semantics for shared libraries, and
those that support PE-DLL semantics. The differences between, say, HP
and Linux are in this regard much less significant than the differences
between win32 (cygwin, mingw, msvc, even wince) and any *nixoid. And
vice verse: cygwin and msvc are much more similar *with regards to the
construction of shared libraries* than they are different (even though
the implib/static lib formats are non-interchangeable).

I'm not sure it would be an improvement, exactly, but we could have a
libtool variable $LT_HOST_SUPPORTS_PE_DLL (or a function that takes
$host), and replace many of these
   case $host in
 *cygwin* | *mingw* | *cegcc* ) ... ;;
 everything else ) ... ;;
   esac
occurences with 'if host_supports_pe_dll ; then ... ; else ... ; fi'
Still ugly, but it means you only have to fix the case $host pattern
in one place.


I think it should be like it is for everything else, a separate control-
ling variable for stuff that seem orthogonal. Many of the case $host
constructs should probably be if test $LT_HOST_SUPPORTS_PE_DLL = yes
(with the variable in lower case to conform), but I'm sure there are
examples where the controlling variable should be named something else.

I think there is value in separating these things, it serves as
documentation of what pieces of ltmain.m4sh are connected to each
other. It also helps when something like the MSVC branch is added
as many, but not all, things are equal between MSVC and MinGW.

A central function would be a step back IMHO, as a MSVC exception
(or whatever exception) for some specific snippet of code would
probably get uglier.

It's not as if we are talking hundreds of new variables, my guess
would be ten or so. But that's without looking at the code for
quite some time...

That said, I'm still not objecting to this patch as is, one more
case $host is not going to kill us.

Cheers,
Peter

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-05 Thread Peter Rosin 

Den 2009-01-06 02:06 skrev Charles Wilson:

Maybe under that name. But a libbfd-ified version of impgen (as a
replacement for the IMO totally broken -- but part of mingw-utils-0.3 --
reimp program), that happens to also supply an --identify foo
--identify-ms functionality? Not so far-fetched.


Right, but it still seems as if this new fixed impgen tool is closer
to MinGW than to MSYS proper. However, as you say, better ask on a better
list...


Also, it will not fail for Vfw32.Lib, it will instead list the three
dlls it imports (AVICAP32.dll, AVIFIL32.dll, MSVFW32.dll).

Well, we probably want it to fail. dlpreopen is supposed to work like
dlopen -- and you'd need to dlopen each of the three DLLs separately.
But if you -dlpreopen Vfw32.Lib, you'd need to determine which symbols
IN Vfw32.Lib came from which DLL, and generate three different groups in
you LT_LTX_*[] structure, to register those symbols with their effective
dlopen source:
   { AVICAP32.dll, 0 }
   {  symbols  }
   { AVIFIL32.dll, 0 }
   {  symbols  }
   { MSVFW32.dll, 0 }
   {  symbols  }
I don't think this is going to work well.

I don't really see why this is not going to work well, but I'm not a
heavy libltdl user (yet...) so I'm pretty ignorant on the subject.


No, what I meant was: IF you constructed all that then it would work.
BUT there is no support currently in libtool for generating that kind of
thing from a single implib.  It would be very ugly indeed.  So, at
present if func_msvc_dll_for_implib returns a list of DLLs, what will
the caller actually do?  How will the caller know which symbols should
go with which DLL? Does it need to be stateful?

But weigh the cost/benefit: LOADS of new code to write, test, and debug
-- so that a pathological import lib that specifies imports from more
than one DLL can be -dlpreopened.  Is it worth it? What's the
opportunity cost -- what /other/ more useful things could that
developer-time be spent on?


Agreed.


So, for the sake of argument, I agree that it should fail. But then I
think it should fail in libtool, not in the tool that digs out the
dll name(s) from the import library. But that's a minor point...


Well, see this and the following thread:
http://sourceware.org/ml/binutils/2008-11/msg00078.html


I'm only saying that from the binutils p.o.v. it makes at least some
sence to report all imported dlls. At least optionally, but again, this
was just a minor point...

Cheers,
Peter

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-04 Thread Charles Wilson 
Charles Wilson wrote:
 Peter Rosin wrote:
 I'm primarily trying to determine what impact this has on my
 MSVC branch...

Ran some experiments on the libraries shipped with the Windows SDK. The
attached script worked ok on most of them. After eliminating the static
libraries and the import libraries to '*.dll' and '*.DLL' (241
successes in all), I'm left with the following 13 odd ducks:

These are correct, but are a reminder that import libraries exist for
objects other than those named foo.dll. So that's 5 more successes:

KSProxy.Lib :x86 archive import FOR ksproxy.ax
bthprops.lib :x86 archive import FOR bthprops.cpl
irprops.lib :x86 archive import FOR irprops.cpl
NetSh.Lib :x86 archive import FOR NETSH.EXE
WinSpool.Lib :x86 archive import FOR WINSPOOL.DRV

These are the true failures:

For the following 6 libraries, it is the LAST archive member with a
.idata$6 section, not the first one, that specifies the DLL.

GdiPlus.lib :x86 archive import FOR u.GdiplusStartup
MSTask.Lib :x86 archive import FOR .._setnetscheduleaccountinformat...@12
WS2_32.Lib :x86 archive import FOR ..inet_pton
ksuser.lib :x86 archive import FOR ..KsCreateTopologyNode
shell32.lib :x86 archive import FOR =.WOWShellExecute
windowscodecs.lib :x86 archive import FOR q.WICSetEncoderFormat_Proxy

This one imports symbols from multiple DLLs. One of them happens to be
in the last archive member, but...

Vfw32.Lib :x86 archive import FOR -.StretchDIB

I have no idea what this one is. objdump can't grok it:

MAPI.Lib :MAPI.Lib: Microsoft Visual C library
$ objdump -f MAPI.Lib
objdump: MAPI.Lib: File format not recognized

So that's 246 PASS, 8 FAIL.


But I wonder if these 8 failures are just pathological cases, and the
code embodied in the attached script is good enough -- assuming an
msvc-configured libtool is allowed to use file, objdump, nm, etc.

Doctor, func_dll_from_imp fails for library shell32.lib, so I can't
dlpreopen it...Ok, don't do that then.

NOTE:
I had to change the grep expression:
  *ar\ archive*) # could be an import, or static
if objdump -f $1 | sed -e '10q' 2/dev/null |
  grep -E 'file format pei?-i386(.*architecture: i386)?' /dev/null
; then

from ...pe-i386(... to ...pei?-i386(... so that some of the import
libraries were recognized as such. I'm not sure what the distinction
between pe-i386 and pei-i386 is, or what the implications of this
particular change would be.

FWIW, I think this sed script is safer than the other one, even at the
cost of an extra fork. Keeping the contents of each archive member on a
separate line, rather than merging them all together, just seems better.

--
Chuck
#!/bin/sh

DLLNAME_SECTION=.idata\$6

# mostly the same as libtool's function of the same name,
# except that it stores the result in an explicitly-accessible
# *_result variable. Still echos, tho.  Also, the grep -E 
# expression is slightly different: pe-i386 - pei?-i386
func_win32_libid ()
{
  func_win32_libid_result=unknown
  win32_fileres=`file -L $1 2/dev/null`
  case $win32_fileres in
  *ar\ archive\ import\ library*) # definitely import
func_win32_libid_result=x86 archive import
;;
  *ar\ archive*) # could be an import, or static
if objdump -f $1 | sed -e '10q' 2/dev/null |
  grep -E 'file format pei?-i386(.*architecture: i386)?' /dev/null ; then
  win32_nmres=`eval nm -f posix -A $1 2/dev/null |
sed -n -e '
1,100{
/ I /{
s,.*,import,
p
q
}
}'`
  case $win32_nmres in
import*) func_win32_libid_result=x86 archive import ;;
*)   func_win32_libid_result=x86 archive static;;
  esac
fi
;;
  *DLL*)
func_win32_libid_result=x86 DLL
;;
  *executable*) # but shell scripts are executable too...
case $win32_fileres in
*MS\ Windows\ PE\ Intel*)
  func_win32_libid_result=x86 DLL
  ;;
esac
;;
  esac
  echo $func_win32_libid_result
}

# same as libtool's, from master
func_win32_import_lib_p ()
{
case `func_win32_libid $1 2/dev/null | sed -e 10q` in
*import*) : ;;
*) false ;;
esac
}

# Odd. For some reason I can't capture this directly in
# backticks. So, use a level of indirection:
func_dll_for_imp_core ()
{
  objdump -s --section $DLLNAME_SECTION $1 2/dev/null |
sed '/^Contents of section '$DLLNAME_SECTION':/{
  # Place marker at beginning of archive member dllname section
  s/.*/MARK/
  p
  d
}
# These lines can sometimes be longer than 43 characters, but
# are always uninteresting
/:[ \t]*file format pe[i]\{,1\}-i386$/d
/^In archive [^:]*:/d
# Ensure marker is printed
/^MARK/p
# Remove all lines with less than 43 characters
/^.\{43\}/!d
# From remoaining lines, remove first 43 characters
s/^.\{43\}//' |
sed -n '
  # Join marker and all lines until next marker into a single line

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-04 Thread Charles Wilson 
Charles Wilson wrote:
 Charles Wilson wrote:
 Peter Rosin wrote:
 I'm primarily trying to determine what impact this has on my
 MSVC branch...
 
 Ran some experiments on the libraries shipped with the Windows SDK. The
 attached script worked ok on most of them. After eliminating the static
 libraries and the import libraries to '*.dll' and '*.DLL' (241
 successes in all), I'm left with the following 13 odd ducks:
 
 These are correct, but are a reminder that import libraries exist for
 objects other than those named foo.dll. So that's 5 more successes:
 
 KSProxy.Lib :x86 archive import FOR ksproxy.ax
 bthprops.lib :x86 archive import FOR bthprops.cpl
 irprops.lib :x86 archive import FOR irprops.cpl
 NetSh.Lib :x86 archive import FOR NETSH.EXE
 WinSpool.Lib :x86 archive import FOR WINSPOOL.DRV
 
 These are the true failures:
 
 For the following 6 libraries, it is the LAST archive member with a
 .idata$6 section, not the first one, that specifies the DLL.
 
 GdiPlus.lib :x86 archive import FOR u.GdiplusStartup
 MSTask.Lib :x86 archive import FOR .._setnetscheduleaccountinformat...@12
 WS2_32.Lib :x86 archive import FOR ..inet_pton
 ksuser.lib :x86 archive import FOR ..KsCreateTopologyNode
 shell32.lib :x86 archive import FOR =.WOWShellExecute
 windowscodecs.lib :x86 archive import FOR q.WICSetEncoderFormat_Proxy
 
 This one imports symbols from multiple DLLs. One of them happens to be
 in the last archive member, but...
 
 Vfw32.Lib :x86 archive import FOR -.StretchDIB
 
 I have no idea what this one is. objdump can't grok it:
 
 MAPI.Lib :MAPI.Lib: Microsoft Visual C library
 $ objdump -f MAPI.Lib
 objdump: MAPI.Lib: File format not recognized
 
 So that's 246 PASS, 8 FAIL.

So, I've prepared a patch for dlltool which adds an '--identify-ms'
flag, which modifies the behavior of the '--identify implib' option.
It searches for .idata$6 instead of .idata$7, AND attempts to
disambiguate between the one that specifies the DLL name and all the
other ones that list the symbols by inspecting the flags.

In almost all cases, the one that specifies the DLL name has the flag
value 0x0123
   SEC_ALLOC | SEC_LOAD | SEC_DATA | SEC_HAS_CONTENTS
The other ones have flag values 0x00204103
   SEC_ALLOC | SEC_LOAD | SEC_HAS_CONTENTS | SEC_IN_MEMORY | SEC_KEEP

This version of dlltool was able to operate on all of the import
libraries in the Windows SDK, except for:

MAPI.Lib: MAPI.Lib: Microsoft Visual C library
  === again, because bfd has no idea how to parse this one

Vfw32.Lib: Import library `Vfw32.Lib' specifies two or more dlls:
`MSVFW32.dll' and `AVIFIL32.dll'

And the following:

WebPost.Lib: x86 archive import FOR WEBPOST.DLL
ddao35.lib: x86 archive import FOR ddao35.dll
ddao35d.lib: x86 archive import FOR ddao35d.dll
ddao35u.lib: x86 archive import FOR ddao35u.dll
ddao35ud.lib: x86 archive import FOR ddao35ud.dll
More on these, later.

Note that this dlltool /succeeded/ on
GdiPlus.lib
MSTask.Lib
WS2_32.Lib
ksuser.lib  
shell32.lib
windowscodecs.lib
where the script in my previous post failed. Dlltool can handle the case
where the one that specifies the DLL name is not first.

The five new failures (where the script succeeded) are interesting. In
each case, the rule above (the one has flag value 0x0123, and
the others do not) was incorrect:


$ ~/dlltool.exe --identify WebPost.Lib --identify-ms
flags: 0x0123   datasize: 000c  data: 'WEBPOST.DLL'
  5745 4250 4f53 542e 444c 4c00   WEBPOST.DLL.

flags: 0x0123   datasize: 0010  data: ''
  0400 5770 4269 6e64 546f 5369 7465 4100 ..WpBindToSiteA.

/home/cwilson/dlltool: Import library `WebPost.Lib' specifies two or
more dlls: `WEBPOST.DLL' and `'


The error message is a little confusing: `WEBPOST.DLL' and `'? The
empty name is because the data contains the unprintable character \004
followed by '\0'.  Recall for symbols, the first two bytes are a
little-endian count. So this is symbol 0x0004. I *guess* I could check
that both offset 0 and offset 1 contain printable characters. But that's
still just a heuristic, because a really big DLL might have
  01my_symbol
where the first two bytes are 0x30 0x31 ('01') representing symbol
number 0x3130 or 12352.

But this wierd case occurs only when the import library appears to NOT
follow the pattern most of them do. In fact, in these five import
libraries, ALL of the .idata$6 sections have flag 0x0123, not just
the one we want.

But, what are they? Do we care?

The ddao35 libraries are the Microsoft JET 3.5 DAO C++ libraries, for
DOS-Win16 (!).  Microsoft shipped the Jet 4.0 libraries with WinME and
W2k, and recommends against using ones older than that. Do we care that
you won't be able to dlpreopen (or dlltool --identify) these ancient
import libraries?)

Webpost.Lib (-- webpost.dll) seems to be part of the Web Publishing
Wizard API. I can't find

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-03 Thread Peter Rosin 

Hi Chuck,

I'm primarily trying to determine what impact this has on my
MSVC branch...

Den 2009-01-03 02:39 skrev Charles Wilson:
*snip*

+   *cygwin* | *mingw* | *cegcc* )


We should strive to have fewer of these in ltmain.m4sh, not more...


+  func_warn Using fallback code to determine dllname for $1; consider updating 
binutils to version 2.20 (2.19.50.20081115), or newer.


I fail to find that version of binutils in Cygwin setup, so I guess the
fallback code will get exercised. The comments say that gcc adds the
dll name in .idata$7, and the fallback code makes use of this fact. How
stable is that? What happens if you generate an import library late (if
you only have the dll) with something that is not gcc? What if you have
an import library created by e.g. MSVC? Looking at a few import libs in
the Platform SDK suggests that MSVC uses .idata$6 instead. To me it
seems as if the dllname is in the last .idata segment, can't that be
scripted for a better fallback?

Hmm, looking at the the --identify patch for binutils, it seems that it
too simply dumps out .idata$7. That seems to be plain wrong for a whole
bunch of import libs out there in the wild.

Cheers,
Peter

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-03 Thread Charles Wilson 
Peter Rosin wrote:
 I'm primarily trying to determine what impact this has on my
 MSVC branch...
 
 Den 2009-01-03 02:39 skrev Charles Wilson:
 *snip*
 +*cygwin* | *mingw* | *cegcc* )
 
 We should strive to have fewer of these in ltmain.m4sh, not more.

Yep. But the problem is, there are really two BIG categories of
platforms: those that support ELF-semantics for shared libraries, and
those that support PE-DLL semantics. The differences between, say, HP
and Linux are in this regard much less significant than the differences
between win32 (cygwin, mingw, msvc, even wince) and any *nixoid. And
vice verse: cygwin and msvc are much more similar *with regards to the
construction of shared libraries* than they are different (even though
the implib/static lib formats are non-interchangeable).

I'm not sure it would be an improvement, exactly, but we could have a
libtool variable $LT_HOST_SUPPORTS_PE_DLL (or a function that takes
$host), and replace many of these
   case $host in
 *cygwin* | *mingw* | *cegcc* ) ... ;;
 everything else ) ... ;;
   esac
occurences with 'if host_supports_pe_dll ; then ... ; else ... ; fi'
Still ugly, but it means you only have to fix the case $host pattern
in one place.

 +  func_warn Using fallback code to determine dllname for $1;
 consider updating binutils to version 2.20 (2.19.50.20081115), or newer.
 
 I fail to find that version of binutils in Cygwin setup, so I guess the
 fallback code will get exercised.

Not exactly.  Background: the --identify option is supported only in
CVS. There has not yet been an official binutils release containing that
code. Furthermore, cygwin's official binutils, while based on a CVS
snapshot, is from 20080624.  So, no, if you want it you have to compile
it yourself.  Same for the mingw-provided binutils.

But, func_win32_dllname_for_implib is only ever called if we were unable
to find the .la file for the implib.  Normally, you'd do something like:

  -dlpreopen foo.la

and then, the libfile_$(transliterated implib name) stuff is used, not
func_win32_dllname_for_implib.  You only use that function if somebody did:

  -dlpreopen /path/to/foo.dll.a

(maybe because they had no .la file, or it was not installed by the
system packaging, or whatever).

BTW, I'm assuming that func_win32_import_lib_p() works for msvc, because
you've got the correct $file_magic_command for your toolchain
(whatever correct means)...

 The comments say that gcc adds the
 dll name in .idata$7, and the fallback code makes use of this fact. How
 stable is that?

For gcc dll's, very. Hasn't changed in over a decade. pe-ppc (as opposed
to pe-i386) uses .idata$6; a dlltool compiled for that toolchain
correctly inspects .idata$6. That's why this manual parsing stuff is
just a fallback; it'd be better to use a binary tool. But, for msvc, I
haven't even thought about trying to parse dumpbin output.

Can we (libtool?) provide binary utility programs to go along with msvc
to solve some of these issues?  Furthermore, can we even assume that
binutils progs like objdump and dlltool are available? Or file, for that
matter?

 What happens if you generate an import library late (if
 you only have the dll) with something that is not gcc? 

First, I'm assuming that you're not talking about mixing between
toolchains (e.g. if $CC is gcc, then the libs were generated by gcc/ld.
if $CC is cl, then the libs were generated by cl.exe.)

So, you're talking about completely non-gcc-based toolchains AND you're
dealing with an import library for which you have no .la file. In that
case you're stuck using func_win32_dllname_for_implib.  Now, dlltool
--identify (if you even HAVE dlltool) doesn't work with MSVC lib files
(I just checked). I could see different functions defined for each
toolchain, and then a libtool variable $pedll_dllname_for_implib_cmd
that points to the correct implementation for your toolchain. (mingw and
cygwin and probably cegcc would point to my implementation, whatever
it is renamed to).

But remember, this is all a corner case: dlpreopen of a shared library,
when you don't have an .la file. Otherwise, it ought to just work(tm).

 What if you have
 an import library created by e.g. MSVC? Looking at a few import libs in
 the Platform SDK suggests that MSVC uses .idata$6 instead.

Sortof. I see a LOT of .idata$6 entries. Most of them contain symbol
names at offset 2, and offset 0,1 contain a little-endian count. But the
one that has the DLL name starts at offset 0.  How are you supposed to
tell that 'MS' is actually the first two characters of a DLL name, and
not an indication that symbol 'VCR80.dll' is entry number 0x534d in the
symbol list?

Unless the first member of the archive is ALWAYS the one that will
specify the DLL, and you look in the .idata$LAST of that member.

I think it would be better NOT to try to generalize this, and instead go
the $LT_pedll_dllname_for_implib_cmd route above. If your msvc port can
use objdump, then the following works (and

[PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-02 Thread Charles Wilson 
* libltdl/config/general.m4sh: Adjust copyright date.
(func_tr_sh): New function.
* libltdl/config/ltmain.m4sh: Adjust copyright date.
(func_dlltool_identify): New function.
(func_win32_dllname_for_implib): New function.
(func_generate_dlsyms) [cygwin|mingw]: Obtain DLL name
corresponding to import library by using value stored in
unique variable libfile_$(transliterated implib name).
If that fails, use func_win32_dllname_for_implib to extract
DLL name from import library directly. Also, properly extract
dlsyms from the import library.
(func_mode_link) [cygwin|mingw]: Prefer to dlpreopen DLLs
over static libs when both are available.  When dlpreopening
DLLs, Use linklib (that is, import lib) as dlpreopen file,
rather than DLL. Store name of associated la file in
unique variable libfile_$(transliterated implib name)
for later use.
* libltdl/m4/libtool.m4: Adjust copyright date.
(_LT_COPYING): Adjust copyright date.
(_LT_CMD_GLOBAL_SYMBOLS): adjust sed expressions for
lt_cv_sys_global_symbol_to_c_name_address and
lt_cv_sys_global_symbol_to_c_name_address_lib_prefix
as trailing space after module name is optional.
(_LT_LINKER_SHLIBS) [cygwin|mingw][C++]:
Set exclude_expsyms correctly for $host. Simplify regular
expression in export_symbols_cmds.
(_LT_LINKER_SHLIBS) [cygwin|mingw|pw32][C]: Set exclude_expsyms
correctly for $host. Enable export_symbols_cmds to identify
DATA exports by _nm_ prefix.
---

This is a revised version of patch(es) posted here
http://lists.gnu.org/archive/html/libtool-patches/2008-11/msg00019.html
and here:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg1.html

In response to a bug reported here:
http://lists.gnu.org/archive/html/bug-libtool/2008-05/msg00054.html

Please see those threads for a discussion of the need for this
patch and the approach taken here. One change reflected in the
patch below, but not discussed in the preceeding threads, is 
that for systems-supporting-PE-DLLs (e.g. cygwin, mingw, cegcc),
the linker will automatically link against the import library 
instead of the static library if both are present in the search
path.  However, earlier versions of this patch -- and indeed, 
un-patched libtool -- would, in the both-are-present case,
extract symbols from the static library always, even tho the
final dlpreopen link was against the import library.

This situation led to an erroneous symbol list:

lt__PROGRAM__LTX_preloaded_symbols[] =
{  { @PROGRAM@, (void *) 0 },
  {libhello.a, (void *) 0},  HERE
  {nothing, (void *) nothing},
  {hello, (void *) hello},
  {foo, (void *) foo},
  {0, (void *) 0}
};

when the correct symbol list should be:

lt__PROGRAM__LTX_preloaded_symbols[] =
{  { @PROGRAM@, (void *) 0 },
  {cyghello-2.dll, (void *) 0},  HERE
  {nothing, (void *) nothing},
  {hello, (void *) hello},
  {foo, (void *) foo},
  {0, (void *) 0}
};

The patch below therefore modifies func_generate_dlsyms to
prefer the DLL/import library over the static library when
both are present -- but only for PE-DLL platforms. Other
platforms still prefer to dlpreopen static libraries when
both are present.

bootstrapped on cygwin, tested the
  demo-{conf|shared|static} + demo-make + demo-exec
test cases with success. Full test suite in progress.

=


 libltdl/config/general.m4sh |   15 +++-
 libltdl/config/ltmain.m4sh  |  198 ++-
 libltdl/m4/libtool.m4   |   16 ++--
 3 files changed, 201 insertions(+), 28 deletions(-)

diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 4bc304c..c4de91a 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -1,6 +1,6 @@
 m4_if([general.m4sh -- general shell script boiler plate -*- Autoconf -*-
 
-   Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
+   Copyright (C) 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
Written by Gary V. Vaughan, 2004
 
This file is part of GNU Cvs-utils.
@@ -412,5 +412,18 @@ func_show_eval_locale ()
   fi
 fi
 }
+
+# func_tr_sh
+# turn $1 into a string suitable for a shell variable name
+# result is stored in $func_tr_sh_result
+func_tr_sh ()
+{
+  func_tr_sh_result=`echo $1 | $SED -e 's/[^A-Za-z0-9_]/_/g'`
+  # ensure result begins with non-digit
+  case $func_tr_sh_result in
+[A-Za-z_][A-Za-z0-9_] ) ;;
+* ) func_tr_sh_result=_$func_tr_sh_result ;;
+  esac
+}
 ]])
 
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 20ca07b..503457c 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -5,7 +5,7 @@ m4_divert_push([SCRIPT])# @configure_input@
 # Written by Gordon Matzigkeit g...@gnu.ai.mit.edu, 1996
 
 # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
-# 2006, 2007, 2008 Free Software Foundation, Inc.
+# 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
 # This is free software; see the source for copying conditions.  There is NO
 # warranty; not even for MERCHANTABILITY or FITNESS

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

2009-01-02 Thread Charles Wilson 
Charles Wilson wrote:

 bootstrapped on cygwin, tested the
   demo-{conf|shared|static} + demo-make + demo-exec
 test cases with success. Full test suite in progress.

And...4.5 hours later, test suite results on cygwin (1.7.0-37, but that
shouldn't matter.  The good news is, cygwin-1.7 now handles missing DLL
errors without a GUI popup dialog. Un-attended testsuite execution on
Vista has been restored!)

old:
===
All 113 tests passed
(11 tests were not run)
===
SKIP: tests/cdemo-undef.test
SKIP: tests/tagdemo-undef.test
SKIP: tests/fcdemo-* == 9 tests


new:
76 tests behaved as expected.
5 tests were skipped.
 23: Java convenience archives skipped (convenience.at:230)
 27: shlibpath_overrides_runpath   skipped (shlibpath.at:54)
 41: GCJ inferred tag  skipped (infer-tag.at:84)
 52: ltdl API  skipped (ltdl-api.at:31)
 81: darwin fat compileskipped (darwin.at:42)

OK to push? Comments? Revisions?

--
Chuck