FYI: Libtool: Microsoft dumpbin as name lister
Ralf Wildenhues wrote on Wednesday, September 21, 2005 16:52 CEST: > > > I don't know which is best... Anyway, ignoring the somewhat strange > > > output for a bit, is this ok for HEAD? > > Yes, please install. Done. > Thanks, and sorry for the delay, No worries, but nice to strike something from the list... Cheers, Peter
Re: Libtool: Microsoft dumpbin as name lister
Hi Peter, * Peter Ekberg wrote on Wed, Sep 21, 2005 at 04:23:08PM CEST: > Ping, almost a month, I don't think I got a clear yes/no on this > One before the discussion wandered off. Only the suggestion to > detect Microsoft link seperately, but that's a much bigger change > and I'd like to do that later. Fair enough. > * Peter Ekberg wrote on Tuesday, August 23, 2005 07:29 CEST: > > > > This info made me look at the dumpbin-as-name-lister patch again > > and I found an issue with it... *snip* > > Anyway, the problem with the new checking msg is that the > > output from configure is a bit strange if nm is not found, > > but dumpbin is: > > > > checking for BSD- or MS-compatible name lister (nm)... no > > checking for dumpbin... dumpbin -symbols > > checking the name lister (dumpbin -symbols) interface... MS dumpbin > > > > However, the old message is strange when dumpbin is specified > > by the user with NM="dumpbin -symbols": > > > > checking for BSD-compatible nm... dumpbin -symbols > > checking the name lister (dumpbin -symbols) interface... MS dumpbin > > > > I don't know which is best... Anyway, ignoring the somewhat strange > > output for a bit, is this ok for HEAD? Yes, please install. Thanks, and sorry for the delay, Ralf > > 2005-08-23 Peter Ekberg <[EMAIL PROTECTED]> > > > > * libltdl/m4/libtool.m4 (LT_PATH_NM): Fix autodetection of > > dumpbin and also check for "link -dump -symbols" as a synonym > > for "dumpbin -symbols".
RE: Libtool: Microsoft dumpbin as name lister
Ping, almost a month, I don't think I got a clear yes/no on this
One before the discussion wandered off. Only the suggestion to
detect Microsoft link seperately, but that's a much bigger change
and I'd like to do that later.
Cheers,
Peter
* Peter Ekberg wrote on Tuesday, August 23, 2005 07:29 CEST:
> Tim Van Holder wrote:
> > >>>Regarding dumpbin not being present in the 2003 version, I
> > >>>*think* it's just missing from the free toolkit and that it is
> > >>>still going strong in "the real" releases of Visual Studio.
> > >>
> > >>OK. I just can't test it then.
> > >>
> > >>
> > Also, there seem to be third-party programs named `dumpbin'.
> > Does your1> test av oid them or do they work with
> > >>
> > >>your macro? Are
> > >>
> > >>>they in
> > >>>
> > wide-spread use? (We can just wait till someone reports
> > >>
> > >>a bug, if you
> > >>
> > don't know; but maybe you do, or I just missed that info.)
> > >>>
> > >>>Hmm, I was not aware of other dumpbins, so if they are similar
> > >>>there might be a problem.
> > >>
> > >>Completely untested (and no idea about trustworthiness):
> > >>http://www.freedownloadscenter.com/Best/coff-dumpbin.html
>
> I meant to mention (but forgot) that the executable in the
> above link appears to be named libdump (but I haven't actually
> installed it so I might be mistaken...)
>
> > >>>But, as the test is currently, the located dumpbin must
> > >>>not choke on the -symbols option and it must output a line
> > >>>with both "External" and "some_variable" on it. So false
> > >>>positives seem unlikely to me, but the test can always be
> > >>>hardened.
> >
> > FYI, the dumpbin.exe provided by Visual C++ is really just a stub
> > that calls link.exe (rather like symlinking unzip as zipinfo).
> >
> > Running "link /dump" has the same effect as running "dumpbin"; so
> > perhaps checking for MS Link is enough - if you have identified
> > the MS linker, you can use it to list symbols (and I imagine
> > libtool may need to know about the linker anyway).
>
> Oook. I guess dumpbin is available (but slightly hidden) in the
> free toolkit after all...
>
> This info made me look at the dumpbin-as-name-lister patch again
> and I found an issue with it...
>
> I had a vague recollection of a good reason not to change the
> checking msg from "checking for BSD-compatible nm..." to the
> new "checking for BSD- or MS-compatible name lister (nm)..."
> but could not pinpoint it in memory when Ralf suggested it.
> Now I remember and the reason is that I couldn't figure out a
> way to use AC_CHECK_TOOL within the AC_CACHE_CHECK for nm, so
> I added a new check after the check for nm and modified the
> check for nm to return "no" instead of "nm" if no BSD nm was
> found. Then the change to "no" was lost when I forked out the
> patch for the big patch (sorry, too many trees over here) and
> I didn't do enough testing with the forked out patch.
>
> Anyway, the problem with the new checking msg is that the
> output from configure is a bit strange if nm is not found,
> but dumpbin is:
>
> checking for BSD- or MS-compatible name lister (nm)... no
> checking for dumpbin... dumpbin -symbols
> checking the name lister (dumpbin -symbols) interface... MS dumpbin
>
> However, the old message is strange when dumpbin is specified
> by the user with NM="dumpbin -symbols":
>
> checking for BSD-compatible nm... dumpbin -symbols
> checking the name lister (dumpbin -symbols) interface... MS dumpbin
>
> I don't know which is best... Anyway, ignoring the somewhat strange
> output for a bit, is this ok for HEAD?
>
>
> 2005-08-23 Peter Ekberg <[EMAIL PROTECTED]>
>
> * libltdl/m4/libtool.m4 (LT_PATH_NM): Fix autodetection of
> dumpbin and also check for "link -dump -symbols" as a synonym
> for "dumpbin -symbols".
>
> Index: libltdl/m4/libtool.m4
> ===
> RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
> retrieving revision 1.1
> diff -u -r1.1 libtool.m4
> --- libltdl/m4/libtool.m4 22 Aug 2005 22:33:35 - 1.1
> +++ libltdl/m4/libtool.m4 23 Aug 2005 05:16:51 -
> @@ -2897,13 +2897,13 @@
> fi
>done
>IFS="$lt_save_ifs"
> - test -z "$lt_cv_path_NM" && lt_cv_path_NM=nm
> + : ${lt_cv_path_NM=no}
> fi])
> if test "$lt_cv_path_NM" != "no"; then
>NM="$lt_cv_path_NM"
> else
># Didn't find any BSD compatible name lister, look for dumpbin.
> - AC_CHECK_TOOL(DUMPBIN, [dumpbin -symbols], :)
> + AC_CHECK_TOOLS(DUMPBIN, ["dumpbin -symbols" "link -dump -symbols"],
> :)
>AC_SUBST([DUMPBIN])
>if test "$DUMPBIN" != ":"; then
> NM="$DUMPBIN"
>
> Cheers,
> Peter
RE: Libtool: Microsoft dumpbin as name lister
Albert Chin wrote: > On Tue, Aug 23, 2005 at 09:53:58AM +0200, Peter Ekberg wrote: > > Any faults in the above? Comments? > > Ick. Why not just test all available "link" programs in $PATH for the > features we want and pick the winner? Well, I think cl will run the link that is in the same dir as cl itself, so my theory was that configure should set LD to the link that is in the same dir as cl. I.e. this matters for the case where there are multiple MSVC installed and in PATH, but is perhaps a bit overdesigned... Cheers, Peter
Re: Libtool: Microsoft dumpbin as name lister
On Tue, Aug 23, 2005 at 09:53:58AM +0200, Peter Ekberg wrote:
> Albert Chin wrote:
> > > Running "link /dump" has the same effect as running "dumpbin"; so
> > > perhaps checking for MS Link is enough - if you have identified
> > > the MS linker, you can use it to list symbols (and I imagine
> > > libtool may need to know about the linker anyway).
> >
> > If dumpbin is an alias for "link" with some args, how about scrapping
> > use of dumpbin and replacing with the appropriate "link" command-line?
>
> As the same is true for "lib" == "link -lib" I have had the same
> thought. The problem is that link is most likely shadowed on the
> PATH on Cygwin. So, some care has to be taken to avoid the use
> of the wrong link program.
So, if "link" appears in multiple places in $PATH, we just need to
pick the "correct" one? Libtool does something similar for grep and
sed (i.e. pick the best one in $PATH that supports the longest
command-line).
> I dreamed up something like this:
>
> 1. Check if $CC is cl with a test compile to see if $CC
>defines _MSC_VER, if not bail.
>
> 2. If (first word of) $CC contains / or \, replace last
>path component (should be cl or cl.exe) with "link".
>
> 3. If (first word of) $CC does not contain / or \, use
>which(1) (or, if which should not be used for some reason,
>search the path manually) to locate the full path of
>$CC and replace last path component with "link".
>
> You now have good input for $LD.
>
> : ${NM="$LD -dump -symbols"}
> : ${AR="$LD -lib"}
>
> Any faults in the above? Comments?
Ick. Why not just test all available "link" programs in $PATH for the
features we want and pick the winner?
--
albert chin ([EMAIL PROTECTED])
RE: Libtool: Microsoft dumpbin as name lister
Albert Chin wrote:
> > Running "link /dump" has the same effect as running "dumpbin"; so
> > perhaps checking for MS Link is enough - if you have identified
> > the MS linker, you can use it to list symbols (and I imagine
> > libtool may need to know about the linker anyway).
>
> If dumpbin is an alias for "link" with some args, how about scrapping
> use of dumpbin and replacing with the appropriate "link" command-line?
As the same is true for "lib" == "link -lib" I have had the same
thought. The problem is that link is most likely shadowed on the
PATH on Cygwin. So, some care has to be taken to avoid the use
of the wrong link program.
I dreamed up something like this:
1. Check if $CC is cl with a test compile to see if $CC
defines _MSC_VER, if not bail.
2. If (first word of) $CC contains / or \, replace last
path component (should be cl or cl.exe) with "link".
3. If (first word of) $CC does not contain / or \, use
which(1) (or, if which should not be used for some reason,
search the path manually) to locate the full path of
$CC and replace last path component with "link".
You now have good input for $LD.
: ${NM="$LD -dump -symbols"}
: ${AR="$LD -lib"}
Any faults in the above? Comments?
Cheers,
Peter
Re: Libtool: Microsoft dumpbin as name lister
On Mon, Aug 22, 2005 at 03:39:19PM +0200, Tim Van Holder wrote: > FYI, the dumpbin.exe provided by Visual C++ is really just a stub > that calls link.exe (rather like symlinking unzip as zipinfo). > > Running "link /dump" has the same effect as running "dumpbin"; so > perhaps checking for MS Link is enough - if you have identified > the MS linker, you can use it to list symbols (and I imagine > libtool may need to know about the linker anyway). If dumpbin is an alias for "link" with some args, how about scrapping use of dumpbin and replacing with the appropriate "link" command-line? -- albert chin ([EMAIL PROTECTED])
RE: Libtool: Microsoft dumpbin as name lister
Tim Van Holder wrote:
> >>>Regarding dumpbin not being present in the 2003 version, I
> >>>*think* it's just missing from the free toolkit and that it is
> >>>still going strong in "the real" releases of Visual Studio.
> >>
> >>OK. I just can't test it then.
> >>
> >>
> Also, there seem to be third-party programs named `dumpbin'.
> Does your1> test av oid them or do they work with
> >>
> >>your macro? Are
> >>
> >>>they in
> >>>
> wide-spread use? (We can just wait till someone reports
> >>
> >>a bug, if you
> >>
> don't know; but maybe you do, or I just missed that info.)
> >>>
> >>>Hmm, I was not aware of other dumpbins, so if they are similar
> >>>there might be a problem.
> >>
> >>Completely untested (and no idea about trustworthiness):
> >>http://www.freedownloadscenter.com/Best/coff-dumpbin.html
I meant to mention (but forgot) that the executable in the
above link appears to be named libdump (but I haven't actually
installed it so I might be mistaken...)
> >>>But, as the test is currently, the located dumpbin must
> >>>not choke on the -symbols option and it must output a line
> >>>with both "External" and "some_variable" on it. So false
> >>>positives seem unlikely to me, but the test can always be
> >>>hardened.
>
> FYI, the dumpbin.exe provided by Visual C++ is really just a stub
> that calls link.exe (rather like symlinking unzip as zipinfo).
>
> Running "link /dump" has the same effect as running "dumpbin"; so
> perhaps checking for MS Link is enough - if you have identified
> the MS linker, you can use it to list symbols (and I imagine
> libtool may need to know about the linker anyway).
Oook. I guess dumpbin is available (but slightly hidden) in the
free toolkit after all...
This info made me look at the dumpbin-as-name-lister patch again
and I found an issue with it...
I had a vague recollection of a good reason not to change the
checking msg from "checking for BSD-compatible nm..." to the
new "checking for BSD- or MS-compatible name lister (nm)..."
but could not pinpoint it in memory when Ralf suggested it.
Now I remember and the reason is that I couldn't figure out a
way to use AC_CHECK_TOOL within the AC_CACHE_CHECK for nm, so
I added a new check after the check for nm and modified the
check for nm to return "no" instead of "nm" if no BSD nm was
found. Then the change to "no" was lost when I forked out the
patch for the big patch (sorry, too many trees over here) and
I didn't do enough testing with the forked out patch.
Anyway, the problem with the new checking msg is that the
output from configure is a bit strange if nm is not found,
but dumpbin is:
checking for BSD- or MS-compatible name lister (nm)... no
checking for dumpbin... dumpbin -symbols
checking the name lister (dumpbin -symbols) interface... MS dumpbin
However, the old message is strange when dumpbin is specified
by the user with NM="dumpbin -symbols":
checking for BSD-compatible nm... dumpbin -symbols
checking the name lister (dumpbin -symbols) interface... MS dumpbin
I don't know which is best... Anyway, ignoring the somewhat strange
output for a bit, is this ok for HEAD?
2005-08-23 Peter Ekberg <[EMAIL PROTECTED]>
* libltdl/m4/libtool.m4 (LT_PATH_NM): Fix autodetection of
dumpbin and also check for "link -dump -symbols" as a synonym
for "dumpbin -symbols".
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.1
diff -u -r1.1 libtool.m4
--- libltdl/m4/libtool.m4 22 Aug 2005 22:33:35 - 1.1
+++ libltdl/m4/libtool.m4 23 Aug 2005 05:16:51 -
@@ -2897,13 +2897,13 @@
fi
done
IFS="$lt_save_ifs"
- test -z "$lt_cv_path_NM" && lt_cv_path_NM=nm
+ : ${lt_cv_path_NM=no}
fi])
if test "$lt_cv_path_NM" != "no"; then
NM="$lt_cv_path_NM"
else
# Didn't find any BSD compatible name lister, look for dumpbin.
- AC_CHECK_TOOL(DUMPBIN, [dumpbin -symbols], :)
+ AC_CHECK_TOOLS(DUMPBIN, ["dumpbin -symbols" "link -dump -symbols"],
:)
AC_SUBST([DUMPBIN])
if test "$DUMPBIN" != ":"; then
NM="$DUMPBIN"
Cheers,
Peter
RE: branch-2-0 vs CVS HEAD (was: Libtool: Microsoft dumpbin as name lister)
Ralf Wildenhues wrote: > Hi Peter, > > * Peter Ekberg wrote on Mon, Aug 22, 2005 at 02:10:14PM CEST: > > Ralf Wildenhues wrote: > > > * Peter Ekberg wrote on Thu, Aug 18, 2005 at 02:36:47PM CEST: > > > > > > | +lt_cv_sys_global_symbol_pipe="$SED -n -e '/ UNDEF > > > [^|]*()/d; / 00* UNDEF /d; > > > > > > I think you are missing a pair of brackets here: ^^^ > > > [[^|]] > > > > Good eyes! I'm almost certain I had that, at least at some point. > > Must have gone missing in some manual backport from a working > > version of ltmain.sh... > > The long waits during `bootstrap' are well spent reading. Heh :-) > > Thanks for (all) your review(s)! > > Well, sure. I'd also like to add (to Bob's statement) that I believe > you do important work. I'm sorry I did not get to any of your other > patches this weekend. No worries, any attempt of mine to dictate your time is about as likely to succeed as any attempt by you to dictate mine. As I said, I'm happy for any feedback I get, it's been excellent so far. > > Applied, can I also apply to branch-2-0? > > Hmm. I'm all for fixing all known issues in HEAD first. When we have > finally fixed installation and ltdl issues in CVS HEAD, and you have > finally installed all of your MSVC work, then: Ok by me, but not what I was hoping for :-) Cheers, Peter
branch-2-0 vs CVS HEAD (was: Libtool: Microsoft dumpbin as name lister)
Hi Peter, * Peter Ekberg wrote on Mon, Aug 22, 2005 at 02:10:14PM CEST: > Ralf Wildenhues wrote: > > * Peter Ekberg wrote on Thu, Aug 18, 2005 at 02:36:47PM CEST: > > > > | +lt_cv_sys_global_symbol_pipe="$SED -n -e '/ UNDEF > > [^|]*()/d; / 00* UNDEF /d; > > > > I think you are missing a pair of brackets here: ^^^ > > [[^|]] > > Good eyes! I'm almost certain I had that, at least at some point. > Must have gone missing in some manual backport from a working > version of ltmain.sh... The long waits during `bootstrap' are well spent reading. > Thanks for (all) your review(s)! Well, sure. I'd also like to add (to Bob's statement) that I believe you do important work. I'm sorry I did not get to any of your other patches this weekend. > Applied, can I also apply to branch-2-0? Hmm. I'm all for fixing all known issues in HEAD first. When we have finally fixed installation and ltdl issues in CVS HEAD, and you have finally installed all of your MSVC work, then: - backporting everything will still be a lot of work, - testing the backports will be even more work, plus nobody will actually do it, or it won't be exposed, because: - CVS HEAD is IMNSHO actually much more tested than branch-2-0 ATM, for one because it has a much larger set of tests, and for another because I test several systems regularly, - backporting all of the test suite would be even more work. :-/ I kept quiet a while ago when Bob first suggested ditching the CVS branch-2-0 and releasing CVS HEAD as 2.0 after a bit of stabilization. Now I estimate that, for us combined, it might save us a man month (whoohoo, maybe even a mythical one :) or more. This would be a strong argument to do it, IMVHO. The only problem is: I don't know how we can get CVS HEAD to work fine with released Autoconf/Automake versions. ATM I'm not even sure which issues there are: - LTLIBOBJS in subdirs - ? Of course the new test suite would even be better with the enhancements of CVS Autoconf. But oh well. We could release it bootstrapped with CVS versions of autotools. I believe users of libltdl that - either build it as subpackage, - or as integrated package but with sub-Makefile.am, still won't be hurt. But we'd need to test that as well. Cheers, Ralf
RE: Libtool: Microsoft dumpbin as name lister
On Mon, 22 Aug 2005, Peter Ekberg wrote: I wasn't intending to offend anyone with that remark, sorry if I did. Regarding my work being important, I can just say that I don't think so myself, I'm just doing it to see if it's possible and to Your work is clearly important. There is some code (e.g. based on ATL or MFC) which can only be built using MSVC so having the ability to drive MSVC with GNU build tools is a benefit. For my project, the vast majority of the software can be built under MinGW using a similar configuration to a MSVC build. However, there are two components which can not because they use MFC or ATL. If these components could be built from the same environment it would result in huge time-savings for me. Once MSVC support is fully working, then there is opportuntity to add enhancements to build Microsoft .net assemblies/applications as well. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Libtool: Microsoft dumpbin as name lister
>>>Regarding dumpbin not being present in the 2003 version, I >>>*think* it's just missing from the free toolkit and that it is >>>still going strong in "the real" releases of Visual Studio. >> >>OK. I just can't test it then. >> >> Also, there seem to be third-party programs named `dumpbin'. Does your1> test av oid them or do they work with >> >>your macro? Are >> >>>they in >>> wide-spread use? (We can just wait till someone reports >> >>a bug, if you >> don't know; but maybe you do, or I just missed that info.) >>> >>>Hmm, I was not aware of other dumpbins, so if they are similar >>>there might be a problem. >> >>Completely untested (and no idea about trustworthiness): >>http://www.freedownloadscenter.com/Best/coff-dumpbin.html >> >> >>>But, as the test is currently, the located dumpbin must >>>not choke on the -symbols option and it must output a line >>>with both "External" and "some_variable" on it. So false >>>positives seem unlikely to me, but the test can always be >>>hardened. FYI, the dumpbin.exe provided by Visual C++ is really just a stub that calls link.exe (rather like symlinking unzip as zipinfo). Running "link /dump" has the same effect as running "dumpbin"; so perhaps checking for MS Link is enough - if you have identified the MS linker, you can use it to list symbols (and I imagine libtool may need to know about the linker anyway).
RE: Libtool: Microsoft dumpbin as name lister
Ralf Wildenhues wrote:
> Hi Peter,
>
> * Peter Ekberg wrote on Thu, Aug 18, 2005 at 02:36:47PM CEST:
> > Ralf Wildenhues wrote:
> >
> > > Missing bits below, plus: We advertise `NM' in libtool.texi as BSD
> > > compatible, and show how its output looks like (two different
> > > sections). We should update that, if possible. If you would not
> > > like to do that, I could do it if I knew how dumpbin's
> output looked
> > > like and how it behaved. As you noticed already, it's not present
> > > in the 2003 version, and I can't find an older accessible msvc to
> > > try out.
> >
> > I have attached (to prevent distortions) the output from "dumpbin
> > -symbols" after compiling the following with cl -c -o sym.obj sym.c
>
> OK, thanks.
>
> *snip*
> > Regarding dumpbin not being present in the 2003 version, I
> > *think* it's just missing from the free toolkit and that it is
> > still going strong in "the real" releases of Visual Studio.
>
> OK. I just can't test it then.
>
> > > Also, there seem to be third-party programs named `dumpbin'.
> > > Does your1> test av oid them or do they work with
> your macro? Are
> > they in
> > > wide-spread use? (We can just wait till someone reports
> a bug, if you
> > > don't know; but maybe you do, or I just missed that info.)
> >
> > Hmm, I was not aware of other dumpbins, so if they are similar
> > there might be a problem.
>
> Completely untested (and no idea about trustworthiness):
> http://www.freedownloadscenter.com/Best/coff-dumpbin.html
>
> > But, as the test is currently, the located dumpbin must
> > not choke on the -symbols option and it must output a line
> > with both "External" and "some_variable" on it. So false
> > positives seem unlikely to me, but the test can always be
> > hardened.
>
> OK.
>
> > If the test is negative the found dumpbin is
> > assumed to support the BSD nm interface, which is probably
> > more likely to happen. But as you noted below, nm must be
> > Missing for that to happen and in that case you were toast
> > previously as well...
>
> ACK.
>
> > > Another remark: we change the interface provided by
> > > libtool.m4. Please
> > > update the serial number of the file.
> *snip*
>
> > Ok.
>
> Thanks.
>
> > > Lastly, can I ask a favor of you? I've seen your other
> patches, and
> > > hate to delay them even longer, but I won't be able to test
> > > them enough
> > > before the weekend. So I'd like you to not use the 72 hour rule.
> > > Thanks. I'll try to get to them as quickly as possible, if
> > > nobody else
> > > has before.
> >
> > No problem at all, I'm just beginning to feel that I have soon
> > filled the quota for at least some people with very similar-
> > looking patches, and that people are perhaps no longer reading.
>
> I am reading, but I need time.
>
> > So I just pictured your request for a 2nd maintainer to chip in
> > disappearing in the bitbucket...
>
> Well, can't do much about that, can I?
>
> > Regarding the changes to the documentation, I have not tested
> > it, so it just might look like crap or generally suck in other
> > ways. Feel free to edit or suggest fixes.
>
> Yep, sucks. :)
> To be serious: the line length is too long. Suggested change below.
>
> OK. Please apply after the following changes, if you agree.
> No need to
> post this for review again.
>
> Cheers,
> Ralf
>
>
*snip*
> | +For MS @command{dumpbin}, the symbols should be in one of
> the following
> | +formats:
> | +
> | [EMAIL PROTECTED]
> | [EMAIL PROTECTED] @var{size}UNDEF notype
> External | @var{global-variable-name}
> | [EMAIL PROTECTED] @var{address} @var{section} notype
> External | @var{global-variable-name}
> | [EMAIL PROTECTED] @var{address} @var{section} notype ()
> External | @var{global-function-name}
> | [EMAIL PROTECTED] example
>
> Please replace this with
>
> [EMAIL PROTECTED]
> [EMAIL PROTECTED] @var{size}UNDEFnotype External
> | @var{global-var}
> [EMAIL PROTECTED] @var{address} @var{section} notype
> External | @var{global-var}
> [EMAIL PROTECTED] @var{address} @var{section} notype ()
> External | @var{global-func}
> [EMAIL PROTECTED] example
>
> and be done with it.
>
Ok.
*snip*
> |# Write the raw and C identifiers.
> | - lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[[
> ]]\($symcode$symcode*\)[[ ]][[
> ]]*$ac_symprfx$sympat$opt_cr$/$symxfrm/p'"
> | + if test "$lt_cv_nm_interface" = "MS dumpbin"; then
> | +# Fake it for dumpbin and say T for any non-static function
> | +# and D for any global variable.
> | +# Also find C++ and __fastcall symbols from MSVC++,
> | +# which start with @ or ?.
> | +lt_cv_sys_global_symbol_pipe="$SED -n -e '/ UNDEF
> [^|]*()/d; / 00* UNDEF /d;
>
> I think you are missing a pair of brackets here: ^^^
> [[^|]]
Good eyes! I'm almost certain I had that, at least at some point.
Must have gone missing
RE: Libtool: Microsoft dumpbin as name lister
Bob Friesenhahn wrote: > On Thu, 18 Aug 2005, Peter Ekberg wrote: > > No problem at all, I'm just beginning to feel that I have soon > > filled the quota for at least some people with very similar- > > looking patches, and that people are perhaps no longer reading. > > So I just pictured your request for a 2nd maintainer to chip in > > disappearing in the bitbucket... > > It is true that some of us are plumb wore out and unable to cope. > Your work is interesting and important but I am sure that > Ralf is best > qualified to evaluate the patch because he as been working with it > closely. I wasn't intending to offend anyone with that remark, sorry if I did. Regarding my work being important, I can just say that I don't think so myself, I'm just doing it to see if it's possible and to perhaps learn a thing or two (and a bunch of similar reasons). So, while I'm personally willing to spend some time on it, I don't expect anybody else to do so, and I'm positively surprised by any interest. Cheers, Peter
Re: Libtool: Microsoft dumpbin as name lister
Hi Peter,
* Peter Ekberg wrote on Thu, Aug 18, 2005 at 02:36:47PM CEST:
> Ralf Wildenhues wrote:
>
> > Missing bits below, plus: We advertise `NM' in libtool.texi as BSD
> > compatible, and show how its output looks like (two different
> > sections). We should update that, if possible. If you would not
> > like to do that, I could do it if I knew how dumpbin's output looked
> > like and how it behaved. As you noticed already, it's not present
> > in the 2003 version, and I can't find an older accessible msvc to
> > try out.
>
> I have attached (to prevent distortions) the output from "dumpbin
> -symbols" after compiling the following with cl -c -o sym.obj sym.c
OK, thanks.
*snip*
> Regarding dumpbin not being present in the 2003 version, I
> *think* it's just missing from the free toolkit and that it is
> still going strong in "the real" releases of Visual Studio.
OK. I just can't test it then.
> > Also, there seem to be third-party programs named `dumpbin'.
> > Does your1> test av oid them or do they work with your macro? Are
> they in
> > wide-spread use? (We can just wait till someone reports a bug, if you
> > don't know; but maybe you do, or I just missed that info.)
>
> Hmm, I was not aware of other dumpbins, so if they are similar
> there might be a problem.
Completely untested (and no idea about trustworthiness):
http://www.freedownloadscenter.com/Best/coff-dumpbin.html
> But, as the test is currently, the located dumpbin must
> not choke on the -symbols option and it must output a line
> with both "External" and "some_variable" on it. So false
> positives seem unlikely to me, but the test can always be
> hardened.
OK.
> If the test is negative the found dumpbin is
> assumed to support the BSD nm interface, which is probably
> more likely to happen. But as you noted below, nm must be
> Missing for that to happen and in that case you were toast
> previously as well...
ACK.
> > Another remark: we change the interface provided by
> > libtool.m4. Please
> > update the serial number of the file.
*snip*
> Ok.
Thanks.
> > Lastly, can I ask a favor of you? I've seen your other patches, and
> > hate to delay them even longer, but I won't be able to test
> > them enough
> > before the weekend. So I'd like you to not use the 72 hour rule.
> > Thanks. I'll try to get to them as quickly as possible, if
> > nobody else
> > has before.
>
> No problem at all, I'm just beginning to feel that I have soon
> filled the quota for at least some people with very similar-
> looking patches, and that people are perhaps no longer reading.
I am reading, but I need time.
> So I just pictured your request for a 2nd maintainer to chip in
> disappearing in the bitbucket...
Well, can't do much about that, can I?
> Regarding the changes to the documentation, I have not tested
> it, so it just might look like crap or generally suck in other
> ways. Feel free to edit or suggest fixes.
Yep, sucks. :)
To be serious: the line length is too long. Suggested change below.
OK. Please apply after the following changes, if you agree. No need to
post this for review again.
Cheers,
Ralf
| Index: doc/libtool.texi
| ===
| RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
| retrieving revision 1.193
| diff -u -r1.193 libtool.texi
| --- doc/libtool.texi 12 Aug 2005 22:52:30 - 1.193
| +++ doc/libtool.texi 18 Aug 2005 12:32:30 -
| @@ -1685,9 +1685,9 @@
| @end defmac
|
| @defmac LT_PATH_NM
| -Try to find a @sc{bsd} compatible @command{nm} command on this
| -machine. The result is stored in the shell variable @samp{$NM}, which
| -is @code{AC_SUBST}ed.
| +Try to find a @sc{bsd} compatible @command{nm} or a @sc{ms} compatible
| [EMAIL PROTECTED] command on this machine. The result is stored in the
| +shell variable @samp{$NM}, which is @code{AC_SUBST}ed.
| @end defmac
|
| @noindent
| @@ -4980,14 +4980,27 @@
| @end defvar
|
| @defvar NM
| -The name of a BSD-compatible @command{nm} program that produces listings
| -of global symbols in one the following formats:
| +The name of a BSD- or MS-compatible program that produces listings of
| +global symbols.
| +For BSD @command{nm}, the symbols should be in one the following formats:
|
| @example
| @var{address} C @var{global-variable-name}
| @var{address} D @var{global-variable-name}
| @var{address} T @var{global-function-name}
| @end example
| +
| +For MS @command{dumpbin}, the symbols should be in one of the following
| +formats:
| +
| [EMAIL PROTECTED]
| [EMAIL PROTECTED] @var{size}UNDEF notype External |
@var{global-variable-name}
| [EMAIL PROTECTED] @var{address} @var{section} notype External |
@var{global-variable-name}
| [EMAIL PROTECTED] @var{address} @var{section} notype ()External |
@var{global-function-name}
| [EMAIL PROTECTED] example
Please replace this with
[EMAIL PROTECTED]
[EMAIL PROTECTED] @var{size}
RE: Libtool: Microsoft dumpbin as name lister
On Thu, 18 Aug 2005, Peter Ekberg wrote: Lastly, can I ask a favor of you? I've seen your other patches, and hate to delay them even longer, but I won't be able to test them enough before the weekend. So I'd like you to not use the 72 hour rule. Thanks. I'll try to get to them as quickly as possible, if nobody else has before. No problem at all, I'm just beginning to feel that I have soon filled the quota for at least some people with very similar- looking patches, and that people are perhaps no longer reading. So I just pictured your request for a 2nd maintainer to chip in disappearing in the bitbucket... It is true that some of us are plumb wore out and unable to cope. Your work is interesting and important but I am sure that Ralf is best qualified to evaluate the patch because he as been working with it closely. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
RE: Libtool: Microsoft dumpbin as name lister
Ralf Wildenhues wrote:
> Sent: Wednesday, August 17, 2005 20:54
> To: Peter Ekberg
> Cc: libtool-patches@gnu.org
> Subject: Re: Libtool: Microsoft dumpbin as name lister
>
> Hi Peter,
>
> * Peter Ekberg wrote on Mon, Aug 15, 2005 at 11:20:58PM CEST:
> >
> > I have forked out this patch (against HEAD) from my MSVC work.
>
> Good work.
Thanks!
> Missing bits below, plus: We advertise `NM' in libtool.texi as BSD
> compatible, and show how its output looks like (two different
> sections).
> We should update that, if possible. If you would not like to do that,
> I could do it if I knew how dumpbin's output looked like and how it
> behaved. As you noticed already, it's not present in the
> 2003 version,
> and I can't find an older accessible msvc to try out.
I have attached (to prevent distortions) the output from
"dumpbin -symbols" after compiling the following with
cl -c -o sym.obj sym.c
-8<-
#include
int global_vardef;
int global_vardef_init = 1;
extern int extern_vardecl;
static int static_vardef;
static int static_vardef_init = 1;
extern __declspec(dllexport) int export_vardef;
int export_vardef;
extern __declspec(dllexport) int export_vardef_init;
int export_vardef_init = 1;
extern __declspec(dllexport) int export_vardecl;
extern __declspec(dllimport) int import_vardecl;
static void static_funcdef(void) {}
extern void extern_funcdecl(void);
extern __declspec(dllexport) void export_funcdef(void);
void export_funcdef(void) {}
extern __declspec(dllexport) void export_funcdecl(void);
extern __declspec(dllimport) void import_funcdecl(void);
void global_funcdef(void)
{
int local_var;
extern_funcdecl();
export_funcdecl();
import_funcdecl();
local_var = extern_vardecl;
local_var += export_vardecl;
local_var += import_vardecl;
}
-8<-
nm on that object file gives:
$ nm sym.obj
d .data
i .drectve
t .text
000a2306 a @comp.id
U __imp__import_funcdecl
U __imp__import_vardecl
U _export_funcdecl
T _export_funcdef
U _export_vardecl
0004 C _export_vardef
0008 D _export_vardef_init
U _extern_funcdecl
U _extern_vardecl
0005 T _global_funcdef
0004 C _global_vardef
D _global_vardef_init
0004 d _static_vardef_init
Regarding dumpbin not being present in the 2003 version, I
*think* it's just missing from the free toolkit and that it is
still going strong in "the real" releases of Visual Studio.
> Also, there seem to be third-party programs named `dumpbin'.
> Does your1> test av oid them or do they work with your macro? Are
they in
> wide-spread use? (We can just wait till someone reports a bug, if you
> don't know; but maybe you do, or I just missed that info.)
Hmm, I was not aware of other dumpbins, so if they are similar
there might be a problem.
But, as the test is currently, the located dumpbin must
not choke on the -symbols option and it must output a line
with both "External" and "some_variable" on it. So false
positives seem unlikely to me, but the test can always be
hardened. If the test is negative the found dumpbin is
assumed to support the BSD nm interface, which is probably
more likely to happen. But as you noted below, nm must be
Missing for that to happen and in that case you were toast
previously as
well...
> Another remark: we change the interface provided by
> libtool.m4. Please
> update the serial number of the file. Strictly speaking,
> your patch is
> an incompatible change, too (as the documented interface, i.e., output
> of $NM, is not guaranteed any more), but in practice I think it is a
> good compromise: before, without any nm, things would not
> have worked at
> all. So I consider that OK.
Ok.
> Lastly, can I ask a favor of you? I've seen your other patches, and
> hate to delay them even longer, but I won't be able to test
> them enough
> before the weekend. So I'd like you to not use the 72 hour rule.
> Thanks. I'll try to get to them as quickly as possible, if
> nobody else
> has before.
No problem at all, I'm just beginning to feel that I have soon
filled the quota for at least some people with very similar-
looking patches, and that people are perhaps no longer reading.
So I just pictured your request for a 2nd maintainer to chip in
disappearing in the bitbucket...
> Cheers,
> Ralf
>
> > 2005-08-15 Peter Ekberg <[EMAIL PROTECTED]>
> >
> > * m4/libtool.m4 (LT_PATH_NM): If nm is not found on the
> > path, look for dumpbin. Then check if $NM responds as
> > dumpbin would and if not, assume the name lister is
> > BSD nm compatible.
> > (_LT_CMD_GLOBAL_SYMBOLS
Re: Libtool: Microsoft dumpbin as name lister
Hi Peter, * Peter Ekberg wrote on Mon, Aug 15, 2005 at 11:20:58PM CEST: > > I have forked out this patch (against HEAD) from my MSVC work. Good work. Missing bits below, plus: We advertise `NM' in libtool.texi as BSD compatible, and show how its output looks like (two different sections). We should update that, if possible. If you would not like to do that, I could do it if I knew how dumpbin's output looked like and how it behaved. As you noticed already, it's not present in the 2003 version, and I can't find an older accessible msvc to try out. Also, there seem to be third-party programs named `dumpbin'. Does your test avoid them or do they work with your macro? Are they in wide-spread use? (We can just wait till someone reports a bug, if you don't know; but maybe you do, or I just missed that info.) Another remark: we change the interface provided by libtool.m4. Please update the serial number of the file. Strictly speaking, your patch is an incompatible change, too (as the documented interface, i.e., output of $NM, is not guaranteed any more), but in practice I think it is a good compromise: before, without any nm, things would not have worked at all. So I consider that OK. Lastly, can I ask a favor of you? I've seen your other patches, and hate to delay them even longer, but I won't be able to test them enough before the weekend. So I'd like you to not use the 72 hour rule. Thanks. I'll try to get to them as quickly as possible, if nobody else has before. Cheers, Ralf > 2005-08-15 Peter Ekberg <[EMAIL PROTECTED]> > > * m4/libtool.m4 (LT_PATH_NM): If nm is not found on the > path, look for dumpbin. Then check if $NM responds as > dumpbin would and if not, assume the name lister is > BSD nm compatible. > (_LT_CMD_GLOBAL_SYMBOLS): If the name lister uses the > dumpbin interface, adjust the test to find a working > global_symbol_pipe. | Index: m4/libtool.m4 | === | RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v | retrieving revision 1.209 | diff -u -r1.209 libtool.m4 | --- m4/libtool.m4 10 Aug 2005 06:25:10 - 1.209 | +++ m4/libtool.m4 15 Aug 2005 20:59:40 - | @@ -2729,9 +2729,11 @@ | | # LT_PATH_NM | # -- | -# find the pathname to a BSD-compatible name lister | +# find the pathname to a BSD- or MS-compatible name lister | AC_DEFUN([LT_PATH_NM], | -[AC_CACHE_CHECK([for BSD-compatible nm], lt_cv_path_NM, | +[AC_REQUIRE([AC_PROG_CC])dnl | +AC_REQUIRE([AC_OBJEXT])dnl | +AC_CACHE_CHECK([for BSD-compatible nm], lt_cv_path_NM, Maybe rather 'for BSD- or MS-compatible name lister (nm)'? | [if test -n "$NM"; then |# Let the user override the test. |lt_cv_path_NM="$NM" | @@ -2768,10 +2770,35 @@ |IFS="$lt_save_ifs" |test -z "$lt_cv_path_NM" && lt_cv_path_NM=nm | fi]) | -NM="$lt_cv_path_NM" | +if test "$lt_cv_path_NM" != "no"; then | + NM="$lt_cv_path_NM" | +else | + # Didn't find any BSD compatible name lister, look for dumpbin. | + AC_CHECK_TOOL(DUMPBIN, [dumpbin -symbols], :) | + AC_SUBST([DUMPBIN]) | + if test "$DUMPBIN" != ":"; then | +NM="$DUMPBIN" | + fi | +fi | test -z "$NM" && NM=nm | AC_SUBST([NM]) | -_LT_DECL([], [NM], [1], [A BSD-compatible nm program])dnl | +_LT_DECL([], [NM], [1], [A BSD- or MS-compatible name lister])dnl | + | +AC_CACHE_CHECK([the name lister ($NM) interface], [lt_cv_nm_interface], | + [lt_cv_nm_interface="BSD nm" | + printf "int some_variable = 0;" > conftest.$ac_ext | + (eval echo "\"\$as_me:__oline__: $ac_compile\"" >&AS_MESSAGE_LOG_FD) | + (eval "$ac_compile" 2>conftest.err) | + cat conftest.err >&AS_MESSAGE_LOG_FD | + (eval echo "\"\$as_me:__oline__: $NM \\\"conftest.$ac_objext\\\"\"" >&AS_MESSAGE_LOG_FD) | + (eval "$NM \"conftest.$ac_objext\"" 2>conftest.err > conftest.out) | + cat conftest.err >&AS_MESSAGE_LOG_FD | + (eval echo "\"\$as_me:__oline__: output\"" >&AS_MESSAGE_LOG_FD) | + cat conftest.out >&AS_MESSAGE_LOG_FD | + if $GREP 'External.*some_variable' conftest.out > /dev/null; then | +lt_cv_nm_interface="MS dumpbin" | + fi | + rm -f conftest*]) | ])# LT_PATH_NM | | # Old names: | @@ -2908,7 +2935,19 @@ |symxfrm="\\1 $ac_symprfx\\2 \\2" | |# Write the raw and C identifiers. | - lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[[ ]]\($symcode$symcode*\)[[ ]][[ ]]*$ac_symprfx$sympat$opt_cr$/$symxfrm/p'" | + if test "$lt_cv_nm_interface" = "MS dumpbin"; then | +# Fake it for dumpbin and say T for any non-static function | +# and D for any global variable. | +# Also find C++ and __fastcall symbols from MSVC++, | +# which start with @ or ?. | +lt_cv_sys_global_symbol_pipe="$SED -n -e '/ UNDEF [^|]*()/d; / 00* UNDEF /d; | + s/.*().*External *| *$ac_symprfx$sympat.*/T $ac_symprfx\1 \1/p; | + s/.*External *| *$ac_symprfx$sympat.*/D $ac_symprfx\1 \1/p; | + s/.*().*External *| *\([EMAIL PROTECTED]@?]]*\).*/T \1
Libtool: Microsoft dumpbin as name lister
Hi, I have forked out this patch (against HEAD) from my MSVC work. 2005-08-15 Peter Ekberg <[EMAIL PROTECTED]> * m4/libtool.m4 (LT_PATH_NM): If nm is not found on the path, look for dumpbin. Then check if $NM responds as dumpbin would and if not, assume the name lister is BSD nm compatible. (_LT_CMD_GLOBAL_SYMBOLS): If the name lister uses the dumpbin interface, adjust the test to find a working global_symbol_pipe. Cheers, Peter head-dumpbin-as-name-lister.patch Description: head-dumpbin-as-name-lister.patch
