Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)

[Ralf Wildenhues]

* Charles Wilson wrote on Sun, Jun 27, 2010 at 02:51:21PM CEST:
> > In that case, Ralf's suggested libfile_$(transliterated implib name)
> > is used, because we have the .la file available which allows that
> > shortcut.  The only time we need `dlltool --identify' is when
> > dlpreopening a non-libtool implib, where we have no .la file.
> > And the sed-fu is a fallback to THAT fallback.
> 
> 
> So...can I get a verdict?  Is -dlpreopen not-an-la-file supposed to work?

I think Pierre's report was about using -dlpreopen file.la at link time,
but then not wanting to need the .la file at run time.  I think that is
desirable.  At link edit time, having a .la file is a reasonable thing I
think.

> > I'll note though that this patch makes me cringe: it introduces more
> > system-specific code in ltmain that is just bloat on other systems,
> > rather than in libtool.m4 where it belongs. 
> 
> Well, I did manage to come up with a mechanism to move most of
> 
> func_cygming_dll_for_implib
> func_cygming_dll_for_implib_fallback
> func_cygming_dll_for_implib_fallback_core
> func_cygming_gnu_implib_p
> func_cygming_ms_implib_p
> 
> into libtool.m4 (attached; only lightly tested pending Q above).
> However, I can't see how to move the other mods in func_generate_dlsyms
> and func_mode_link there.
> 
> I tried to use Gary's _LT_PROG_XSI_REPLACE function, but using a sed
> script to create a sed script and all the quoting nightmares just made
> my head hurt.  So, I have _LT_PROG_FUNCTION_REPLACE that uses the old
> 'copy half the script, emit the new function content, copy the rest of
> the script' algorithm.

I don't see this method as the new method of choice.  We already have a
mechanism for years to transport values to the libtool script with
_LT_DECLs and _LT_TAGDECLs, and at least for small code snippets, that
should be used.  I'd probably be more confident with code in ltmain that
you did test rather than a new transplanting method that has not been
tested well, and thus by definition has bugs.

> > Does this patch have any relation to Pierre Ossman's "Preloading without
> > .la" patch?  http://thread.gmane.org/gmane.comp.gnu.libtool.general/7071
> > His copyright papers are through now, so we can look at that patch.
> 
> Well, I *think* Pierre's patch would break cygwin -- but that'd be true
> with or without this patch.  (The following statement in libltdl is not
> true, for cygwin when -dlpreload and --disable-static):
> 
> /* Preloaded modules are always named according to their old
>archive name. */
> 
> because at least currently, the second entry in the
> LTX_preloaded_symbols array is "cygfoo-N.dll" in those circumstances,
> not "libfoo.a".

Well yeah, this confusion and interface non-well-definedness is bad, no?

> The title of Pierre's thread is a bit confusing (at least to me). What
> he is talking about is using libltdl at runtime, with a variety of names
> refering to the same library (module, module.la, module.a, etc).  That's
> why HE means by "Preloading without .la". My Question above is about
> *build* time, when you're trying to specify -dlpreopen not-a-.la.

OK.

> >> +func_tr_sh ()
> >> +{
> >> +  case "$1" in
> > 
> > No double-quotes needed here.
> 
> Even if $1 might have spaces? 

Yes.  The shell does not do word splitting on the right hand side of an
assignment and in the argument to 'case'.  Just try it:

  foo="with space"; case $foo in *space*) echo whoo;; esac

>  It's a pathname:
> 
>   func_tr_sh "$dlprefile"
> 
> But, I guess, since dlprefile obtained as a member of a space-separated
> list, it BETTER not have any spaces in it. OK.

Irrelevant.

> >> +  eval '$ECHO ": $dlprefile_dlbasename" >> "$nlist"'
> >> +  eval '$ECHO ": $name " >> "$nlist"'
> > 
> > Likewise.
> 
> Those are (copies, adaptations of) pre-existing code:
> 
> - $opt_dry_run || {
> -   eval '$ECHO ": $name " >> "$nlist"'
> -   eval "$NM $dlprefile 2>/dev/null | $global_symbol_pipe >>
> '$nlist'"
> 
> I don't feel comfortable folding in a change like that as part of this
> patch, but I'd be happy to supply a separate follow-on patch to change
> them all at once.

Don't worry.  I'm working on a related change anyway that fixes a lot of
the eval stuff.

> >> +fi
> >> +eval "$NM $dlprefile 2>/dev/null | $global_symbol_pipe |
> >> +  $SED -e '/I __imp/d' -e 's/I __nm_/D /;s/_nm__//' >> 
> >> '$nlist'"
> > 
> > This can probably have the outer double quotes removed, eval moved to
> > $global_symbol_pipe, and quotes around $nlist removed.  Actually, don't
> > change this, because it might be the eval isn't needed at all; I will
> > check this and change all uses in libtool then.
> 
> Again, this is a copy of pre-existing code, so...I'll leave this to you.

OK.

> >> +# func_cygming_dll_for_implib_fallback_core SECTION_NAME LIBNAMEs

> >> +# Echos the name of the DLL associated with the
> >> +# specified import library.
> > 
> > You'd s

Re: [PATCH] Add func_append_quoted and do inline func_append substitutions.

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Mon, Jun 28, 2010 at 01:24:39AM CEST:
> Looking through the XSI substitutions, or more correctly the bash/ksh
> func_append usage, there's room here to consistently use func_append
> everywhere to make for easier maintenance... but rather than take the
> additional overhead of a function call in the sensitive quadratic scaling
> parts that prompted the introduction of the += idiom in the first place:
> use the libtool rewriting  machinery to substitute inline `+=' where
> possible, with a fallback to the earlier longhand otherwise.
> 
> Okay to push?

OK thanks!

Cheers,
Ralf

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)

[Ralf Wildenhues]

Hello Charles,

* Charles Wilson wrote on Mon, Jun 28, 2010 at 12:05:40AM CEST:
> On 6/27/2010 4:43 PM, Ralf Wildenhues wrote:
> > * Charles Wilson wrote on Sun, Jun 27, 2010 at 02:51:21PM CEST:
> >> So...can I get a verdict?  Is -dlpreopen not-an-la-file supposed to work?
> > 
> > I think Pierre's report was about using -dlpreopen file.la at link time,
> > but then not wanting to need the .la file at run time.  I think that is
> > desirable.  At link edit time, having a .la file is a reasonable thing I
> > think.
> 
> So...I *don't* need to worry about -dlpreopen not-an-.la?  The issue is
> that I can't figure out how *current* libtool EVER gets here:
> 
> (current master ltmain.m4sh:1984:func_generate_dlsyms)
> 
>   for dlprefile in $dlprefiles; do
> func_verbose "extracting global C symbols from \`$dlprefile'"
> func_basename "$dlprefile"
> name="$func_basename_result"
> $opt_dry_run || {
>   eval '$ECHO ": $name " >> "$nlist"'
>   eval "$NM $dlprefile 2>/dev/null | $global_symbol_pipe >> '$nlist'"
> }
>   done
> 
> in that situation, with anything IN $dlprefiles -- because in
> ltmain.m4sh, we have:
> 
> 5764 if test "$linkmode" = prog; then
> 5765   dlfiles="$newdlfiles"
> 5766 fi
> 5767 if test "$linkmode" = prog || test "$linkmode" = lib; then
> 5768   dlprefiles="$newdlprefiles"
> 5769 fi
> 
> and at this point, both newdlfiles and newdlfiles are empty, when the
> argument to libtool's -dlpreopen option is not a libtool .la library.
> 
> So...we APPEAR to have a bunch of dead code.

I wasn't aware of that.  Sorry about the sloppy review.

>  It obviously isn't
> SUPPOSED to be dead -- or it wouldn't be there.

Well, I wouldn't put my money on that reasoning.

>  So, I can either keep
> (that is, commit) all of my new stuff in this patch, some of which will
> also be dead code, in anticipation of somebody tracking down WHY it and
> these existing snippets are (currently) dead, and brings them back to life.
> 
> Or I can NOT commit any new (dead) code and commit only those bits that
> are presently "live", and wait until after the existing dead code is
> resurrected, and THEN add those particular bits that I'd've held back.
> 
> Which?

I'd say the part that is easier for you, so I guess that would be
committing all the code, including presumably-dead.  And maybe in a
future patch adding a testsuite test that exercises the code.

> >> I tried to use Gary's _LT_PROG_XSI_REPLACE function, but using a sed
> >> script to create a sed script and all the quoting nightmares just made
> >> my head hurt.  So, I have _LT_PROG_FUNCTION_REPLACE that uses the old
> >> 'copy half the script, emit the new function content, copy the rest of
> >> the script' algorithm.
> > 
> > I don't see this method as the new method of choice.  We already have a
> > mechanism for years to transport values to the libtool script with
> > _LT_DECLs and _LT_TAGDECLs, and at least for small code snippets,
> 
> Yeah, that's the problem. You complained that these functions added a
> lot of parse time to all the other platforms that would never use them,
> presumably because they were BIG functions and there were several of
> them.  Presumably, the parse-time cost of small functions is low, unless
> there are a TON.

I think you can measure parse time in script length plus number of
here-documents (for old shells).

> But please, in the future, don't complain so strongly ([your patch]
> "makes me cringe") about architectural issues if you don't actually want
> to see them fixed: "system-specific code in ltmain...rather than in
> libtool.m4 where it belongs."
> 
> I feel (more) discouraged now (than usual), having wasted so much time
> addressing a criticism of a patch that wasn't meant to be taken seriously.

I would like to apologize for this comment making you do this extra
work.  Again, that review of mine was more sloppy than it should have
been.

> In fact, I have often wondered if the reason many of my patches -- and
> Peter's -- tend to languish so long is because of these aesthetic
> objections

Of course code maintenance aspects and long-term slowdown of the code
are a part of code quality.

> Anyway, this patch AND that upcoming cross-compile patch both add
> several large system-specific new functions to ltmain.sh.  Since you
> objected to them now, I figured I'd hear it again THEN, so...I took this
&

Re: [PATCH] Add an XSI replacement for func_split_short_opt.

[Ralf Wildenhues]

Hi Eric,

thanks for the suggestion.  I had considered the idea for a second, but
failed to see the nontrivial half.

* Eric Blake wrote on Mon, Jun 28, 2010 at 02:49:40PM CEST:
> tmp=${1#?}
> patt=
> i=2
> while test $i -lt ${#1}; do
>   patt="?$patt"

If the parameter may be expected to be very long (which I don't think it
will be) then
  func_append patt '?'

would be useful here, and even if not, appending rather than prepending
here helps with current bash.

>   i=$((i+1))
> done
> result=${tmp%$patt}

Cheers,
Ralf

Re: [PATCH 3/4] Uniform const'ness of symlist variable lt_preloaded_symbols.

[Ralf Wildenhues]

Hello Vincent,

* Ralf Wildenhues wrote on Sat, Jun 19, 2010 at 12:08:29PM CEST:
> I would like to commit the patch quoted below, on the way of support for
> LTO with GCC.  For that, I need to know from somebody who is willing to
> help out with the Windows CE port of Libtool whether the #defines used
> in the patch are sufficient and correct.
> 
> This is
> <http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9769>.

Libtool has no wince maintainer.  If we cannot even get simple questions
answered about WinCE, then we cannot ensure to keep Libtool working on
this system.  Questions answered are a necessary, but not necessarily
sufficient condition for keeping a port working.  Regular regression
testing is usually necessary as well, even if there are none to few
changes specific to some port.  For systems Charles, the Peters, Bob,
Gary, and I have access to, regular testing is pretty much a given,
which sums up to something like 3 dozen different setups at least
(users do more testing, but I have less of an overview off-hand).

Right now I have one simple question: can I assume that the preprocessor
symbol _WIN32_WCE is defined for wince code, and usually not defined for
non-wince code?

This question is the only impediment for this particular patch.  Of
course, a regression test of Libtool with this patch on wince would be
much better even.

Thank you,
Ralf

Re: [PATCH] Add an XSI replacement for func_split_short_opt.

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Tue, Jun 29, 2010 at 05:09:29PM CEST:
> On 29 Jun 2010, at 21:03, Eric Blake wrote:
> > Ultimately, I'd like to fix m4sh to make it easier to probe/require XSI
> > support, but that will have to wait until after autoconf 2.66.
> 
> While that might turn out to be useful elsewhere (I wrote a quick esyscmd
> to check for the things that Libtool needs, so it's not difficult in
> principle), it's not useful for Autotools as things stand right now, since
> m4sh generally runs on the developers machine to generate scripts that are
> shipped and executed on the user's shell.
> 
> It might be nice if a future Autotools does the m4sh->sh generation from
> some AC_macros that expand at distribution time but are still executed on
> the user's machine - but then we are requiring that the user have modern
> GNU m4 available, which might not be smart.

I think m4sh can simply use code like

  if ( eval '$smart_works' ) >/dev/null 2>&1; then
func_foo () { smart code; }
  else
func_foo () { safe code; }
  fi

for code run a handful of times, without need for extra m4 magic, it's
just that libtool is easily run hundreds of times in a typical large
software build so it warrants optimization.

Cheers,
Ralf

Re: checking for header/library mismatch, rpath problem?

[Ralf Wildenhues]

[ please elide autoconf@ from followups, thanks ]

Hi Peter,

* Peter Breitenlohner wrote on Tue, Jun 29, 2010 at 10:36:32AM CEST:
> Here the macro we are using in TeX Live for such tests (C and C++).  Our
> purpose is to test properties of libraries that can be either
> (1) uninstalled libtool libraries already built when this configure runs,
> or (2) installed libraries -- libtool or not.

Good stuff.  Are you willing to turn this into a patch against git
Libtool?  Otherwise we'll put it on our todo list.  You might need
to sign papers though, at least if you're adding test coverage.

A general set of macros could be LT_USE_LIBTOOL_PUSH and _POP and could
adjust the AC_LANG setting of all configured libtool tags; the pop macro
could reset them to their original state afterwards; that would help for
encapsulation.  Or some better names I can't think of right now.

> # _KPSE_USE_LIBTOOL()
> # ---
> AC_DEFUN([_KPSE_USE_LIBTOOL],
> [## $0: Generate a libtool script for use in configure tests
> AC_PROVIDE_IFELSE([LT_INIT], ,
>   [m4_fatal([$0: requires libtool])])[]dnl
> LT_OUTPUT
> m4_append([AC_LANG(C)],
> [ac_link="./libtool --mode=link --tag=CC $ac_link"
> ])[]dnl
> AC_PROVIDE_IFELSE([AC_PROG_CXX],
> [m4_append([AC_LANG(C++)],
> [ac_link="./libtool --mode=link --tag=CXX $ac_link"
> ])])[]dnl
> AC_LANG(_AC_LANG)[]dnl
> ]) # _KPSE_USE_LIBTOOL

Thanks,
Ralf

Re: [PATCH] Add an XSI replacement for func_split_short_opt.

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Tue, Jun 29, 2010 at 08:30:43PM CEST:
> On 30 Jun 2010, at 01:22, Ralf Wildenhues wrote:
> > I think m4sh can simply use code like
> > 
> >  if ( eval '$smart_works' ) >/dev/null 2>&1; then
> >func_foo () { smart code; }
> >  else
> >func_foo () { safe code; }
> >  fi
> > 
> > for code run a handful of times, without need for extra m4 magic, it's
> > just that libtool is easily run hundreds of times in a typical large
> > software build so it warrants optimization.
> 
> In that case might the retarded shell choke and die as it parses 'smart
> code;'?

Good point.  IIRC gnulib-tool uses e.g.,
  eval 'func_foo () { smart code; }'

or eval inside the smart code, to get around that where needed.

> I don't actually know whether retarded shells mostly ignore the code
> during parsing, and can be reliably fed what they would otherwise consider
> garbage as long they are never instructed to execute the garbage... but
> it seems like something we'd need to be very careful about.

Just trying it with Solaris sh and maybe a couple of the other vendor
systems helps, these things are easily sorted out with your level of
system access.

Cheers,
Ralf

Re: [SCM] GNU Libtool branch, master, updated. v2.2.10-49-gc13532a

[Ralf Wildenhues]

[ moving from -commit to -patches, I think the former was for commits
  only; maybe it should have reply-to set? ]

Hi Gary, Peter,

* Gary V. Vaughan wrote on Sat, Jul 03, 2010 at 10:23:12AM CEST:
> On 3 Jul 2010, at 15:15, Peter Rosin wrote:
> >Fix typo in "Add func_append_quoted and do..."
> > 
> >* libltdl/config/ltmain.m4sh (func_mode_compile): Use
> >func_append_quoted instead of func_append.
[...]
> In an ideal world, we'd have test coverage of this part of the
> code,

at least after the bug was found and fixed ;-)

> and I would never have made the bogus commit in the 
> first place :(

Oh well.  So, is anyone of you working on a testsuite addition, so I'd
be doing double work?

Thanks,
Ralf

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 7)

[Ralf Wildenhues]

* Charles Wilson wrote on Sun, Jul 04, 2010 at 06:15:06AM CEST:
> On 6/26/2010 2:51 PM, Ralf Wildenhues wrote:
> > OK.  Here's my take on this: if you fix all nits I noted inline below,
> > post the updated and tested patch (you decide what testing is needed),
> > then you are OK to commit after 72 hours of waiting.  FWIW, I'm likely
> > not available most of next week; if we find issues later, then I guess
> > they'll just have to be fixed afterwards.
> 
> As discussed previously, this version fixes (almost) all of the noted
> issues. I didn't change the eval stuff, deferring instead to Ralf's
> promised patch to take care of all of that at once.

Thanks for the re-do.

> 112: override pic_flag at configure time FAILED (pic_flag.at:48)

I will fix this failure.  The test has a few issues, also on other
systems.

> 112 appears to be a new test, and is ELF specific (-fpic/-fPIC has no
> meaning on cygwin).  It probably should be skipped.
> 
> 
> So...this is what I intend to push, barring objections.

No objections from me, please wait however long I asked you to wait
(basically long enough so others have had a chance to chime in).

Thanks,
Ralf

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)

[Ralf Wildenhues]

Hi Charles,

* Charles Wilson wrote on Sat, Jul 03, 2010 at 06:10:57PM CEST:
> On 6/28/2010 2:10 AM, Ralf Wildenhues wrote:
> > * Charles Wilson wrote on Mon, Jun 28, 2010 at 12:05:40AM CEST:
> >>  It obviously isn't SUPPOSED to be dead -- or it wouldn't be there.
> > 
> > Well, I wouldn't put my money on that reasoning.
> 
> .  Except that I do recall that back-in-the-day, this code WAS
> actually used.  That's why I had to change it as I did, before your
> suggestion in Jan 2009 to use the save-.la-name-in-a-custom-variable
> approach.

OK, thanks.

> >> I feel (more) discouraged now (than usual), having wasted so much time
> >> addressing a criticism of a patch that wasn't meant to be taken seriously.
> > 
> > I would like to apologize for this comment making you do this extra
> > work.  Again, that review of mine was more sloppy than it should have
> > been.
> 
> Accepted (Although you didn't actually 'make' me do the extra work.
> Your review did not actually REQUIRE it -- but your increasing
> unhappiness with $host-specific code to ltmain.m4sh made it appear to me
> that tackling it now -- before the cross-compile patch comes up for
> review again -- was a good idea.  It wasn't.)
> 
> I apologize also for letting my frustration overtake my good sense. I
> shouldn't have complained as...vociferously. You're just doing your job:
> reviewing code to make sure libtool is as good as it can be.

No hard feelings at all on my side.  Except that I do have somewhat of a
bad conscience for letting all the w32 stuff go on for so long.

Let's hope we can improve that in the future, too.

> I guess the issue is, the shared library model of PE/COFF is just so
> different than ELF that the differences, to me, just don't seem to be
> the kind of thing that can be handled by m4 code -- at least, given the
> current architecture of the libtool script.  Now, if the ENTIRE body of
> 'libtool' were generated from libtool.m4, rather than the bulk of it
> being presented in ltmain.m4sh...then maybe the "skeleton" could be more
> platform-agnostic.
> 
> But, two things: (1) this means moving a LOT of what we probably
> consider "generic" code into libtool.m4 (imagine what that m4 would have
> to look like, to eliminate ALL case $host statements), and (2) you'd
> basically end up with, effectively, two DIFFERENT scripts that each CALL
> themselves "libtool".  The "ELF-ish" one would not look anything like
> the "PE/COFF-ish" one.
> 
> Maybe that's the right thing to do...long term.
> 
> But that's a long-term project...I was just trying to fix a single
> regression (that turned into a rabbit hole).

Yep.  I agree that a bigger cleanup could help here, and I agree that
it's better to tackle that as an orthogonal issue.  Maybe in the end
a different structuring will even be easier once all the w32 stuff
works, because then we can maybe see the bigger picture.

> >> Anyway, if we're going to try and nail down these aspects of the API, I
> >> think that's a good thing to do for libltdl2 (whether Gary's or some
> >> other brainstorm).
> > 
> > Yep, I guess.
> 
> I guess that's what I'm getting at: I think some of this ugliness is
> unavoidable given the major architectural differences between PE/COFF
> and ELF -- and the EXISTING division of labor between libtool.m4 and
> ltmain.m4sh.  "Fixing" it is going to require...*major* changes.
> 
> Given that...unless we plan to DO those major rewrites now...harping on
> them with regards to w32 is counter-productive. Peter and I will
> certainly try to put code into libtool.m4, but...it's not clear exactly
> how successful it is possible for us to be, without beginning that major
> rewrite process.

OK.  It is certainly helpful for review if you mention this with some
code that could not end up in libtool.m4 that way.

I realize I'm violently agreeing with you here as well, because your
patch postings are usually very detailedly explained, as to which
approaches you took and why and why not.

> > I'm sorry if review is painful to accept, and I
> > don't on purpose try to review in a way making you do double work.
> > That that has happened now is bad, sorry about that.
> 
> No, I think you misunderstand. *Review* is good. Critical review is even
> better.
> 
> But...the reason you found it so hard to review this patch -- I mean,
> really, having to review six different discussions spread out over two
> years? -- that's ridiculous! Who would expect THAT to happen quickly?
> But how did we GET to that p

Re: MSVC: Fix ccache test for MSVC.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Wed, Jun 30, 2010 at 09:10:02PM CEST:
> Can you please cherry-pick this commit of yours into master?
> "Fix ccache test for MSVC."
> 563c2406deb4d5ed0ebf5faf5c8b798d52ee6ac2

Done, thanks for the reminder.

> I could do it myself but I don't know what to do about the
> year 2008 that would appear in the ChangeLog, so I'm leaving
> it in your capable hands. Thanks!

Well, git cherry-pick ... && $EDITOR ChangeLog && git commit -avs --amend
easy!

> The patch was previously mentioned here:
> http://lists.gnu.org/archive/html/libtool-patches/2008-08/msg00046.html

Cheers,
Ralf

*_cmds file name expansion bug (was: MSVC: For MSVC, embed the manifest as a resource in the executable.)

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Thu, Jul 01, 2010 at 10:30:56PM CEST:
> I.e. *.exe get expanded. That doesn't happen with "*.[eE][xX][eE])":
> 
[...]
> This all seems awfully fragile. I don't know how to quote
> this expression in libtool.m4 and need help. Someone please?

Ouch.  Our expansion code is borked.  It's ok that you have a workaround
now, but that means we need to fix this.  I guess that probably means
testing for and setting noglob when the shell supports it.

Thanks for the report,
Ralf

Re: MSVC: Preloading in ltdl doesn't heed libname_spec.

[Ralf Wildenhues]

Hi Peter,

any chance you could post your patches inline?  Thanks.

* Peter Rosin wrote on Mon, Jul 05, 2010 at 02:45:28PM CEST:
> http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00152.html

This is ok with nits below addressed, thanks.

> Make preloading heed libname_spec.
> 
> * libltdl/ltdl.c (libprefix): New static variable describing
> the prefix of static archives.
> (try_dlopen): Use libprefix.
> * libltdl/m4/ltdl.m4 (_LTDL_SETUP): Export prefix of static
> archives to config.h.

Please mention which test case is fixed on which system/compiler by this
patch (the ones you know for sure).

> --- a/libltdl/ltdl.c
> +++ b/libltdl/ltdl.c
> @@ -54,6 +54,10 @@ or obtained by writing to the Free Software Foundation, 
> Inc.,
>  #  define LT_LIBEXT "a"
>  #endif
>  
> +#if !defined(LT_LIBPREFIX)
> +#  define LT_LIBPREFIX "lib"
> +#endif
> +
>  /* This is the maximum symbol size that won't require malloc/free */
>  #undef   LT_SYMBOL_LENGTH
>  #define LT_SYMBOL_LENGTH 128
> @@ -72,6 +76,7 @@ or obtained by writing to the Free Software Foundation, 
> Inc.,
>  static   const char  objdir[]= LT_OBJDIR;
>  static   const char  archive_ext[]   = LT_ARCHIVE_EXT;
>  static  const char   libext[]= LT_LIBEXT;
> +static  const char   libprefix[] = LT_LIBPREFIX;
>  #if defined(LT_MODULE_EXT)
>  static   const char  shlib_ext[] = LT_MODULE_EXT;
>  #endif
> @@ -1272,8 +1277,8 @@ try_dlopen (lt_dlhandle *phandle, const char *filename, 
> const char *ext,
>  
>if (vtable)
>   {
> -   /* name + "." + libext + NULL */
> -   archive_name = MALLOC (char, LT_STRLEN (name) + strlen (libext) + 2);
> +   /* libprefix + name + "." + libext + NULL */
> +   archive_name = MALLOC (char, strlen (libprefix) + LT_STRLEN (name) + 
> strlen (libext) + 2);
> *phandle = (lt_dlhandle) lt__zalloc (sizeof (struct lt__handle));
>  
> if ((*phandle == NULL) || (archive_name == NULL))
> @@ -1285,7 +1290,14 @@ try_dlopen (lt_dlhandle *phandle, const char 
> *filename, const char *ext,
>  
> /* Preloaded modules are always named according to their old
>archive name.  */
> -   sprintf (archive_name, "%s.%s", name, libext);
> +   if (strncmp(name, "lib", 3) == 0)
> + {
> +   sprintf (archive_name, "%s%s.%s", libprefix, name + 3, libext);
> + }
> +   else
> + {
> +   sprintf (archive_name, "%s.%s", name, libext);
> + }
>  
> if (tryall_dlopen (&newhandle, archive_name, advise, vtable) == 0)
>   {

> --- a/libltdl/m4/ltdl.m4
> +++ b/libltdl/m4/ltdl.m4
> @@ -410,6 +410,11 @@ AC_CHECK_FUNCS([strlcat strlcpy], [], 
> [AC_LIBOBJ([lt__strl])])
>  m4_pattern_allow([LT_LIBEXT])dnl
>  AC_DEFINE_UNQUOTED([LT_LIBEXT],["$libext"],[The archive extension])
>  
> +name=
> +lt_libprefix=`eval "\\$ECHO \"$libname_spec\""`

This is simpler, less buggy, and more efficiently written as
   eval "lt_libprefix=\"$libname_spec\""

> +m4_pattern_allow([LT_LIBPREFIX])dnl
> +AC_DEFINE_UNQUOTED([LT_LIBPREFIX],["$lt_libprefix"],[The archive prefix])
> +
>  name=ltdl
>  LTDLOPEN=`eval "\\$ECHO \"$libname_spec\""`

This, too.

>  AC_SUBST([LTDLOPEN])

Cheers,
Ralf

Re: MSVC: Support for response files with $NM.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Fri, Jul 02, 2010 at 02:45:47PM CEST:
> The MSVC linker can't do relinking (-r -o), and this patch avoids
> a usage of that in libtool when it digs for symbols in large
> numbers of object files. With the patch I get identical behavior
> inside "Run tests with low max_cmd_len" as I do outside, without
> the patch lots of stuff go belly-up with low max_cmd_len. I found
> no regressions on neither cygwin/gcc nor debian/gcc (admittedly
> both with "recent" binutils nm, supporting @FILE).

Did you confirm that the debian/gcc case actually uses the @FILE code
path in the testsuite (should be in the low_cmd_len tests)?

> 2010-07-01  Ralf Wildenhues  
>   Peter Rosin  
> 
>   Support for response files with $NM.
>   * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS)
>   : New tag variable. Set it to '@' if input
>   files can be passed to $NM in a file named with the '@' option.
>   * libltdl/config/ltmain.m4sh (func_mode_link): When
>   nm_file_list_spec is nonempty, use it to avoid skipped_export.
>   * doc/libtool.texi (libtool script contents): Document
>   new variable.

You've pushed this already, but I still have nits:

> --- a/libltdl/config/ltmain.m4sh
> +++ b/libltdl/config/ltmain.m4sh
> @@ -6719,14 +6719,30 @@ EOF
>   $opt_dry_run || $RM $export_symbols
>   cmds=$export_symbols_cmds
>   save_ifs="$IFS"; IFS='~'
> - for cmd in $cmds; do
> + for cmd1 in $cmds; do
> IFS="$save_ifs"
> -   eval cmd=\"$cmd\"
> +   eval cmd=\"$cmd1\"
> func_len " $cmd"
> len=$func_len_result
> if test "$len" -lt "$max_cmd_len" || test "$max_cmd_len" -le -1; 
> then
>   func_show_eval "$cmd" 'exit $?'
>   skipped_export=false
> +   elif test -n "$nm_file_list_spec"; then

Actually, why even do the expensive test for long command lines, and not
just go for the spec file all the time?  I'm not sure we really want to
do this, as it hampers debugging a bit (the developer doesn't readily
see the contents of the response file), but it surely would be a bit
more efficient.

> + output_la=`$ECHO "X$output" | $Xsed -e "$basename"`

save 2 fork&exec:

func_basename "$output"
output_la=$func_basename_result

> + save_libobjs=$libobjs
> + save_output=$output
> + output=${output_objdir}/${output_la}.nm
> + libobjs=$nm_file_list_spec$output
> + func_append delfiles " $output"
> + func_verbose "creating $NM input file list: $output"
> + for obj in $save_libobjs; do
> +   $ECHO "$obj"
> + done > "$output"
> + eval cmd=\"$cmd1\"

This eval is wrong and shouldn't be necessary, func_show_eval below
already does an evaluation.  Please check that it is not needed.

> + func_show_eval "$cmd" 'exit $?'
> + output=$save_output
> + libobjs=$save_libobjs
> + skipped_export=false
> else
>   # The command line is too long to execute in one step.
>   func_verbose "using reloadable object file for export list..."

Thanks,
Ralf

Re: MSVC: Preloading in ltdl doesn't heed libname_spec.

[Ralf Wildenhues]

Hi Bob,

* Bob Friesenhahn wrote on Tue, Jul 06, 2010 at 06:48:56AM CEST:
> On Mon, 5 Jul 2010, Bob Friesenhahn wrote:
> >Yesterday's libtool was doing quite good with the tests but I am
> >seeing plenty of failures now for all Unixish targets.  Even Linux
> >blows failures all over the place.  Not to worry, it is likely
> >something simple.
> 
> Perhaps things are not all that bad.  While 35 of 110 tests fail
> under Debian Linux, only these two extra are failing under FreeBSD,
> OS-X, and Solaris:
> 
> FAIL: tests/mdemo2-make.test
> FAIL: tests/pdemo-make.test

It would probably be even more helpful if you posted verbose test
failure output (or excerpts), that would make assigning blame easier,
I guess.

Cheers,
Ralf

Re: MSVC: Support for response files with $NM.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Tue, Jul 06, 2010 at 11:27:31AM CEST:
> Den 2010-07-06 08:07 skrev Ralf Wildenhues:
> >Did you confirm that the debian/gcc case actually uses the @FILE code
> >path in the testsuite (should be in the low_cmd_len tests)?
> 
> No I didn't, but now I have and nm @FILE is used by at least export.at,
> deplib-in-subdir.at and stresstest.at. And it works just fine for
> me.

Thanks for verifying.

> >>--- a/libltdl/config/ltmain.m4sh
> >>+++ b/libltdl/config/ltmain.m4sh
> >>@@ -6719,14 +6719,30 @@ EOF
> >>$opt_dry_run || $RM $export_symbols
> >>cmds=$export_symbols_cmds
> >>save_ifs="$IFS"; IFS='~'
> >>-   for cmd in $cmds; do
> >>+   for cmd1 in $cmds; do
> >>  IFS="$save_ifs"
> >>- eval cmd=\"$cmd\"
> >>+ eval cmd=\"$cmd1\"
> >>  func_len " $cmd"
> >>  len=$func_len_result
> >>  if test "$len" -lt "$max_cmd_len" || test "$max_cmd_len" -le -1; 
> >> then
> >>func_show_eval "$cmd" 'exit $?'
> >>skipped_export=false
> >>+ elif test -n "$nm_file_list_spec"; then
> >
> >Actually, why even do the expensive test for long command lines, and not
> >just go for the spec file all the time?  I'm not sure we really want to
> >do this, as it hampers debugging a bit (the developer doesn't readily
> >see the contents of the response file), but it surely would be a bit
> >more efficient.
> 
> I wanted to change as little as possible. The expensive test was not
> added by the patch, so I don't feel too bad about that. I didn't
> even realize it was expensive, but if that's the case it is
> certainly possible to first test for nm_file_list_spec and only do
> the max_cmd_len test otherwise.

As I said, I'm not sure which behavior is more desirable; there is a
tradeoff performance vs. readability of build output to make here.

This was really meant as a point for discussion rather than a patch nit,
sorry for not being clear enough here.

> >>+   save_libobjs=$libobjs
> >>+   save_output=$output
> >>+   output=${output_objdir}/${output_la}.nm
> >>+   libobjs=$nm_file_list_spec$output
> >>+   func_append delfiles " $output"
> >>+   func_verbose "creating $NM input file list: $output"
> >>+   for obj in $save_libobjs; do
> >>+ $ECHO "$obj"
> >>+   done>  "$output"
> >>+   eval cmd=\"$cmd1\"
> >
> >This eval is wrong and shouldn't be necessary, func_show_eval below
> >already does an evaluation.  Please check that it is not needed.
> 
> The double eval was there before, so the patch just copied the
> existing style. Or didn't it? The code was:

Whatever.  It is wrong to do the double eval for anything here, it's
only that the func_len test needs one because func_show_eval already
does an eval and func_len doesn't (and shouldn't).  I'll fix it.

Thanks,
Ralf

Re: [PATCH RFC] Add sysroot support.

[Ralf Wildenhues]

Hello Thierry,

thanks for your patch and explanations.

* Thierry Reding wrote on Wed, Jul 07, 2010 at 11:51:58AM CEST:
> the following patch adds support for gcc's --sysroot argument to libtool.
> I'll post the patch first and will reply to it, giving more details where
> needed.
> 
> I've been building a number of packages with variations of this patch
> depending on the libtool version. The most tricky packages were those
> building multiple libtool libraries with inter-dependencies (like glib and
> gtk). But even those build fine with this patch.
> 
> One more important fact is that after installing packages I always delete the
> .la files from my sysroot so that any dependencies will never try to link
> against the .la file but against the .so directly. This seems to work rather
> well.

Well, but that is not a practice we would like to recommend; rather, it
would be better if libtool wouldn't misinterpret references in those .la
files to point to /usr rather than the sysroot.

> I welcome any comments or suggestions.

I haven't looked at the patch much at all yet, but will do so; first
though we should get copyright assignment out of the way (more on this
off-list), because otherwise we shouldn't be looking at your patch at
all.

Then, for the patch to be complete, several things are missing: a
ChangeLog entry, NEWS and libtool.texi updates, and most importantly,
testsuite additions.  It is really and utmostly important that the
features your patch aims to support are covered in the testsuite,
otherwise somebody will break it two months down the road.

If you find adding code to the Autotest test suite difficult, then we
can easily write that if you just give small example setups that work
with the patch but not without.

> --- a/libltdl/config/ltmain.m4sh
> +++ b/libltdl/config/ltmain.m4sh
> @@ -1608,6 +1608,10 @@ func_mode_install ()
>   func_append dir "$objdir"
>  
>   if test -n "$relink_command"; then
> +   if test -n "$sysroot"; then
> + libdir=`$ECHO "$libdir" | $SED -e "s%$sysroot%%"`

The sed script should get only an version of $sysroot with sed special
character escaped suitably.  If we don't have such code in libtool yet,
Automake uses it in the am__nobase_strip_setup variable setting.

Cheers, and thanks again,
Ralf

verbose test output (was: MSVC: Preloading in ltdl doesn't heed libname_spec.)

[Ralf Wildenhues]

Hello Bob,

* Bob Friesenhahn wrote on Thu, Jul 08, 2010 at 06:34:46PM CEST:
> On Tue, 6 Jul 2010, Ralf Wildenhues wrote:
> >>
> >>Perhaps things are not all that bad.  While 35 of 110 tests fail
> >>under Debian Linux, only these two extra are failing under FreeBSD,
> >>OS-X, and Solaris:
> >>
> >>FAIL: tests/mdemo2-make.test
> >>FAIL: tests/pdemo-make.test
> >
> >It would probably be even more helpful if you posted verbose test
> >failure output (or excerpts), that would make assigning blame easier,
> >I guess.
> 
> Yes.  And in fact it would be even better if the test suite always
> produced/retained "verbose" output for failed tests so that the
> information is always immediately available on demand.

That *is* already the case for the new testsuite.  It even tells you at
the end where to find the file, and to send it.

>  The fact
> that it does not should be considered to be a bug.

For the old testsuite, it will be the case once I have finished the
conversion to the Automake parallel-tests driver.  No wait long but no
time have right now.  Gimme a couple of weekends.

> I am thinking that the many test failures under Debian Linux are due
> to it using older tool versions such as Autoconf 2.61.

Facts, not thinking, please.  We cannot read your computer's mind.

Thanks!
Ralf

Re: [SCM] GNU Libtool branch, master, updated. v2.2.10-59-g8c4dae1

[Ralf Wildenhues]

[ moving from -commit ]

Hi Gary,

* Gary V. Vaughan wrote on Thu, Jul 08, 2010 at 03:37:23PM CEST:
> commit 8c4dae1232958c24989f31ab5b5768d00be2ef03
> Author: Gary V. Vaughan 
> Date:   Thu Jul 8 18:47:59 2010 +0700
> 
> Fix a spurious trailing space and a botched merge.
> 
> * libltdl/m4/libtool.m4 (_LT_PROG_FUNCTION_REPLACE): Remove
> spurious trailing space.
> * ChangeLog: Reorder to match commit order after botched
> merge.

Make botched ChangeLog merges a thing of the distant, easily forgotten
past by getting to know, installing and configuring git-merge-changelog,
currently distributed as a gnulib module of the same name.  Be sure to
use recent git gnulib.  It's really that good!

Cheers,
Ralf

Re: MSVC: Always dllimport the variable for MSVC in link-order.at

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Sat, Jul 10, 2010 at 10:15:09AM CEST:
> Next in to MSVC queue...
> 
> This is a variation of
> 95bdbc456f7c5d6d669121cf20d62a9c28bec2bf
> "Always dllimport the variable for MSVC in link-order.at"
> 
> Patch previously discussed here:
> http://lists.gnu.org/archive/html/libtool-patches/2008-08/msg00053.html
> 
> In that discussion I claim that "With MSVC, you can declare any variable
> with __decspec(dllimport), even if you are not actually importing it"
> and I must have been thoroughly confused when I arrived at that
> conclusion. It doesn't hold when I now try it...
> 
> So, instead of just "#ifdef _MSC_VER", this version does
> #if defined _MSC_VER && defined PIC
> #  define LIBCEE_SCOPE __declspec(dllimport)
> 
> Now, the PIC part isn't truly what we want to test for, since we don't
> really want to dllimport when we a *building* a PIC library. We want
> to dllimport when we *use* a shared library. But in this case it happens
> to coincide, and the notion of using a shared vs. static library isn't
> really covered by libtool, i.e. there's no -DUSE_PIC or equivalent that
> can be used to discriminate in the code.

the patch looks fairly innocent at first sight, but your description
makes me wonder how a user is going to get that right.  In fact, I don't
see how we *can* get that right as the preferred form of linking (static
or shared) might not yet be known at compile time at all.  So I guess
the only viable route is to document the limitation somewhere, and tell
developers and users what to do and expect in face of it.

Is that documentation step hidden somewhere in your queue already, or
does that still need to be done?

Thanks,
Ralf

> 2010-07-10  Peter Rosin  
> 
>dllimport the variable for MSVC in link-order.at
>* tests/link-order.at [MSVC]: Makes the test pass by dllimporting
>imported variables when working with shared libraries.

Re: MSVC: Always dllimport the variable for MSVC in link-order.at

[Ralf Wildenhues]

Hi Peter, Charles,

* Peter Rosin wrote on Thu, Jul 15, 2010 at 10:39:42PM CEST:
> Den 2010-07-12 07:46 skrev Ralf Wildenhues:
> >* Peter Rosin wrote on Sat, Jul 10, 2010 at 10:15:09AM CEST:
> >the patch looks fairly innocent at first sight, but your description
> >makes me wonder how a user is going to get that right.  In fact, I don't
> >see how we *can* get that right as the preferred form of linking (static
> >or shared) might not yet be known at compile time at all.  So I guess
> >the only viable route is to document the limitation somewhere, and tell
> >developers and users what to do and expect in face of it.
> 
> This is nothing new. It is the same situation that applied to GNU on
> Windows before auto-import, I think. I'm quoting this off-list
> conversation with Chuck (off-list due to some misunderstanding) that
> describes the situation quite well:

Thanks for reproducing this, it is quite enlightening, and I'm afraid I
really had forgotten most of this again since a couple of years ago.

[...]
> The above implies that you need to select one way to do this universally
> for "my target", but I don't think that you need to do the same everywhere.
> So, I just just the method that cleared up the test case in the least
> intrusive way I could think of.

OK.  The patch is fine with me then.

> [back to Ralf's message]
> 
> >Is that documentation step hidden somewhere in your queue already, or
> >does that still need to be done?
> 
> It is not hidden in my queue, so it is a TODO.

OK.  Do we need to remember it somewhere (e.g., in TODO, exept that
this is hopelessly outdated)?

> I didn't think the onus
> was on me to write this as it has been a known issue on Windows for a
> long time (I was just temporarily fooled that it was a non-issue with
> MSVC when I misguidedly thought you could always dllimport with it).

I didn't mean to imply that the onus is on you.  Just that it needs to
be done.

> The manual already says that it is not portable to export data items from
> a libtool library. At least I think it does.

The "Library tips" nodes has a bit.

Cheers, and thanks,
Ralf

Re: MSVC: Always dllimport the variable for MSVC in link-order.at

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Sat, Jul 17, 2010 at 04:33:07AM CEST:
> Den 2010-07-16 05:36 skrev Ralf Wildenhues:

> >>The manual already says that it is not portable to export data items from
> >>a libtool library. At least I think it does.
> >
> >The "Library tips" nodes has a bit.
> 
> Hmmm, my memory says that I have read something with the meaning that
> exporting variables makes your life difficult on some platforms but I
> now fail to find it in the libtool manual. Strange...

Quoting from above node:

Use opaque data types
 The fewer data type definitions a library user has access to, the
 better.  [...]

Not totally clear ...

Cheers,
Ralf

Re: MSVC: stresstest.at fixes

[Ralf Wildenhues]

Hello Peter,

* Peter Rosin wrote on Sun, Jul 18, 2010 at 06:45:53PM CEST:
> Next in the MSVC queue. It's getting short quickly!
> 
> These two patches are commits
> ee8c181987478752a9432a903cf7febbf761d034
> dllimport when the lib is shared and not linking with -static
> 
> and
> 
> 5ff2e6e4e5a1f05df59ccf11ba881de9df895cb5
> dllimport variables for MSVC in stresstest.at
> 
> Previous review:
> http://lists.gnu.org/archive/html/libtool-patches/2008-08/msg00056.html
> 
[...]
> The second patch is very similar to how things are done in export.at,
> see commit b28132eabade54dbb9ff18a5761be445d916e148 and the recent
> thread at
> http://lists.gnu.org/archive/html/libtool-patches/2010-07/msg00026.html

The two patches are ok, thanks.  However, both of them are another
instance of the "if a developer not familiar with MSVC and/or w32
semantics wants to create code portable to this system, then the Libtool
manual needs to provide more documentation in order to make this clear"
TODO item.

Charles, I'm with Peter in that you should prioritize as you please,
independently of this.

Thanks,
Ralf

> 2010-07-18  Peter Rosin  
> 
>   * tests/stresstest.at: Link with main.lo when liba is shared
>   and linking main with -no-install.

> 2010-07-18  Peter Rosin  
> 
>   * tests/stresstest.at [MSVC]: dllimport all imported
>   variables.

Re: MSVC: Support for response files with $NM.

[Ralf Wildenhues]

Hi Peter,

a little while ago:

* Peter Rosin wrote on Wed, Jul 07, 2010 at 10:15:53PM CEST:
> No problem, but I was initially very confused (and still am) by the
> fact that
> 
> make check-local TESTSUITEFLAGS='-v -d -k max_cmd_len' \
>   INNER_TESTSUITEFLAGS=',export -v -d export' | grep creating
> 
> did not catch output from this line:
>   func_verbose "creating $NM input file list: $output"
> 
> (and no trace of it in either of
> tests/testsuite.log,
> tests/testsuite.dir/111/testsuite.log or
> tests/testsuite.dir/111/testsuite.dir/044/testsuite.log
> either)
> 
> I had to change func_verbose to echo in the above line to finally
> be able to verify.
> 
> What's up with that?

Well, func_verbose only outputs if --verbose is passed.  The rules are a
bit obtuse, granted, but were some sort of compromise.

> + func_verbose "creating $NM input file list: $output"
> + for obj in $save_libobjs; do
> +   $ECHO "$obj"
> + done>   "$output"
> + eval cmd=\"$cmd1\"
> >>>
> >>>This eval is wrong and shouldn't be necessary, func_show_eval below
> >>>already does an evaluation.  Please check that it is not needed.
> >>
> >>The double eval was there before, so the patch just copied the
> >>existing style. Or didn't it? The code was:
> >
> >Whatever.
> 
> Oh, I didn't mean to imply that I don't care, but I find that I
> need 100% attention on getting libtool to do what I want. I just
> don't usually have anything left for the bigger picture...

That's fine really.  I was hitting the wrong tone again in my previous
message, sorry.

> (but perhaps I should also point out that I think you wrote that
> part of the patch, and I didn't really look at those aspects of
> that code, the code looked fine to me and it did what I wanted)

Hey, just because I wrote it, doesn't mean it's right, or that I won't
find it objectionable at some other point in time.  ;-)
Point well taken in getting blame assigned to the right person though.

Cheers,
Ralf

Re: [PATCH RFC] Add sysroot support.

[Ralf Wildenhues]

Hello,

* Paolo Bonzini wrote on Wed, Jul 21, 2010 at 06:04:43PM CEST:
> On 07/21/2010 03:58 PM, Charles Wilson wrote:
> >On 7/8/2010 1:02 PM, Paolo Bonzini wrote:
> >
> >>I have another sysroot patch that seems (from a first cursory view)
> >>pretty different.  I'll rebase and send.
> >
> >Ping?
> 
> Rebasing was a bit troublesome due to the "replace shell function
> implementation" change.  In the weekend I should be done.

It would probably be fine to send even without rebasing.
Post the parent SHA or git describe, and ideally send with
format-patch, that makes it fairly easy to go from there.

The biggest part of the needed work on this topic is defining
exactly what impact sysroot is to have, and expressing that in
a number of test cases.  So that we can be sure that it works,
and tell bug reporters later to fix their setups if we don't
(or can't also) support them.  I see quite a bit of variation
in how sysroot setups are done, and Charles' explanation hints
at this issue, too.

Cheers,
Ralf

Re: [RFT PATCH v3 2/9] handle sysroot flags

[Ralf Wildenhues]

Hi Paolo,

patch 1/9 is OK right away.  Thanks!

* Paolo Bonzini wrote on Thu, Jul 29, 2010 at 01:23:15AM CEST:
> * libltdl/config/ltmain.m4sh (func_mode_link): Recognize --sysroot
> option.

This patch 2/9 is OK but please commit together with the rest.

Thanks,
Ralf

Re: [RFT PATCH v3 3/9] add --with-sysroot

[Ralf Wildenhues]

Next one: 3/9.   This is a bit of a preliminary review, because I
haven't read all patches and all of the discussion yet.

* Paolo Bonzini wrote on Thu, Jul 29, 2010 at 01:23:16AM CEST:
> * libltdl/m4/libtool.m4 (_LT_HOST_NONCANONICAL, _LT_WITH_SYSROOT): New.
> (LT_SETUP): Require _LT_WITH_SYSROOT.
> 
> Signed-off-by: Paolo Bonzini 
> ---
> Right now the default is to use a sysroot.  Probably it is
> a bit too aggressive, especially because most existing
> cross-compilation setups are using the wrong prefix that
> includes the sysroot.  They would thus stop working until
> they switched to --prefix and installing with DESTDIR.

Can you explain this comment in a bit more detail?  What do you mean
with "use the wrong prefix"?  Is that, they use
  ./configure --prefix=/win-mount/usr
  make
  make install

but should be using
  ./configure --prefix=/usr
  make
  make install DESTDIR=/win-mount

instead?

Thanks.  Ideally, the answer is put in the form of a diff against the
manual.  ;-)

> --- a/libltdl/m4/libtool.m4
> +++ b/libltdl/m4/libtool.m4
> @@ -173,6 +173,7 @@ m4_require([_LT_CHECK_MAGIC_METHOD])dnl
>  m4_require([_LT_CHECK_SHAREDLIB_FROM_LINKLIB])dnl
>  m4_require([_LT_CMD_OLD_ARCHIVE])dnl
>  m4_require([_LT_CMD_GLOBAL_SYMBOLS])dnl
> +m4_require([_LT_WITH_SYSROOT])dnl
>  
>  _LT_CONFIG_LIBTOOL_INIT([
>  # See if we are running on zsh, and set the options which allow our
> @@ -1163,6 +1164,55 @@ _LT_DECL([], [ECHO], [1], [An echo program that 
> protects backslashes])
>  ])# _LT_PROG_ECHO_BACKSLASH
>  
>  
> +# _LT_HOST_NONCANONICAL
> +# 
> +AC_DEFUN([_LT_HOST_NONCANONICAL],
> +[build_noncanonical=${build_alias:-$ac_build_alias}
> +host_noncanonical=${host_alias:-$build_noncanonical}

This needs to AC_REQUIRE AC_CANONICAL_{BUILD,HOST}.

> +target_noncanonical=${target_alias:-$host_noncanonical}

This either needs to AC_REQUIRE AC_CANONICAL_TARGET or act
m4-conditionally upon whether that has been provided before.
Before the patch series, $target is not automatically used
in packages using AC_PROG_LIBTOOL, it would be nice if it
could be kept that way, because it tends to cause lot of
confusion still.

If you care about ordering, an AC_BEFORE to warn about
AC_CANONICAL_TARGET after AC_PROG_LIBTOOL can be added
(the warning can be appended to the former in the same
way Libtool sticks code to AC_PROG_CC et al).

> +_LT_DECL([], [build_noncanonical], [0],
> +  [The user-supplied name of the build machine.])dnl
> +_LT_DECL([], [host_noncanonical], [0],
> +  [The user-supplied name of the host machine.])dnl

> +_LT_DECL([], [target_noncanonical], [0],
> +  [The user-supplied name of the target machine.])

Likewise for this _LT_DECL.

Actually, I don't see any other uses of target in the whole patch
series, so why not just omit that here?

> +])# _LT_HOST_NONCANONICAL
> +
> +# _LT_WITH_SYSROOT
> +# 
> +AC_DEFUN([_LT_WITH_SYSROOT],
> +[AC_REQUIRE([_LT_HOST_NONCANONICAL])
> +AC_MSG_CHECKING([for sysroot])
> +AC_ARG_WITH([sysroot],
> +[  --with-sysroot[=DIR] Search for dependent libraries within DIR

Please use quadrigraphs for the optional argument.

> +(or the compiler's sysroot if not specified).],
> +[], [with_sysroot=no])

The GCC package specifies --with-sysroot in at least its
gcc/configure.ac as well, with slightly incompatible semantics (setting
to empty not no); how to address this?  codesearch finds other instances
as well (e.g., LLVM), I'm not sure how to address these (not even sure
they use Libtool) except for a big sign in NEWS, and documentation in
the manual.

> +dnl lt_sysroot will always be passed unquoted.  We quote it here
> +dnl in case the user passed a directory name.
> +lt_sysroot=
> +case ${with_sysroot} in #(
> + yes)
> +   if test "$GCC" = yes; then
> + lt_sysroot=`$GCC --print-sysroot 2>/dev/null`

OK, GCC between 2.7.2.3 and 4.2 print an error message on stderr and
exit 1.  Can we blissfully assume the user knows what she's doing when
passing --with-sysroot?  I'd guess so.

> +   fi
> +   ;; #(
> + /*)

Can it be a windows C:/sys-root style path?

> +   AC_MSG_RESULT([$with_sysroot])
> +   lt_sysroot=`echo "$with_sysroot" | sed -e "$sed_quote_subst"`
> +   ;; #(
> + no)

Normalization of "no" to empty?  The rest of the series doesn't
special-case "no", and I think empty would please GCC configury, too
(untested).

> +   ;; #(
> + *)
> +   AC_MSG_RESULT([])

Why not print the borked result?

> +   AC_MSG_ERROR([The sysroot must be an absolute path.])
> +   ;;
> +esac
> +
> + AC_MSG_RESULT([${with_sysroot:-no}])

Duplicate results in the code path going through the /* case above.

> +_LT_DECL([], [lt_sysroot], [0], [The root where to search for ]dnl
> +[dependent libraries, and in which our libs should be installed.])])

s/libs/libraries/

>  # _LT_ENABLE_LOCK
>  # ---
>  m4_defun([_LT_ENABLE_LOCK],

Thanks,
Ralf

Re: using ld for linking non-C code

[Ralf Wildenhues]

* Charles Wilson wrote on Sun, Aug 01, 2010 at 02:10:36PM CEST:
> On 8/1/2010 6:46 AM, Ralf Wildenhues wrote:
> > Because that allows it to set run paths to the compiler libs?
> > (I don't know either.)
> 
> Hmm. If so, what use case does that capability have? You want to install
> an application compiled with a non-standard compiler, but whose compiler
> runtime lib has the same name as the standard one, so only the standard
> one is "registered" in ld.so.conf?
> 
> It seems that this is such an odd use case that it should be handled
> separately (e.g. via a libtool option that the user can pass via LDFLAGS
> (-use-syslib-rpath), rather than built in to the way libtool operates
> normally).

Could be.

I thought of another reason: likely, for a while the compiler drivers
simply couldn't create shared libraries correctly.  Seems very weird,
yes, but look at some Fortran compilers where that's still the case
today.

> > It precedes my time anyway.  We should clean it up and disable it for
> > the compilers and systems where we know that it works.  That is a
> > separate issue, and hopefully we can keep it separate, but IIUC it
> > influences this patch series and how much work it is to get right.
> > Not sure which strategy would be easiest for you.
> 
> I agree it is a separate issue.  Paolo has already found the reason that
> his original patch broke the postdep detection, and fixed it, so it's
> really not an immediate issue with respect to sysroot.
> 
> At some point it will be necessary to take the plunge, as various g++
> (and even, gcc) flags like -shared-{libgcc|libstdc++|libfortran?} (or
> -static-*) can affect both postdep detection and final link behavior.
> 
> But it'll be a big scary change, no doubt.

Agreed on all counts.  Good thing we can keep the issues separate.

Cheers,
Ralf

using ld for linking non-C code (was: [REBASED PATCH 0/9] Paolo's sysroot patches, rebased plus some fixes)

[Ralf Wildenhues]

* Charles Wilson wrote on Mon, Jul 26, 2010 at 01:57:57PM CEST:
> As an aside, WHY is it that libtool tries to figure out what the language 
> driver
> does, and use ld directly, rather than just trust the language driver and use 
> it
> to link instead?  It seems that the current libtool behavior causes a lot of
> problems because it is quite fragile...

Because for a long time, the drivers were broken? (I don't know.)

Because that allows it to set run paths to the compiler libs?
(I don't know either.)

It precedes my time anyway.  We should clean it up and disable it for
the compilers and systems where we know that it works.  That is a
separate issue, and hopefully we can keep it separate, but IIUC it
influences this patch series and how much work it is to get right.
Not sure which strategy would be easiest for you.

Cheers,
Ralf

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

* Paolo Bonzini wrote on Sun, Aug 01, 2010 at 04:47:26PM CEST:
> This should, and I say "should" :) pass all tests.

Thanks for the repost.  Did anything change beside the discussion
attached to the last patch series post?

This passes for me on GNU/Linux with a non sysrooted GCC.  How come
there is no testsuite coverage for --with-sysroot for such compilers
though?  Is that option not usable in that case?

Cheers,
Ralf

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

* Charles Wilson wrote on Sun, Aug 01, 2010 at 08:03:11PM CEST:
> On 8/1/2010 10:47 AM, Paolo Bonzini wrote:
> >> 112: override pic_flag at configure time   FAILED (pic_flag.at:48)
> >>
> >> 112 has been discussed before and should be
> >> skipped on non-ELF.
> > 
> > Since I wasn't around, why is this regressing?  Is it intermittent?
> > Maybe a double-check of the testsuite.dir would be nice.
> 
> It's not technically a "regression" since AFAIK there was never a time
> when that particular test actually passed on cygwin/mingw.  IIRC, it is
> a new testsuite addition that was never validated on cygwin/mingw.  The
> fact that the test failed on cygming just wasn't caught until I reported
> it some months ago, in another context.
> 
> However, there have always been bigger fish to fry, so nobody has gotten
> around to making it skip on non-ELF, or figuring out how to translate
> the test into terms that might make sense on PE/COFF.

I have it on my TODO list (since I wrote the test in the first place),
but people keep pushing review tasks further up my TODO list ... ;-)

Just ignore the failure for now; it is merely a testsuite bug.

Cheers,
Ralf

Re: [RFT PATCH v4 6/8] emit sysrooted paths when installing .la files

[Ralf Wildenhues]

* Paolo Bonzini wrote on Sun, Aug 01, 2010 at 04:47:32PM CEST:
> * libltdl/config/ltmain.m4sh (func_replace_sysroot): New.
> (func_mode_link): Prepend paths in $libdir with the sysroot.  Further,
> replace the sysroot with = (using func_replace_sysroot) whenever
> such a path is written in a .la file.

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

> @@ -8064,7 +8093,7 @@ EOF
>   eval libdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $lib`
>   test -z "$libdir" && \
> func_fatal_error "\`$lib' is not a valid libtool archive"
> - func_append newdlfiles " $libdir/$name"
> + func_append newdlfiles " ${lt_sysroot:+=}$libdir/$name"

Although it is fairly unlikely, I prefer not relying on :+ support, so
please replace with 'if test -z "$lt_sysroot"...'.  Two instances.

>   ;;
> *) func_append newdlfiles " $lib" ;;
> esac
> @@ -8083,7 +8112,7 @@ EOF
>   eval libdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $lib`
>   test -z "$libdir" && \
> func_fatal_error "\`$lib' is not a valid libtool archive"
> - func_append newdlprefiles " $libdir/$name"
> + func_append newdlprefiles " ${lt_sysroot:+=}$libdir/$name"
>   ;;
> esac
>   done

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

* Paolo Bonzini wrote on Sun, Aug 01, 2010 at 04:47:26PM CEST:
>   handle sysroot flags
>   add --with-sysroot
>   teach libtool -L= and -R=
>   handle sysrooted paths when reading dependencies to la files
>   process postdeps to include sysrooted paths
>   emit sysrooted paths when installing .la files
>   add sysroot test
>   initial version of the NEWS entry

The overall series looks fairly good to me, thanks to you and Charles
for the hard work on it.  Please s/2009/2010/ in the new testsuite file,
and spaces before open parentheses for C and shell functions, thanks.

I can't really give a good review of the rest without a sysrooted
compiler, and I don't have time to build one any more this weekend,
so I'd appreciate if you could post output of
  make check-local TESTSUITEFLAGS='-v -d -x -k sysroot'

for both w32 and GNU/Linux (and other systems you happen to be able to
test); thanks.  Might still take me until next weekend though, sorry.

After nits have been addressed, also please feel free to push the patch
series to a temporary git branch (off of master) on savannah.  I expect
that it will be mergeable with minor corrections.  I really do think
however that a libtool.texi update would be fairly important to have.

Also, I still don't quite understand why this is unusable when the
compiler is not sysrooted, so an explanation would be nice.  For
example, the w32 cross compiler package on Debian is not sysrooted.

Thanks,
Ralf

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

* Charles Wilson wrote on Mon, Aug 02, 2010 at 06:15:29AM CEST:
> > On 8/1/2010 2:43 PM, Ralf Wildenhues wrote:
> >> I can't really give a good review of the rest without a sysrooted
> >> compiler, and I don't have time to build one any more this weekend,
> >> so I'd appreciate if you could post output of
> >>   make check-local TESTSUITEFLAGS='-v -d -x -k sysroot'

> I've attached the logs from the cygwin->mingw test and the linux->mingw
> test. The actual testsuite dirs are here:
> 
> http://cygwin.cwilson.fastmail.fm/ITP/libtool-sysroot-cygwin-mingw-cross-tests.tar.lzma
> http://cygwin.cwilson.fastmail.fm/ITP/libtool-sysroot-linux-mingw-cross-tests.tar.lzma

This should be fixed:

| ++ make all
| stderr:
| lib2.c: In function 'g':
| lib2.c:6:13: warning: initialization makes pointer from integer without a cast
| stdout:

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

* Charles Wilson wrote on Sun, Aug 01, 2010 at 10:04:16PM CEST:
> support, use --prefix=/mingw + DESTDIR=/the-sysroot.

What about the w32 users that use --prefix=C:/mingw and then cannot use
DESTDIR because that will not concatenate?

Also, in 'ln -sf' in the testsuite addition, the -f is non-portable
to Solaris, and for DJGPP (cough) it would even need $(LN_S) but let's
ignore that for now.

Thanks,
Ralf

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

* Charles Wilson wrote on Mon, Aug 02, 2010 at 08:00:47PM CEST:
> On 8/2/2010 1:55 PM, Ralf Wildenhues wrote:
> >What about the w32 users that use --prefix=C:/mingw and then cannot use
> >DESTDIR because that will not concatenate?
> 
> According to the GNU Standards, you can always do this after building:
> 
> make prefix=/new/destdir/old-prefix
> 
> And -- supposedly -- "/new/destdir" is not supposed to appear
> anywhere in the installed files.  So, if you're doing a cross build
> for a mingw $host, you can do this:
> 
> configure --prefix=C:/MinGW && make
> make install --prefix=/tmp/dest/MinGW
> 
> and create your installable tarball from /tmp/dest.

So are you saying this works with this very patch series?  If yes, then
very cool, and I'd very much like this to be exposed in the testsuite
(only on w32 systems, of course, and the C:/... path should be something
unlikely to clash with any actual user files, in case make install does
write there after all).

Thanks,
Ralf

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

More issues:

- the part of ltmain starting with
# Collect and forward deplibs of preopened libtool libs

will source .la files but looks like it mistreats = in $dependency_libs

- is it intended that the = remain in the .la files after these are
moved to their final location on the host system?  Or should
--mode=finish remove them?

- should we provide a minimal patch for vendors 2.2.10 (or earlier
versions, maybe even 1.5.x) that makes libtool not barf upon = in .la
files, for smoother upgrades (given that 2.2.12 could contain other
issues not making for a smooth upgrade path)?

Thanks,
Ralf

fix pic_flag test (was: [RFT PATCH v4 0/8] Sysroot series)

[Ralf Wildenhues]

* Charles Wilson wrote on Mon, Aug 02, 2010 at 05:23:28AM CEST:
> The "unexpected" failure was
> 112: override pic_flag at configure time  FAILED (pic_flag.at:48)
> which isn't a regression on cygwin.

I'm pushing this patch to fix two issues with the test case.
Really should've known better than to use grep -e ...

Thanks for the report,
Ralf

Fix pic_flag test unportabilities.

* tests/pic_flag.at (override pic_flag at configure time): Skip
test if the compiler produces a warning containing `fpic'.
Do not use nonportable `grep -e', for Solaris.
Report by Charles Wilson.

diff --git a/tests/pic_flag.at b/tests/pic_flag.at
index a729d16..e62e1b7 100644
--- a/tests/pic_flag.at
+++ b/tests/pic_flag.at
@@ -34,7 +34,9 @@ int func(void) { return data; }
 cp foo.c foo.cpp
 C_pic_flag='-fpic -DPIC'
 AT_CHECK([$CC $CPPFLAGS $CFLAGS $C_pic_flag -c foo.c || exit 77],
-[], [ignore], [ignore])
+[], [stdout], [stderr])
+# The configure test for the PIC flag also checks for warnings.
+AT_CHECK([grep fpic stdout stderr && exit 77], [1])
 
 CXX_pic_flag='-fpic -DPIC'
 if $CXX $CPPFLAGS $CXXFLAGS $CXX_pic_flag -c foo.cpp; then :; else
@@ -46,6 +48,6 @@ AT_CHECK(["$abs_top_srcdir"/configure 
lt_cv_prog_compiler_pic="$C_pic_flag" ]dnl
 : ${MAKE=make}
 AT_CHECK([$MAKE], [], [stdout], [ignore])
 AT_CHECK([if ./libtool --features | grep 'enable shared libraries'; then ]dnl
-[  grep -e -fpic stdout; else exit 77; fi], [], [ignore], [ignore])
+[  grep ' -fpic' stdout; else exit 77; fi], [], [ignore], [ignore])
 
 AT_CLEANUP

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

* Paolo Bonzini wrote on Mon, Aug 02, 2010 at 10:51:30PM CEST:
> On Mon, Aug 2, 2010 at 22:13, Ralf Wildenhues wrote:
> 
> > - is it intended that the = remain in the .la files after these are
> > moved to their final location on the host system?  Or should
> > --mode=finish remove them?
> 
> I thought so, but --mode=finish takes a directory. :/
> 
> Should I do that on all .la files?

Isn't that what you actually need though?

Let's turn the question around: if some of the installed .la files have
been fixed already, won't the packages installed afterwards then expose
libtool bugs again, because they don't get handled by your patch series?

Thanks,
Ralf

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

* Charles Wilson wrote on Tue, Aug 03, 2010 at 07:30:28AM CEST:
> On 8/2/2010 4:51 PM, Paolo Bonzini wrote:
> > On Mon, Aug 2, 2010 at 22:13, Ralf Wildenhues wrote:
> >> - is it intended that the = remain in the .la files after these are
> >> moved to their final location on the host system?  Or should
> >> --mode=finish remove them?
> > 
> > I thought so, but --mode=finish takes a directory. :/
> > 
> > Should I do that on all .la files?
> 
> Wait, I thought you NEEDED the '=' marker in there, or the .la files
> wouldn't give correct behavior when they were used from within a sysroot.

Yes, but isn't --finish supposed to be run only once these files are not
within a sysroot any more?

> Sure, you might want to strip out the '=' flags if you copied/installed
> the built package over onto $host and wanted to do "native" development
> over there, but...

Exactly.  For some use cases it is "normal" to have this native
development later.  (Example: most distribution packagers.)

> it seemed cleaner to me to simply require an updated
> libtool for clients that want to link against libs built, from a cross
> $build, using the new libtool.  And if you want to "clean up" the "="
> flags when you deploy on $host -- it seems to me that that is a
> packaging/integration task (e.g. not libtool's problem).

That's exactly what I'm trying to find out.  If it's a packager task, it
needs to be documented as such, and if --finish is not the right place
to do it, then we should invent another tool to easily to it, because we
can't expect people to get those sed scripts right themselves.

> BTW, does libltdl need to know about these '=' markers, when it tries to
> load a module?

Good point, yes.

Thanks,
Ralf

Re: [RFT PATCH v4 6/8] emit sysrooted paths when installing .la files

[Ralf Wildenhues]

* Paolo Bonzini wrote on Tue, Aug 03, 2010 at 09:52:54AM CEST:
> On 08/01/2010 08:31 PM, Ralf Wildenhues wrote:
> >Although it is fairly unlikely, I prefer not relying on :+ support, so
> >please replace with 'if test -z "$lt_sysroot"...'.  Two instances.
> 
> Is this still true in the light of the recent discussion on autoconf
> mailing lists?

No, I guess that's fine then.

Thanks,
Ralf

Re: [RFT PATCH v3 3/9] add --with-sysroot

[Ralf Wildenhues]

* Paolo Bonzini wrote on Tue, Aug 03, 2010 at 10:04:08AM CEST:
> On 08/01/2010 12:48 PM, Ralf Wildenhues wrote:
> 
[ other packages that already use --with-sysroot ]

> >I'm not sure how to address these (not even sure
> >they use Libtool) except for a big sign in NEWS, and documentation in
> >the manual.
> 
> I can think of two ways:
> 
> 1) ignore --with-sysroot if not cross-compiling.  This however has a
> problem: if we test $cross_compiling = yes, sysroot tests will fail
> under Wine.

Yes, both that, and: I thought this patch series was meant to be usable
also for native compilation?

Distro packages much like to do things like that.

> 2) support both --with-sysroot and --with-host-sysroot, with the
> latter overriding the first.  Make GCC's toplevel always pass
> --without-host-sysroot to build modules, always pass
> --without-host-sysroot unless it was specified for host modules
> (this serves Canadian crosses), and skip --with-host-sysroot for
> target modules.  This is a hack, but one that can work reliably.

At this point you have me lost, simply because I can't claim to
understand all the details here.  So I can't give good advice.
My best bet would be to either trust you, or require some way to
set things up with GCC to try them out.  Doesn't have to be a
testsuite addition, just some recipe that works.


Also, I just noticed that recent GCC can just be passed --sysroot $D
and it will print $D upon --print-sysroot, so maybe if this is supported
it can be used for wider test exposure?  If you need GCC to support the
sysroot, that is.  And maybe symlink-tree will come in handy ... ?

Thanks,
Ralf

Re: [PATCH] Add func_append_quoted and do inline func_append substitutions.

[Ralf Wildenhues]

* Peter Rosin wrote on Thu, Jul 01, 2010 at 07:38:45PM CEST:
> Den 2010-06-28 01:24 skrev Gary V. Vaughan:
> >@@ -704,15 +710,14 @@ func_mode_compile ()
> >   save_ifs="$IFS"; IFS=','
> >   for arg in $args; do
> > IFS="$save_ifs"
> >-func_quote_for_eval "$arg"
> >-lastarg="$lastarg $func_quote_for_eval_result"
> >+func_append lastarg " $arg"
> >   done
> >   IFS="$save_ifs"
> >   func_stripname ' ' '' "$lastarg"
> 
> Oh, and this look suspicious...
> 
> s/func_append/func_append_quoted/ ?

A change like you suggested was apparently done in v2.2.10-49-gc13532a,
but it is not right.  The quoting may not extend to the added space.

This causes the compile failure reported in
.

I'm fixing the issue as follows.  I'm seeing lots more testsuite
failures in the quoting section part with AIX and FreeBSD shells
though ...

Cheers,
Ralf

Fix build failure with AIX sh due to shell quoting error.

* libltdl/config/ltmain.m4sh (func_append_quoted): Document
that this function inserts a separator space.
(func_mode_compile): Do not pass extra space here.
Fixes regression introduced in v2.2.10-49-gc13532a.
Report by Rainer Tammer.

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 897a5e8..193ff1a 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -157,7 +157,8 @@ func_append ()
 } # func_append may be replaced by extended shell implementation
 
 # func_append_quoted var value
-# Quote VALUE and append to the end of shell variable VAR.
+# Quote VALUE and append to the end of shell variable VAR, separated
+# by a space.
 func_append_quoted ()
 {
 func_quote_for_eval "${2}"
@@ -710,7 +711,7 @@ func_mode_compile ()
  save_ifs="$IFS"; IFS=','
  for arg in $args; do
IFS="$save_ifs"
-   func_append_quoted lastarg " $arg"
+   func_append_quoted lastarg "$arg"
  done
  IFS="$save_ifs"
  func_stripname ' ' '' "$lastarg"

Fix testsuite errors due to shell quoted parameter expansion issue.

[Ralf Wildenhues]

Interesting shell unportability:

$ bash -c 'f=" val" e=; echo "$e"$f'
val
$ ksh -c 'f=" val" e=; echo "$e"$f'
 val

ksh93, dash, zsh all do it like ksh.  Is that a bug in bash?

Anyway, the patch below seems to fix it, but I may want to fix the log
entry to pinpoing the culprit correctly.

Thanks,
Ralf

Fix testsuite errors due to shell quoted parameter expansion issue.

* tests/getopt-m4sh.at (_LT_AT_GETOPT_M4SH_SETUP): Insert space
between double-quoted and unquoted shell parameter, as ksh may
add one in its output anyway if the expansion of the second one
starts with a space.
(short option splitting, enhanced shell short option splitting)
(long option splitting, XSI long option splitting): Add space in
expected output.
Fixes testsuite failures on AIX, FreeBSD, etc.

diff --git a/tests/getopt-m4sh.at b/tests/getopt-m4sh.at
index ca5d5b8..768d595 100644
--- a/tests/getopt-m4sh.at
+++ b/tests/getopt-m4sh.at
@@ -44,7 +44,7 @@ M4SH_GETOPTS(
   [i], [--install],[], [options="$options install"],
   [v], [--verbose],[], [options="$options verbose"],
   [!], [--ltdl],   [false],[options="$options ltdl=$optarg"],
-[echo "$list"$options])
+[echo "$list" $options])
 ]])
 m4_pattern_forbid([m4_include])
 m4_pattern_forbid([AS_INIT])
@@ -87,7 +87,7 @@ rm -f options && mv options.tmp options])
 AT_SETUP([short option splitting])
 
 AT_DATA(expout,
-[[force verbose install
+[[ force verbose install
 ]])
 
 _LT_AT_GETOPT_M4SH_SETUP
@@ -103,7 +103,7 @@ AT_SETUP([enhanced shell short option splitting])
 AT_CHECK([fgrep '# Extended-shell func_split_short_opt' 
$abs_top_builddir/libtool >/dev/null 2>&1 || (exit 77)])
 
 AT_DATA(expout,
-[[force verbose install
+[[ force verbose install
 ]])
 
 _LT_AT_GETOPT_M4SH_SETUP
@@ -121,7 +121,7 @@ AT_CLEANUP
 AT_SETUP([long option splitting])
 
 AT_DATA(expout,
-[[ltdl=long
+[[ ltdl=long
 ]])
 
 _LT_AT_GETOPT_M4SH_SETUP
@@ -137,7 +137,7 @@ AT_SETUP([XSI long option splitting])
 AT_CHECK([fgrep '# Extended-shell func_split_long_opt' 
$abs_top_builddir/libtool >/dev/null 2>&1 || (exit 77)])
 
 AT_DATA(expout,
-[[ltdl=long
+[[ ltdl=long
 ]])
 
 _LT_AT_GETOPT_M4SH_SETUP

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

Hi Charles,

* Charles Wilson wrote on Tue, Aug 03, 2010 at 07:22:46AM CEST:
> For instance, suppose I have a cross compiler for mingw whose sysroot is
> /usr/i686-pc-mingw32/sys-root.  Suppose I want to build the gtk2 stack,
> for win32.  Well, that means I need to build gettext, and libiconv, and
> zlib, and libpng, and a dozen other libraries before I can build glib
> and the core gtk2.  And, as I build each one, I want to install them --
> or their -devel components like headers and link libraries -- into my
> cross sysroot on $build, so I can continue on to the next item in the
> stack.  That's case (1); I'd build these with --prefix=/mingw, because I
> WANT them to end up in
>/usr/i686-pc-mingw32/sys-root/mingw
> 
> Now, since I've used --prefix=/mingw and NOT
> --prefix=/usr/i686-pc-mingw32/sys-root/mingw, I can "cheat" even on
> win32.  I can take the binary runtime components -- even the -devel
> components! -- and install them in
>C: (or D: or E:)
> and they'll end up under
>C:/mingw
>D:/mingw
> or whathaveyou.  Thanks to a quirk in window's path resolution, any
> unixish absolute path is interpreted as if it were a path from the drive
> root of the CWD.  So, if CWD is on C:, then /mingw/libexec is
> interpreted as C:/mingw/libexec.  Since ALL the unixish paths will start
> with /mingw, this will Do The Right Thing.

Sorry, but I don't think that is viable.  Say, C:/mingw is owned by the
administrator, but D:/mingw is domain of user A.  Starting your app on
D: as user B makes B susceptible to files which A owns.  In general, you
cannot leave away the drive letter when specifying the --prefix.

> If the elements had been
> compiled with --prefix=$sysroot/mingw, then I could not do this, because
> the embedded paths hardcoded into the binaries, .la files, and scripts
> would all say things like /usr/i686-pc-mingw32/sys-root/mingw/lib, which
> windows would transliterate into
> C:/usr/i686-pc-mingw32/sys-root/mingw/lib, when what I REALLY wanted all
> along was C:/mingw/lib.

Sure.  I don't disagree with leaving the sysroot part out of --prefix.

> However, items built for case (2) -- direct deployment on the $host (or
> compiled "natively" ON the mingw host, that is MSYS/MinGW) -- are by
> convention configured as:
>configure --prefix=`cd /mingw && pwd -W`
> which ends up as
>configure --prefix=C:/MinGW
> and the installation is usually preformed as
>make install prefix=/tmp/something/MinGW

I guess what I don't see is why the former case doesn't also use
  --prefix=C:/MinGW

[...]
> Anyway, this workflow ensures that the actual, DOS-ish paths are
> embedded anywhere such things are hardcoded, which is both good and bad.
>  But it also ensures that there IS no concatenation of paths that might
> start with X:, since we replace the ENTIRE prefix with a unixish one
> during make install.  This technique works, even today on cross setups,
> if you build one package at a time for deployment on $host.

Ahh.

> But you
> can't easily do a "chain" of such builds on a cross system, without
> effort.  You sorta have to do twice the builds: one of type (1) and one
> of type (2), for each library in the chain:
> 
>   a) zlib class (1) installed on $build in sysroot under $prefix
>   b) zlib class (2) installed on $host under $prefix
>   c) libpng class (1) installed on $build in sysroot under $prefix
>  this will link against the libz.dll.a from (a).  If you have
>  support on $build for running $host binaries (wine?) then at
>  runtime it would use the libz-1.dll from (a) as well.
>   d) libpng class (2) installed on $host under $prefix
>  this will link against libz.dll.a from (a)!!!  However, once
>  installed on $host, it will RUN against zlib-1.dll from (b).
>   and so on, and so on.
> 
> Using method (2) alone would not yet be appropriate for a case (1)
> installation (e.g. into a cross $build system's sysroot), because then
> you WOULD be concatenating a unixish sysroot with a dosish "prefix".
> (e.g. you can't really use (b) and install it on $build in sysroot, and
> pretend that's a suitable replacement for (a); ditto (d) vs. (c)).

Is this still relevant in light of my above reply?

> > If yes, then
> > very cool, and I'd very much like this to be exposed in the testsuite
> > (only on w32 systems, of course, and the C:/... path should be something
> > unlikely to clash with any actual user files, in case make install does
> > write there after all).
> 
> I'm not entirely sure what you want to test here -- or that it would be
> something that *libtool's* testsuite should cover (wouldn't it be more
> appropriate as part of automake's?)

Please allow me to give a sort-of simple-minded answer, hope I can make
the gist of it clear:

If Libtool gains the --with-sysroot feature, then that should be tested
as part of the Libtool testsuite.  Currently these tests all skip if the
compiler found is not GCC or has not been configured with a sysroot.
These two side

Re: Fix testsuite errors due to shell quoted parameter expansion issue.

[Ralf Wildenhues]

* Eric Blake wrote on Tue, Aug 03, 2010 at 10:55:36PM CEST:
> On 08/03/2010 02:32 PM, Ralf Wildenhues wrote:
> > Interesting shell unportability:
> > 
> > $ bash -c 'f=" val" e=; echo "$e"$f'
> > val
> > $ ksh -c 'f=" val" e=; echo "$e"$f'
> >  val
> > 
> > ksh93, dash, zsh all do it like ksh.  Is that a bug in bash?
> 
> Yes; [...]

thanks for the investigation.  I'm pushing the patch with modified
log entry.

Cheers,
Ralf

Fix testsuite errors due to shell quoted parameter expansion issue.

* tests/getopt-m4sh.at (_LT_AT_GETOPT_M4SH_SETUP): Insert space
between double-quoted and unquoted shell parameter, as bash
4.0.28 doesn't add one in its output if the expansion of the
second one starts with a space.
(short option splitting, enhanced shell short option splitting)
(long option splitting, XSI long option splitting): Add space in
expected output.
Fixes testsuite failures on AIX, FreeBSD, etc.
Report by Rainer Tammer.

Re: libtool-2.2.11a on AIX 5.3 / 5.3 current git master - tests/nomode.test

[Ralf Wildenhues]

* Rainer Tammer wrote on Wed, Aug 04, 2010 at 08:41:26AM CEST:
> FAIL: tests/nomode.test
> 
> This failure is due to the following error:
> 
> $ ./libtool
> ./libtool[1591]: shift: bad number
> 
> -> code
>   # save first non-option argument
>   nonopt="$opt"; shift
> 
> But there is nothing in $1, so the shift fails.

Thanks.  Fixing with the first patch below.  (The double-quotes around
what will be $# in the final shell script are merely there to please
sh.test.)

> # ./libtool
> libtool: error: you must specify a MODE.
> 
> The output of libtool-2.2.10 is:
> 
> r...@build53 rc:127 # libtool
> *** Warning: inferring the mode of operation is deprecated.
> *** Future versions of Libtool will require --mode=MODE be specified.
> libtool: warning: cannot infer operation mode without MODE-ARGS
> libtool: you must specify a MODE
> Try `libtool --help' for more information.

Thanks.  I'm re-enabling the pointer to --help with the second patch
below.

Cheers,
Ralf

Avoid syntax error due to shift of nonexistent parameter.

* libltdl/config/ltmain.m4sh : Only shift
if there is a positional parameter to shift.  Fixes `libtool
--help' when dash is used.
Report by Rainer Tammer.

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 193ff1a..98c0a27 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -387,7 +387,10 @@ M4SH_GETOPTS(
func_enable_tag "$optarg"],
 [
   # save first non-option argument
-  nonopt="$opt"; shift
+  if test "$[]#" -gt 0; then
+nonopt="$opt"
+shift
+  fi
 
   # preserve --debug
   $opt_debug && func_append preserve_args " --debug"



Let `libtool' without arguments point to `--help' again.

* libltdl/config/ltmain.m4sh (func_check_version_match):
Remove duplicate and wrong error check.
* tests/help.at (standard command line options): Extend test.
Report by Rainer Tammer.

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 98c0a27..32a41c7 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -413,8 +413,6 @@ M4SH_GETOPTS(
   func_fatal_configuration "not configured to build any kind of library"
 fi
 
-test -z "$opt_mode" && func_fatal_error "error: you must specify a MODE."
-
 # Darwin sucks
 eval std_shrext=\"$shrext_cmds\"
 
diff --git a/tests/help.at b/tests/help.at
index 3460a2b..e1bcbf5 100644
--- a/tests/help.at
+++ b/tests/help.at
@@ -1,6 +1,6 @@
 # help.at -- standard command line options  -*- Autotest -*-
 #
-#   Copyright (C) 2009 Free Software Foundation, Inc.
+#   Copyright (C) 2009, 2010 Free Software Foundation, Inc.
 #
 #   This file is part of GNU Libtool.
 #
@@ -35,6 +35,10 @@ AT_CHECK([$LIBTOOL --help-all], [], [ignore])
 AT_CHECK([$LIBTOOL --version], [], [stdout])
 AT_CHECK([grep 'Copyright.*Free Software Foundation' stdout], [], [ignore])
 
+AT_CHECK([$LIBTOOL], [1], [ignore], [stderr])
+AT_CHECK([grep 'specify a MODE' stderr], [], [ignore])
+AT_CHECK([grep ' --help' stderr], [], [ignore])
+
 AT_CLEANUP
 
 

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

Hi Charles,

thanks for the elaborate explanations.

* Charles Wilson wrote on Thu, Aug 05, 2010 at 08:10:10AM CEST:
> On 8/4/2010 2:15 PM, Ralf Wildenhues wrote:
> > * Charles Wilson wrote on Tue, Aug 03, 2010 at 07:22:46AM CEST:
[...]
> >> Thanks to a quirk in window's path resolution, any
> >> unixish absolute path is interpreted as if it were a path from the drive
> >> root of the CWD.  So, if CWD is on C:, then /mingw/libexec is
> >> interpreted as C:/mingw/libexec.  Since ALL the unixish paths will start
> >> with /mingw, this will Do The Right Thing.
> > 
> > Sorry, but I don't think that is viable.  Say, C:/mingw is owned by the
> > administrator, but D:/mingw is domain of user A.  Starting your app on
> > D: as user B makes B susceptible to files which A owns.  In general, you
> > cannot leave away the drive letter when specifying the --prefix.
> 
> Then you are stuck with building twice.  Once for your sysroot
> installation, and once for the "real" installation on $host.
> However...that would STILL break:
> 
> libfoo.la
> a)  compiled for sysroot using the cross compiler, and installed there,
> with --prefix=/something and --with-sysroot
> b)  compiled for $host using the cross compiler, and installed THERE,
> with --prefix=E:/mingw or whatever.
> 
> Then, you compile libbar.la which depends on libfoo:
> a)  compiled for sysroot using the cross compiler, and installed there,
> with --prefix=/something and --with-sysroot.  libbar.la(a)'s
> dependency_libs will look like
> -L=/something =/something/lib/libfoo.la
> This is obviously useful for future compilation of libbaz.la.
> 
> b)  compiled for $host using the cross compiler, and eventually
> installed there, with --prefix=E:/mingw or whatever.  However...
> libbar.la(b)'s dependency_libs will look like
> -L=/something =/something/lib/libfoo.la
> too!  But that's clearly wrong, if you want to copy libbar.la(b)
> directly over to $host and use it there, under E:/mingw.
> 
> Now, this is cross-compiler 101, for all architectures.  You really need
> to use the same "prefix" underneath your sysroot that you use on the
> actual $host.  Unfortunately, there is no such thing, on unix, as a
> prefix named "E:/somedir" (note the missing initial '/').
> 
> 
> But, that is untenable: on the one hand you want to assert that "thou
> shalt include X: in thy prefixes when configuring for $host=mingw" even
> when cross-compiling for any purpose,

No; I don't want to assert this.  Users may want to assert this, and I
don't want to libtool stand in their way if that is possible.  If some
user has only one drive, or is otherwise fine with not specifying a
drive prefix, I'm totally fine with that.

> but then there's this impossible
> requirement that the "prefix" underneath the sysroot be identical to the
> "prefix" on $host -- otherwise this whole cross compile thing falls
> apart, once you start chaining dependencies.
> 
> Now, if "/something" in the (a) cases above were "/mingw" (e.g.
> "matched" the drive-letter-stripped version from the (b) cases above),
> then it would actually work correctly -- but, you'd be open to exploits
> from D:/mingw.

> And this problem is not limited to libtool's .la files; if any path
> containing $prefix is compiled into a binary, or recorded anywhere,
> you'll have this problem.
> 
> The only real solution, as I've said, is:
> 
>   1) don't cross compile for $host=mingw. Ever. Always compile
>  natively, and use --prefix=X:/stuff WITH the drive letter.

We are at that position already, and would like to improve from there.

>   2) Fix *every* package that records ANY directory information
>  so that it is completely relocatable. Each binary or script, or
>  tool that parses a text file containing directory information,
>  should autodetect its installation location, and deduce relative
>  paths to its resources from that.

Relocatability is one possibility, and one that I think we should
expore eventually, because it is a conceptually good idea.

> #2 is a gigantic job, and it's not libtool's task to do that for the
> universe of software packages. Now, MAYBE, we might take a look at
> relocation support for .la files -- but I fear that would open us up to
> more security holes than you could shake a stick at.  Resolving all
> paths into relative paths from whatever is recorded in libdir=''? Oh, boy...

Why would it be clear that unreliable automatisms need to come into play
here?  Please, let's no

Re: Next Libtool Point Release Pending

[Ralf Wildenhues]

Hello Gary,

* Gary V. Vaughan wrote on Fri, Aug 06, 2010 at 06:01:37AM CEST:
> I promised to roll a 2.2.12 release this month.  But looking at the
> huge progress we've made so far with Windows since 2.2.10, I'm
> wondering if we would be better to roll 2.2.12 sooner rather than
> later?

I am still looking at several regressions in git over 2.2.10, so no,
a release right now (as opposed to in a couple of weeks, hopefully)
would make me rather unhappy.

Also, I would prefer a release with this patch series in, at least if
the series is in mergeable shape in the near future.

> Slightly related, I wonder whether all the progress on Windows
> justifies calling the next release 2.4?

A higher number could help notify people that more new bugs have crept
in, certainly.  ;-)  The w32 support requires Automake support to be
really usable though, and we're still working on that.  I had kinda
hoped that there could at least an Automake beta that carries that work.

OTOH, since I hope to have more larger changes in the future, I'm not
sure we really want another major number bump already.

Cheers,
Ralf

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

* Charles Wilson wrote on Fri, Aug 06, 2010 at 03:26:30AM CEST:
> But a STEP in that direction is to reduce the current pain experienced
> by cross compiles for $host=mingw even with --prefix=/unixish; pain
> caused by the current lack of sysroot support in libtool (and some other
> utilities).
> 
> But...mingw is not the only $host in the world; the pain in (c) is
> experienced right now by *all* cross users of libtool.  Other $hosts
> don't care about mingw's issues with X:/foo paths.  The only situations
> that matter to them are (b) and (c), and libtool's current lack of
> sysroot support makes (c) very painful.
> 
> Let's fix that, THEN worry about the screwball mingw platform's
> decade-festering issue with multiroot file systems.

OK.

> >> The only real solution, as I've said, is:
> >>
> >>   1) don't cross compile for $host=mingw. Ever. Always compile
> >>  natively, and use --prefix=X:/stuff WITH the drive letter.
> > 
> > We are at that position already, and would like to improve from there.
> 
> Well, we're a bit past THAT.  You can DO cross compiles with
> --prefix=/foo, even without sysroot support.  It's ugly, and you have to
> post-process the .la files and jump thru other hoops, but it can be done.

OK.

> With sysroot support in the (cross) compiler, AND sysroot support in
> libtool, it becomes possible to do it without jumping thru as many hoops.

Good.

> Honestly, this whole issue with DESTDIR, and X:/foo paths, is a
> *separate topic* and really doesn't belong in THIS discussion at all.

Fine with me.

> The only reason it came up is because *I'm* the one testing Paolo's
> patches, and *I* have a fistful of mingw-target cross compilers.  If I'd
> tested only with sun-, hpux-, and irix- cross compilers, none of this
> would ever have come up.

And it's great you're doing all the testing.  But honestly, unless you
keep doing that testing before every new release, things are going to
break in the future.  Which is why I am harping so much on tests that
run as automatically as possible.

> > Relocatability is one possibility, and one that I think we should
> > expore eventually, because it is a conceptually good idea.
> 
> Well, there is a set of tools for it in gnulib, but it requires EVERY
> library in your system to adopt it, really.  Plus the program component
> is GPL, which limits acceptance -- especially if you want it to become
> universal.

Well, yes, let's not further discuss this topic now.  The system in
gnulib is not the end of the story, and the technical issues can be
addressed in a different way as well.

> The discussion of semantics, when you start talking about how and
> whether DESTDIR is supported, is a distraction from the sysroot support.
> I'd rather drop all discussion of mingw since sysroot is useful and
> needed for cross compilers that target other $hosts.

OK.

> > So I really hope that my comments don't discourage you from working on
> > this.  You guys have done a great job so far, and I'm really trying to
> > not delay review; it would be sad to see this not fly just because we
> > talk past each other about some related questions.
> 
> I'm encouraged by the review. I'm discouraged by the rabbit trails
> eating up scarce time and resources (and I consider tilting at the
> longstanding DESTDIR+win32 windmill a rabbit trail).  It is what it is.
>  If it is to be fixed, it's not part of *this* patch, and shouldn't
> complicate consideration of *this* change.

OK.

> > What if we special-cased drive letters in the way that
> >   DESTDIR=C:/foo/bar prefix=D:/baz/zork
> > 
> > gets mapped to
> >   C:/foo/bar/D/baz/zork
> > 
> 
> Well, I can easily do that as follows:
>   make install prefix=/D/baz/zork DESTDIR=C:/foo/bar
> 
> but what does that BUY me?
[... snip good explanation ...]

> Why are we considering this again?  And if we must, can we put it off to
> another thread, and keep our focus on Paolo's actual patch for sysroot
> support, and not hypothetical fixes for DESTDIR+mingw?

OK.

> >> $ gcc --sysroot=/bob -print-sysroot
> >> /bob
> >>
> >> So, you could easily create a test that uses the native system compiler
> >> to "fake" a cross-toolchain "sysroot" test.
> > 
> > Exactly.  That's what I meant.
> ...
> > These parts are what I don't know, because I have no experience in this
> > area.  Is creating such a link farm feasible?  Presumably, some subtrees
> > could just be created with one symlink to a directory?  Presumably the
> > symlink-tree script from Automake/GCC could help?
> 
> Dunno. It's possible that all you really need from lib are elements in
> that directory alone, and no subs.  For include, though, who knows how
> ugly the #include chain could be, with sys/ and bits/ and sys/bits/ and
> sys/bits/$arch and all.  (Oh, and multilib: what about lib64?)

libtool is not known to install files itself below $includedir, so for
include, it would seem sufficient to simply 'ln -s' it when $build has
real symlinks, and skip the test if $build is

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

* Charles Wilson wrote on Fri, Aug 06, 2010 at 02:47:59PM CEST:
> On 8/6/2010 1:19 AM, Ralf Wildenhues wrote:
> > Wrt. lib and lib32, lib64, can we find out all files GCC needs by asking
> > it several -print-* questions?  Plus maybe optimistically searching for
> > libc and ld*.so?
> 
> Well, if the test is skipped for $build=w32, maybe we can rely on ldd?
> That is, use the system compiler to build a hello world all, use ldd to
> figure out what libs it is linked to, and where they come from?

Sounds like a good idea, and not a big limitation.

Note that there are non-binutils ldd tools out there (Solaris, IRIX,
Tru64) where output differs at least in the amount of whitespace and
possibly additional empty lines; and AIX ldd may print things like:

$ ldd /bin/ls
/bin/ls needs:
 /usr/lib/libc.a(shr.o)
 /unix
 /usr/lib/libcrypt.a(shr.o)

and BSD ldd prepends "$prog:\n" etc.; in case of doubt looking at
gnulib/m4/ldd.m4 (or just ignoring all tools that don't look like GNU;
or just using the gnulib ldd.m4; however you like) helps.

Thanks,
Ralf

Re: Next Libtool Point Release Pending

[Ralf Wildenhues]

Hello,

* Gary V. Vaughan wrote on Fri, Aug 06, 2010 at 08:53:15PM CEST:
> Another viable compromise might be to call the next release
> 2.3.0?

Maybe it's early enough to finalize a decision on this when we
know a bit better which patches are in, and which features can
be advertised.

There is also our numbering scheme description on
.

Gary, any way BTW I can get you to look at

that would be lovely.

Thanks,
Ralf

Fix ltdl-libdir test for C++ compilers.

[Ralf Wildenhues]

Pushed as obvious to let 'configure CC=g++' pass the testsuite again.

Cheers,
Ralf

Fix ltdl-libdir test for C++ compilers.

* tests/ltdl-libdir.at (libdir of installed modules): Declare
module function as extern "C".

diff --git a/tests/ltdl-libdir.at b/tests/ltdl-libdir.at
index 432d18e..f5dc33c 100644
--- a/tests/ltdl-libdir.at
+++ b/tests/ltdl-libdir.at
@@ -38,7 +38,9 @@ bindir=$prefix/bin
 mkdir $prefix $libdir $bindir
 
 AT_DATA([a.c],
-[[
+[[#ifdef __cplusplus
+extern "C"
+#endif
 int f (void)
 {
   return 42;

Fix AC_NO_EXECUTABLES test failure on AIX. (was: libtool-2.2.8 on AIX 6.1)

[Ralf Wildenhues]

> On 02.08.2010 20:40, Ralf Wildenhues wrote:
> > * Rainer Tammer wrote on Mon, Aug 02, 2010 at 05:40:13PM CEST:
> >> I just have tested libtool 2.2.8 on AIX 6.1.

> >> 95: AC_NO_EXECUTABLES   FAILED
> >> (no-executables.at:76)
> > This is new to me, and an actual (minor) bug in libtool.m4, which you
> > can ignore unless you're hacking on GCC.  I think it's the
> > _LT_SYS_MODULE_PATH_AIX macro that contains a link test which currently
> > isn't skippable by setting a cache variable.

This failure should be fixed by the patch below.

The no-executables.at test group nicely shows which cache variables
need to be set inside the configury of GCC when GCC_NO_EXECUTABLES is in
use; unfortunately, I don't know of an easy way for GCC to determine how
to set them reliably when the linker cannot be used.  While the
dlopen-related ones may be implied fairly reliably from $host, the rest
is simply unclear to me.  See e.g. this PR for an instance of the
problem: <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174#c13>

Thanks,
Ralf

Fix AC_NO_EXECUTABLES test failure on AIX.

* libltdl/m4/libtool.m4 (_LT_SYS_MODULE_PATH_AIX): Wrap link
test in AC_CACHE_VAL, using cache variable $lt_cv_aix_libpath.
* tests/no-executables.at (AC_NO_EXECUTABLES): Preset it, to
avoid link test.
Bug report by Rainer Tammer.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 39873be..62c437d 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1081,7 +1081,8 @@ m4_defun([_LT_DARWIN_LINKER_FEATURES],
 # to the aix ld manual.
 m4_defun([_LT_SYS_MODULE_PATH_AIX],
 [m4_require([_LT_DECL_SED])dnl
-AC_LINK_IFELSE(AC_LANG_PROGRAM,[
+AC_CACHE_VAL([lt_cv_aix_libpath],
+[AC_LINK_IFELSE(AC_LANG_PROGRAM,[
 lt_aix_libpath_sed='
 /Import File Strings/,/^$/ {
/^0/ {
@@ -1089,12 +1090,14 @@ lt_aix_libpath_sed='
p
}
 }'
-aix_libpath=`dump -H conftest$ac_exeext 2>/dev/null | $SED -n -e 
"$lt_aix_libpath_sed"`
+lt_cv_aix_libpath=`dump -H conftest$ac_exeext 2>/dev/null | $SED -n -e 
"$lt_aix_libpath_sed"`
 # Check for a 64-bit object if we didn't find anything.
-if test -z "$aix_libpath"; then
-  aix_libpath=`dump -HX64 conftest$ac_exeext 2>/dev/null | $SED -n -e 
"$lt_aix_libpath_sed"`
+if test -z "$lt_cv_aix_libpath"; then
+  lt_cv_aix_libpath=`dump -HX64 conftest$ac_exeext 2>/dev/null | $SED -n -e 
"$lt_aix_libpath_sed"`
 fi],[])
-if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
+if test -z "$lt_cv_aix_libpath"; then lt_cv_aix_libpath="/usr/lib:/lib"; fi
+])
+aix_libpath=$lt_cv_aix_libpath
 ])# _LT_SYS_MODULE_PATH_AIX
 
 
diff --git a/tests/no-executables.at b/tests/no-executables.at
index e9e229a..75b92ef 100644
--- a/tests/no-executables.at
+++ b/tests/no-executables.at
@@ -1,7 +1,6 @@
 # no-executables.at -- Libtool usage in GCC-*- Autotest -*-
 
-#   Copyright (C) 2008 Free Software Foundation, Inc.
-#   Written by Ralf Wildenhues, 2008
+#   Copyright (C) 2008, 2010 Free Software Foundation, Inc.
 #
 #   This file is part of GNU Libtool.
 #
@@ -52,6 +51,7 @@ lt_cv_archive_cmds_need_lc=no
 lt_cv_cc_needs_belf=no
 lt_cv_ld_exported_symbols_list=no
 lt_cv_prog_compiler_static_works=no
+lt_cv_aix_libpath="/usr/lib:/lib"
 
 # Deal with AC_LIBTOOL_DLOPEN in one of two possible ways:
 # - do not execute it at all in the ac_no_link case

versioning test on AIX (was: libtool-2.2.8 on AIX 6.1)

[Ralf Wildenhues]

* Rainer Tammer wrote on Tue, Aug 03, 2010 at 09:40:23AM CEST:
> On 02.08.2010 20:40, Ralf Wildenhues wrote:
> > * Rainer Tammer wrote on Mon, Aug 02, 2010 at 05:40:13PM CEST:
> >> 56: versioning  FAILED
> >> (versioning.at:169)
> > This testsuite bug should (hopefully) be fixed in 2.2.10.  Testsuite
> > bugs are no need to worry.
> >
> Unfortunately no.

> ## -- ##
> ## libtool 2.2.10 test suite. ##
> ## -- ##

>  56: versioning  FAILED
> (versioning.at:172)

This particular test failure is a real failure but not a regression;
it is new because the tests is new.  Quoting the relevant bits from the
testsuite.log:

| ./versioning.at:237: $LIBTOOL --mode=clean rm -f liba.la
| stderr:
| stdout:
| libtool: clean: rm -f liba.la .libs/liba.a .libs/liba.a .libs/liba.so.2 
.libs/liba.la .libs/liba.lai
| libtool: clean: rmdir .libs >/dev/null 2>&1
| ./versioning.at:172: if "$lt_exe" ; then :; else lt_status=$?; 
test "X$host" != "X$build" && test -x "$lt_exe" && exit 77; exit 
$lt_status; 
| --- /dev/null   2010-08-03 08:56:09.0 +0200
| +++ /daten/source/libtool-2.2.10/tests/testsuite.dir/at-groups/56/stderr  
  2010-08-03 08:56:09.0 +0200
| @@ -0,0 +1,3 @@
| +Could not load program 
/daten/source/libtool-2.2.10/tests/testsuite.dir/056/inst/bin/prog1:
| +   Dependent module 
/daten/source/libtool-2.2.10/tests/testsuite.dir/056/inst/lib/liba.a(liba.so.0) 
could not be loaded.
| +   Member liba.so.0 is not found in archive 
| ./versioning.at:172: exit code was 255, expected 0
| 56. versioning.at:24: 56. versioning (versioning.at:24): FAILED 
(versioning.at:172)

Oh well, hacking libtool wouldn't be half the fun without AIX. :-/

The test tries to ensure that with an incompatible library upgrade,
programs previously linked against the old library still work.  This
usually works on systems where different major versions of a library
have different file names.  Which isn't the case for AIX without
runtimelinking (liba.a is the same name whether it contains liba.so.2
or liba.so.0):

$ ls inst/lib
liba.a   liba.la  libb.a   libb.la

$ ar t inst/lib/liba.a
liba.so.2

Now, the part that really surprised me was that this doesn't even work
with runtimelinking (configure LDFLAGS=-Wl,-brtl), even though the file
names aren't the issue here:

$ ls -l inst/lib | sed 's/.*[0-9] \(lib.*\)/\1/'
total 45
liba.a
liba.la
liba.so -> liba.so.2.0.0
liba.so.0 -> liba.so.0.1.0
liba.so.0.0.1
liba.so.0.1.0
liba.so.2 -> liba.so.2.0.0
liba.so.2.0.0
libb.a
libb.la
libb.so -> libb.so.0.0.0
libb.so.0 -> libb.so.0.0.0
libb.so.0.0.0

The failure looks like this:
$ ./prog1
exec(): 0509-036 Cannot load program ./prog1 because of the following errors:
rtld: 0712-001 Symbol a was referenced
  from module prog1(), but a runtime definition
  of the symbol was not found.

The apparent reason for the failure is that it's not the versioned name
that is encoded:

$ dump -H inst/bin/prog1
[...]
***Import File Strings***
INDEX  PATH  BASEMEMBER  
0  /tmp/build/tests/testsuite.dir/064/inst/lib:/usr/vac/lib:/usr/lib:/lib   
  
1liba.so 
2libc.a  shr.o   
3librtl.ashr.o   


(For reference here's also the respective output for non-rtl:

$ dump -H inst/bin/prog1
[...]
***Import File Strings***
INDEX  PATH  BASEMEMBER  
0  /tmp/build/tests/testsuite.dir/064/inst/lib:/usr/vac/lib:/usr/lib:/lib   
  
1libc.a  shr.o   
2liba.a  liba.so.0   

)


So, while I'm not completely sure yet that there isn't another bug
lurking in libtool here, it seems that this is another AIX limitation.

One way out may be to use loader domains; see here for a description:
<http://stromberg.dnsalias.org/~strombrg/AIX-shared-libs.html>

I don't really see how to apply this concept in general, i.e., without
user intervention.  So, for now I propose the patch below to skip this
part of the part; I will leave time for comments before pushing it.

Cheers,
Ralf

Skip part of versioning test on AIX.

* tests/versioning.at (versioning): The AIX linker always
records the unversioned library name, even with runtimelinking,
so skip the execution test for the incompatibly upgraded
  

revert unwanted enabling of libtool tracing (was: libtool-2.2.11a on AIX 5.3 current git master / followup on the old test suite and failures in the new testsuit)

[Ralf Wildenhues]

Rainer, I'm going through things in some random order, and it will take
me at least a little while to get through them all.

* Rainer Tammer wrote on Thu, Aug 05, 2010 at 09:25:14AM CEST:
> 38. link-order2.at:46: testing Link order of deplibs ...
> libtool: compile:  cc_r -qlanglvl=extc89 -g -c a0.c  -DPIC -o .libs/a0.o
> libtool: compile:  cc_r -qlanglvl=extc89 -g -c a1.c  -DPIC -o .libs/a1.o
> libtool: compile:  cc_r -qlanglvl=extc89 -g -c b.c  -DPIC -o .libs/b.o
> libtool: link: /usr/bin/nm -B -BCpg  .libs/a0.o   | awk '{ if ((($ 2 == "T") 
> || ($ 2 == "D") || ($ 2 == "B")) && (substr($ 3,1,1) != ".")) { print $ 3 } 
> }' | sort -u > .libs/liba0.exp
> libtool: link: cc_r -qlanglvl=extc89 -Wl,-bM:SRE -o .libs/liba0.so.0  
> .libs/a0.o   -L/daten/source/libtool-2.2.11a/tests/testsuite.dir/038/lib -lc 
> -Wl,-bnoentry  -qlanglvl=extc89   -Wl,-bE:.libs/li
> libtool: link: ar cru .libs/liba0.a .libs/liba0.so.0
> libtool: link: ( cd ".libs" && rm -f "liba0.la" && ln -s "../liba0.la" 
> "liba0.la" )
> libtool: install: cp .libs/liba0.a 
> /daten/source/libtool-2.2.11a/tests/testsuite.dir/038/lib/liba0.a
> libtool: install: cp .libs/liba0.lai 
> /daten/source/libtool-2.2.11a/tests/testsuite.dir/038/lib/liba0.la
> libtool: enabling shell trace mode
> + test 2 -gt 0
> + opt=--finish
> + shift
> + opt_finish=:
> + set dummy --mode finish 
> /daten/source/libtool-2.2.11a/tests/testsuite.dir/038/lib

Waitaminute.  Why is libtool enabling trace mode here?  That wasn't
requested anywhere; and it leads to huge log files.

*time passes*

git bisect converges at v2.2.10-34-gb8dd17a, the introduction of
getopt.m4sh.  I'm pushing the patch below to undo that.

Thanks,
Ralf

Ensure not to reverse preserving of --debug for relinking/finish.

* libltdl/config/ltmain.m4sh (func_check_version_match): Only
preserve '--debug' switch if $opt_debug is not equal to ':'.
* tests/help.at (debug tracing): New test group.
Report by Rainer Tammer.

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 32a41c7..fad2e64 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -393,7 +393,7 @@ M4SH_GETOPTS(
   fi
 
   # preserve --debug
-  $opt_debug && func_append preserve_args " --debug"
+  test "$opt_debug" = : || func_append preserve_args " --debug"
 
   case $host in
 *cygwin* | *mingw* | *pw32* | *cegcc*)
diff --git a/tests/help.at b/tests/help.at
index e1bcbf5..c4eaa87 100644
--- a/tests/help.at
+++ b/tests/help.at
@@ -92,3 +92,100 @@ AT_CHECK([$LIBTOOL cl liba.la],
 [], [ignore], [ignore])
 
 AT_CLEANUP
+
+
+AT_SETUP([debug tracing])
+
+AT_DATA([a.c],
+[[int a () { return 0; }
+]])
+
+AT_DATA([b.c],
+[[extern int a ();
+int b () { return a (); }
+]])
+
+AT_DATA([main.c],
+[[extern int b ();
+int main () { return b (); }
+]])
+
+inst=`pwd`/inst
+libdir=$inst/lib
+bindir=$inst/bin
+mkdir $inst $libdir $bindir
+
+# This test will not work correctly if --debug is passed.
+AT_CHECK([case "$LIBTOOL $CC $CPPFLAGS $CFLAGS $LDFLAGS " in ]dnl
+[  *\ --debug\ *) exit 77;; *) :;; esac])
+
+check_trace ()
+{
+  if test "X$trace" = X--debug; then
+AT_CHECK([grep 'enabling shell trace mode' stdout stderr], [0], [ignore])
+AT_CHECK([grep ' --mode' stderr], [0], [ignore])
+  else
+AT_CHECK([grep 'enabling shell trace mode' stdout stderr], [1])
+AT_CHECK([grep ' --mode' stderr], [1])
+  fi
+}
+
+orig_LIBTOOL=$LIBTOOL
+for trace in '' --debug; do
+  LIBTOOL="$orig_LIBTOOL $trace"
+
+  # Hypothesis: debug output should happen if (and only if) --debug is
+  # passed, for compile, link, install, uninstall, and clean modes.
+  AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c a.c],
+  [], [stdout], [stderr])
+  check_trace
+  AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c b.c],
+  [], [stdout], [stderr])
+  check_trace
+  AT_CHECK([$CC $CPPFLAGS $CFLAGS -c main.c], [], [ignore], [ignore])
+  AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba.la a.lo ]dnl
+  [ -no-undefined -rpath $libdir], [], [stdout], [stderr])
+  check_trace
+  AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o libb.la b.lo ]dnl
+  [ -no-undefined -rpath $libdir liba.la], [], [stdout], [stderr])
+  check_trace
+  AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main$EXEEXT 
main.$OBJEXT ]dnl
+  [libb.la], [], [stdout], [stderr])
+  check_trace
+  LT_AT_NOINST_EXEC_CHECK([./main], [], [], [stdout], [stderr])
+  check_trace
+
+  AT_CHECK([$LIBTOOL --mode=install cp liba.la libb.la $libdir],
+  [], [stdout], [stderr])
+  check_trace
+
+  # Hypothesis: --debug should be passed to relink mode if (and only if)
+  # it was passed at link mode.
+  AT_CHECK([$orig_LIBTOOL --mode=install cp liba.la libb.la $libdir],
+  [], [stdout], [stderr])
+  if grep ': relinking ' stdout stderr; then
+if test "X$trace" = X--debug; then
+  AT_CHECK([grep ' --mode=relink' stdout stderr | grep ' --debug '],
+ 

Do not call toplevel configure in non-VPATH build. (was: libtool-2.2.11a on AIX 5.3 current git master / followup on the old test suite and failures in the new testsuit)

[Ralf Wildenhues]

* Rainer Tammer wrote on Thu, Aug 05, 2010 at 09:25:14AM CEST:
> 112. pic_flag.at:24: testing override pic_flag at configure time ...
> ./pic_flag.at:36: $CC $CPPFLAGS $CFLAGS $C_pic_flag -c foo.c || exit 77
> stderr:
> stdout:
> ./pic_flag.at:39: grep fpic stdout stderr && exit 77
> ./pic_flag.at:46: "$abs_top_srcdir"/configure 
> lt_cv_prog_compiler_pic="$C_pic_flag"  
> lt_cv_prog_compiler_pic_CXX="$CXX_pic_flag"
> stderr:
> configure: error: source directory already configured; run "make distclean" 
> there first
> stdout:
> ## --- ##
> ## Configuring libtool" (Build:1.3224 2010-08-04)" 2.2.11a ##
> ## --- ##
> 
> checking for a BSD-compatible install... /opt/freeware/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /opt/freeware/bin/mkdir -p
> checking for gawk... no
> checking for mawk... no
> checking for nawk... nawk
> checking whether gmake sets $(MAKE)... yes
> ./pic_flag.at:46: exit code was 1, expected 0
> 112. pic_flag.at:24: 112. override pic_flag at configure time 
> (pic_flag.at:24): FAILED (pic_flag.at:46)

Ouch.  My bad.

I'm pushing the patch below to avoid the test in this case, and to make
a note in another test to point to the issue.

Thanks,
Ralf

Do not call toplevel configure in non-VPATH build.

* tests/deplibs-mingw.at (deplibs without file command): Use
LT_AT_CONFIGURE for consistency, update comment about why it
might fail.
* tests/pic_flag.at (override pic_flag at configure time): Skip
test if we are building in-tree.
Report by Rainer Tammer.

diff --git a/tests/deplibs-mingw.at b/tests/deplibs-mingw.at
index 68e8386..45aa032 100644
--- a/tests/deplibs-mingw.at
+++ b/tests/deplibs-mingw.at
@@ -74,8 +74,9 @@ EOF
   chmod +x bin/file
   PATH=`pwd`/bin${PATH_SEPARATOR-:}$PATH
   cd new-libtool
-  AT_CHECK(["$abs_top_srcdir"/configure $configure_options || exit 77],
-  [], [ignore], [ignore])
+  # configure might fail due to in-tree build of toplevel, or
+  # missing configure flags and other reasons.
+  LT_AT_CONFIGURE([|| exit 77], ["$abs_top_srcdir"/configure])
   cd ..
   LIBTOOL=new-libtool/libtool
   export LIBTOOL
diff --git a/tests/pic_flag.at b/tests/pic_flag.at
index c045ed4..ffad842 100644
--- a/tests/pic_flag.at
+++ b/tests/pic_flag.at
@@ -43,6 +43,7 @@ if $CXX $CPPFLAGS $CXXFLAGS $CXX_pic_flag -c foo.cpp; then :; 
else
   CXX_pic_flag=
 fi
 
+AT_CHECK([test "$at_srcdir" != . || exit 77])
 LT_AT_CONFIGURE([lt_cv_prog_compiler_pic="$C_pic_flag" ]dnl
[lt_cv_prog_compiler_pic_CXX="$CXX_pic_flag"],
["$abs_top_srcdir"/configure])

Allow running pic_flag test with different shell.

[Ralf Wildenhues]

I'd like to ensure that $CONFIG_SHELL and $configure_options are used
consistently throughout the testsuite.  So I'm fixing the pic_flag test
to also use LT_AT_CONFIGURE, after making that macro accept a second
argument to specify another configure script location.

Hope this is trivial enough to just push it, please complain otherwise.

Thanks,
Ralf

Allow running pic_flag test with different shell.

* tests/testsuite.at (LT_AT_CONFIGURE): Accept optional second
argument specifying the configure script to run.
* tests/pic_flag.at (override pic_flag at configure time):
Use LT_AT_CONFIGURE.

diff --git a/tests/pic_flag.at b/tests/pic_flag.at
index e62e1b7..c045ed4 100644
--- a/tests/pic_flag.at
+++ b/tests/pic_flag.at
@@ -43,8 +43,9 @@ if $CXX $CPPFLAGS $CXXFLAGS $CXX_pic_flag -c foo.cpp; then :; 
else
   CXX_pic_flag=
 fi
 
-AT_CHECK(["$abs_top_srcdir"/configure lt_cv_prog_compiler_pic="$C_pic_flag" 
]dnl
-[lt_cv_prog_compiler_pic_CXX="$CXX_pic_flag"], [], [ignore], [ignore])
+LT_AT_CONFIGURE([lt_cv_prog_compiler_pic="$C_pic_flag" ]dnl
+   [lt_cv_prog_compiler_pic_CXX="$CXX_pic_flag"],
+   ["$abs_top_srcdir"/configure])
 : ${MAKE=make}
 AT_CHECK([$MAKE], [], [stdout], [ignore])
 AT_CHECK([if ./libtool --features | grep 'enable shared libraries'; then ]dnl
diff --git a/tests/testsuite.at b/tests/testsuite.at
index 3935962..35b920b 100644
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -146,11 +146,13 @@ AT_KEYWORDS([autoconf automake])
 ])
 
 
-# LT_AT_CONFIGURE([OPTIONS])
-# --
+# LT_AT_CONFIGURE([OPTIONS], [CONFIGURE-SCRIPT])
+# --
+# Configure CONFIGURE-SCRIPT, defaulting to ./configure, with
+# additional OPTIONS.
 m4_define([LT_AT_CONFIGURE],
 [AT_CHECK([: ${CONFIG_SHELL=/bin/sh}; export CONFIG_SHELL; ]dnl
- [$CONFIG_SHELL ./configure $configure_options $1],
+ [$CONFIG_SHELL m4_default([$2], [./configure]) $configure_options $1],
  [0], [ignore], [ignore])
 ])
 

Avoid unwanted error message in configure output.

[Ralf Wildenhues]

There might be no 'print' program available, and some shells (like
FreeBSD sh) redirect that stderr only when you call the program from
a subshell.  I'm installing this to beautify configure output.

The second 'print' instance should be fine, and 'printf' can be assumed
to at least be present everywhere, I think.

Cheers,
Ralf

Avoid unwanted error message in configure output.

* libltdl/m4/libtool.m4 (_LT_PROG_ECHO_BACKSLASH): Try print
in subshell, so eventual `print: not found' is hidden reliably.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index d8d6aeb..c36a6b4 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1122,7 +1122,7 @@ ECHO=$ECHO$ECHO$ECHO$ECHO$ECHO$ECHO
 
 AC_MSG_CHECKING([how to print strings])
 # Test print first, because it will be a builtin if present.
-if test "X`print -r -- -n 2>/dev/null`" = X-n && \
+if test "X`( print -r -- -n ) 2>/dev/null`" = X-n && \
test "X`print -r -- $ECHO 2>/dev/null`" = "X$ECHO"; then
   ECHO='print -r --'
 elif test "X`printf %s $ECHO 2>/dev/null`" = "X$ECHO"; then

Re: libtool-2.2.11a on AIX 5.3 current git master / followup on the old test suite and failures in the new testsuit

[Ralf Wildenhues]

* Rainer Tammer wrote on Thu, Aug 05, 2010 at 09:25:14AM CEST:
> I just refreshed my source from git and rerun the test suit on AIX 5.3.

>  75: lt_dlopenext error messages FAILED
> (lt_dlopenext.at:202)
>  76: libdir of installed modules FAILED
> (ltdl-libdir.at:104)

Relevant log excerpts:

| libtool: compile:  cc_r -qlanglvl=extc89 
-I/daten/source/libtool-2.2.11a/libltdl -g -c ltdl-loader.c  -DPIC -o 
.libs/ltdl-loader.o
| ./lt_dlopenext.at:202: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o 
ltdl-loader$EXEEXT   ltdl-loader.$OBJEXT -dlopen self $LIBLTDL
| stderr:
| cc_r: 1501-228 (W) input file ltdl-loader.o not found
| stdout:
| libtool: link: rm -f .libs/ltdl-loader.nm .libs/ltdl-loader.nmS 
.libs/ltdl-loader.nmT
| libtool: link: (cd .libs && cc_r -qlanglvl=extc89 -g -c "ltdl-loaderS.c")
| libtool: link: rm -f ".libs/ltdl-loaderS.c" ".libs/ltdl-loader.nm" 
".libs/ltdl-loader.nmS" ".libs/ltdl-loader.nmT"
| libtool: link: cc_r -qlanglvl=extc89 -g -o ltdl-loader ltdl-loader.o 
.libs/ltdl-loaderS.o -Wl,-bexpall  
/daten/source/libtool-2.2.11a/libltdl/.libs/dlopen.a
| libtool: link: rm -f ".libs/ltdl-loaderS.o"
| ./lt_dlopenext.at:202: exit code was 252, expected 0
| 75. lt_dlopenext.at:23: 75. lt_dlopenext error messages (lt_dlopenext.at:23): 
FAILED (lt_dlopenext.at:202)

| ./ltdl-libdir.at:102: $LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c m.c
| stderr:
| stdout:
| libtool: compile:  cc_r -qlanglvl=extc89 
-I/daten/source/libtool-2.2.11a/libltdl -g -c m.c  -DPIC -o .libs/m.o
| ./ltdl-libdir.at:104: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m$EXEEXT   
   m.$OBJEXT $LIBLTDL
| stderr:
| cc_r: 1501-228 (W) input file m.o not found
| stdout:
| libtool: link: cc_r -qlanglvl=extc89 -g -o m m.o  
/daten/source/libtool-2.2.11a/libltdl/.libs/dlopen.a 
/daten/source/libtool-2.2.11a/tests/../libltdl/.libs/
| ./ltdl-libdir.at:104: exit code was 252, expected 0
| 76. ltdl-libdir.at:23: 76. libdir of installed modules (ltdl-libdir.at:23): 
FAILED (ltdl-libdir.at:104)

These two particular failures are straightforward to fix but the tests
will still fail with the patch below, due to other issues.  Later; I'm
pushing this for now.

Cheers,
Ralf

Fix compilation of program sources on AIX.

* tests/lt_dlopenext.at (lt_dlopenext error messages): Do not
use $LIBTOOL when compiling plain object, AIX by default does
not enable static archives.
* tests/ltdl-libdir.at (libdir of installed modules): Likewise.
Report by Rainer Tammer.

diff --git a/tests/lt_dlopenext.at b/tests/lt_dlopenext.at
index 26a2b24..6631124 100644
--- a/tests/lt_dlopenext.at
+++ b/tests/lt_dlopenext.at
@@ -1,6 +1,6 @@
 # lt_dlopenext.at -- test libltdl functionality -*- Autotest -*-
 #
-#   Copyright (C) 2009 Free Software Foundation, Inc.
+#   Copyright (C) 2009, 2010 Free Software Foundation, Inc.
 #   This file is part of GNU Libtool.
 #
 # GNU Libtool is free software; you can redistribute it and/or
@@ -197,7 +197,7 @@ AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c 
simple-module.c],
 AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o simple-module.la ]dnl
 [simple-module.lo -rpath $libdir -module -avoid-version],
 [], [ignore], [ignore])
-AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c ltdl-loader.c],
+AT_CHECK([$CC $CPPFLAGS $CFLAGS -c ltdl-loader.c],
 [], [ignore], [ignore])
 AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o ltdl-loader$EXEEXT ]dnl
 [ltdl-loader.$OBJEXT -dlopen self $LIBLTDL],
diff --git a/tests/ltdl-libdir.at b/tests/ltdl-libdir.at
index f5dc33c..7065c5b 100644
--- a/tests/ltdl-libdir.at
+++ b/tests/ltdl-libdir.at
@@ -101,7 +101,7 @@ AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c 
a.c],
 AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o a.la ]dnl
 [a.lo -rpath $libdir -module -shared -avoid-version],
 [], [ignore], [ignore])
-AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c m.c],
+AT_CHECK([$CC $CPPFLAGS $CFLAGS -c m.c],
 [], [ignore], [ignore])
 AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m$EXEEXT ]dnl
 [m.$OBJEXT $LIBLTDL],

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

FWIW, I didn't find any more objectionable things in the rest of this
patch series, so whenever you have something that addresses the known
issues, I think a public branch would be fine.  If merely additional
testsuite items are missing, that shouldn't hold up creating a branch,
only merging it.

And Thanks! to both of you again,
Ralf

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

Hi Charles,

* Charles Wilson wrote on Sat, Aug 07, 2010 at 06:06:14PM CEST:
> configure:2917: checking whether the C compiler works
> configure:2939: gcc --sysroot=/tmp/sysroot   conftest.c  >&5
> /usr/bin/ld: this linker was not configured to use sysroots
> collect2: ld returned 1 exit status
> 
> Err...ooops.
> 
> $ ld --sysroot=/bob
> ld: this linker was not configured to use sysroots
> 
> 
> Well. That sux.

Yep.  :-/

> I wonder what would happen if you built a (native) toolchain with
> sysroot support, but with the default "sysroot" == "/"?  OTOH, if you're
> gonna go thru the trouble of specially building an entire toolchain just
> to ensure that the sysroot support in libtool gets tested, you might as
> well do it using an actual *cross* compiler with sysroot support.

True.

> Quick poll: does anybody's (linux) system 'ld' support the --sysroot
> option?  To find out, just run 'ld --sysroot=/bob'

I've tried my half dozen systems now, none of them do, not even the
Debian MinGW cross ld.

Thank you for investing the work in this.  If you're really motivated,
then it would still be nice to have such a test, but obviously it's not
a big help, so might as well skip that then.

Cheers,
Ralf (makes a note to create a decent cross setup for regular testing)

Re: [PATCH] Add func_append_quoted and do inline func_append substitutions.

[Ralf Wildenhues]

Hi Gary,

* Ralf Wildenhues wrote on Mon, Jun 28, 2010 at 07:34:35AM CEST:
> * Gary V. Vaughan wrote on Mon, Jun 28, 2010 at 01:24:39AM CEST:
> > Looking through the XSI substitutions, or more correctly the bash/ksh
> > func_append usage, there's room here to consistently use func_append
> > everywhere to make for easier maintenance... but rather than take the
> > additional overhead of a function call in the sensitive quadratic scaling
> > parts that prompted the introduction of the += idiom in the first place:
> > use the libtool rewriting  machinery to substitute inline `+=' where
> > possible, with a fallback to the earlier longhand otherwise.
> > 
> > Okay to push?
> 
> OK thanks!

I approved this patch v2.2.10-40-g0da7d80 aka.
<http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00190.html>
back then without much concern, but trying to debug libtool script
issues, and seeing users struggle with nonportable shell constructs
(even if these turn out to be user side issues later):
<http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7475>

I'm now wondering whether we shouldn't maybe reevaluate the inline
expansion of nonportable code.  The change has an unknown performance
upside and a known usability downside of needing to hack several places
rather than just one func_append instance.  Has the speedup been
measured?  If not, is there a chance that we can somehow agree on either
having numbers to prove that this actually helps in practice, or
otherwise reverting the inlining part of this patch?

Thanks,
Ralf

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

* Charles Wilson wrote on Sun, Aug 08, 2010 at 10:40:56PM CEST:
> So, you suggesting *possibly* a test where:
> 
> if not cross-compiling
>   if (the native) ld supports --sysroot
> 1. create a fake sysroot (contents TBD?)
> 2. execute sysroot.at contents as a subtest, with
>native toolchain + --sysroot=my-fake-sysroot
>   else
> skip
> else
>   skip

I think so, yes.  That might help in practice because a new ld is
quickly built, and maybe prebuilt ld with --sysroot becomes more common
in the future.

But please let this not distract time from more important work now,
the patch series should not depend on it.

Thanks,
Ralf

Re: [RFT PATCH v4 0/8] Sysroot series

[Ralf Wildenhues]

* Charles Wilson wrote on Mon, Aug 09, 2010 at 12:14:37AM CEST:
> On 8/7/2010 2:36 AM, Ralf Wildenhues wrote:
> > FWIW, I didn't find any more objectionable things in the rest of this
> > patch series, so whenever you have something that addresses the known
> > issues, I think a public branch would be fine. 
> 
> Well, that's up to Paolo.
> 
> > If merely additional
> > testsuite items are missing, that shouldn't hold up creating a branch,
> > only merging it.
> 
> Hmm...but if I understand your last message in the other subthread,
> adding a test for sysroot with "native" compilers is very very optional,

This message you are replying to is older than the other subthread.
The GNU list server was down for more than 24 hours.

> Ralf: do ALL of these items need solutions before the temp branch is
> created?  If Paolo wants to delegate, it'd certainly be easier to manage
> if the basic set of patches were already in a branch, which effort
> continues on these items.

You can create a temp branch any time you like.

Cheers,
Ralf

finish mode (was: [RFT PATCH v4 0/8] Sysroot series)

[Ralf Wildenhues]

* Charles Wilson wrote on Mon, Aug 09, 2010 at 12:14:37AM CEST:
> I think --mode=finish needs to accept additional arguments that are not
> directories, somehow.  Maybe mode=finish needs to iterate through its
> arguments, and split them into "directories" and ".la files", and then
> execute two different commands:

Letting --finish accept .la file names is a valid (but low priority)
optimization opportunity.  It can be done unrelated to this thread, and
this thread does not need to wait for the feature to be implemented,
I don't see any reason this thread *absolutely needs* that feature.

> So, taking (4) and (5) together, it looks like we need
> 
> a) backport support to older libtool so that, IF there are '=' symbols
> in .la files, libtool won't barf when you're doing native development on
> $host.
> 
> b) some tool (an extension to mode=finish that accepts a list of .la
> files; some other tool?)

Or just mode=finish for now.

> to remove those '=' markers -- so that "old"
> libtool, and apps using "old" libltdl, are not confused.  This tool
> would be used as part of postinstall scripts in packages, or perhaps
> done in a staging area on $build when preparing the image for creating a
> deployment package (RPM, tarball, etc) for $host.  Whatever this is, it
> needs documenting in NEWS.

Yep.  And while you're doing (a), then letting libltdl be lenient about
'=' is prudent.

Cheers,
Ralf

Re: [PATCH] Add func_append_quoted and do inline func_append substitutions.

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Sun, Aug 08, 2010 at 08:50:12AM CEST:
> On 7 Aug 2010, at 18:15, Ralf Wildenhues wrote:
> > <http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00190.html>

> I don't see that the +=/func_append substitution is causing any additional
> concerns to the XSI function substitution though. The whole function
> substitution is really a single issue in this case, right?  Either we need
> to work on it to the point where it will DTRT reliably, or else we should
> remove all of the function substitution machinery, and go back to writing
> portable shell everywhere.

Agreed, but bugs can always happen.

> I'd rather not do that actually, but I don't have time to work on getting
> timings or looking at bugs right now, so I'm more than happy to leave the
> decision in your capable hands.

Thanks; I'm still undecided, but measurements of
  make check-local TESTSUITEFLAGS='-k libtool'

cannot detect a performance impact in the noise.  There can still be one
with another workload, of course.

I think we should have a rule to not apply pure optimization patches
without measurement results.

Cheers,
Ralf

Re: Next Libtool Point Release Pending

[Ralf Wildenhues]

Hello,

* Peter O'Gorman wrote on Mon, Aug 09, 2010 at 05:38:44PM CEST:
> I don't think having a stable and development branch worked well
> with 1.5.x and 2.x. It added more work for us, and did not serve our
> users well - they had to wait years for the development branch's
> features to make it into a released libtool.
> 
> Developing new features etc. on a branch is, of course, ok, in my
> opinion (having to wait several years to merge is not so good
> though).
> 
> I don't really care what the version number is - as long as it's
> greater than the previous one :-)

I agree with Peter on all accounts.

Our testsuite has been getting better, so more issues should be exposed
(given testing on suitably many different systems and setups); also, the
w32 stuff has cooked long enough now; no, let me clarify: it has been
cooking far too long already (blame me if you like).

I don't think having more than one release branch will increase adoption
rates at all.  In fact, I really prefer having *one* version only,
because if anything then we are already understaffed for one branch.

Feature branches are cool, but should be merged in a timeframe measured
in (low-digit) weeks.  At least, that should be the goal.  (Yes, I can
at least try!)


I also don't think that cherry-picking already published patches is a
grand idea, now that I've come to like branching and merging a lot in
Automake.  ;-)  But I'm fine with ignoring that for the sake of this
discussion.

I do think however that it's time that our testing efforts become a bit
more coordinated, to make regression tracking easier and more apparent.
Will reply to this post with more details.

* Gary V. Vaughan wrote on Mon, Aug 09, 2010 at 06:52:19PM CEST:
> That's true, but I think that was because we tried too hard to make
> the 2.x branch perfect, and spent altogether too much time pumping out
> more and more 1.5.x releases with patches merged back from an ever
> diverging code base. As long as we're careful not to do any of this
> things, then we can avoid repeating history.

Do you really want to reopen this can?  IMVHO 2.x took so long because
it was destabilized *too* *much*.

> Does git offer the means to relabel the head of
> a branch as master? Then I can cherry-pick the bug fixes from the
> current master, rename it to branch-2-2, and relabel the cherry-picked
> branch as the new master... voilà: stable master, and feature branch
> for msvc :-)

Except that the new branch is completely untested, the interaction of
cherry-picked patches with non-ones is unknown ...

Cheers,
Ralf

autobuild logs for Libtool (was: Next Libtool Point Release Pending)

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Mon, Aug 09, 2010 at 08:42:24PM CEST:
> I do think however that it's time that our testing efforts become a bit
> more coordinated, to make regression tracking easier and more apparent.
> Will reply to this post with more details.

I think Libtool should use Autobuild, <http://josefsson.org/autobuild/>,
for testing, and developers as well as users should be encouraged to
send results to the gathering site.  It's about time I try to get my
various build setups sorted out in some manner suitable for that.

This should help us catch (and pinpoint) regressions more easily,
hopefully.

Cheers,
Ralf

another func_append inlining regression (was: libtool-2.2.11a on AIX 5.3 current git master / followup on the old test suite and failures in the new testsuit)

[Ralf Wildenhues]

* Rainer Tammer wrote on Thu, Aug 05, 2010 at 09:25:14AM CEST:
> The new test suite still yields many failures in comparison to 2.2.8.

I assume most if not all of the regressions are due to a single issue:

> # grep FAILED check.log
>  38: Link order of deplibs   FAILED
> (link-order2.at:138)

That fails more or less like this (taken from a test run of mine) in git
master:

../../libtool/tests/link-order2.at:123: $LIBTOOL --mode=link $CC $CFLAGS 
$LDFLAGS $static -o main$EXEEXT main.$OBJEXT libb.la -la0
+ /home/rwild/lt/build-powerpc-ibm-aix5.3.0.0/libtool --mode=link cc 
-qlanglvl=extc89 -g -no-undefined 
-L/home/rwild/lt/build-powerpc-ibm-aix5.3.0.0/tests/t
estsuite.dir/039/lib -o main main.o libb.la -la0
stderr:
stdout:
libtool: link: cc -qlanglvl=extc89 -g -o .libs/main main.o  
-L/home/rwild/lt/build-powerpc-ibm-aix5.3.0.0/tests/testsuite.dir/039/.libs 
-L/home/rwild/lt/bui
ld-powerpc-ibm-aix5.3.0.0/tests/testsuite.dir/039/lib -L./.libs -lb -la1 -la0 
-Wl,-blibpath::/home/rwild/lt/build-powerpc-ibm-aix5.3.0.0/tests/testsuite.dir
/039/lib:/usr/vac/lib:/usr/lib:/lib

Note the double colon after -blibpath, which is due to a regression in
v2.2.10-40-g0da7d80 fixed with the patch below.  I wish I'd never
approved that patch, this one took me so long to find ...

Thanks,
Ralf

Fix another typo on "Add func_append_quoted and do..."

* libltdl/config/ltmain.m4sh (func_mode_link): Fix regression in
computation of finalize_rpath introduced in v2.2.10-40-g0da7d80,
fixing several testsuite failures on AIX.
Report by Rainer Tammer.

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index fad2e64..e5065fb 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -7568,7 +7568,7 @@ EOF
  *"$hardcode_libdir_separator$libdir$hardcode_libdir_separator"*)
;;
  *)
-   func_append hardcode_libdirs 
"_libdirs$hardcode_libdir_separator$libdir"
+   func_append hardcode_libdirs "$hardcode_libdir_separator$libdir"
;;
  esac
fi

Re: another func_append inlining regression

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Mon, Aug 09, 2010 at 10:55:25PM CEST:
> Note the double colon after -blibpath, which is due to a regression in
> v2.2.10-40-g0da7d80 fixed with the patch below.  I wish I'd never
> approved that patch, this one took me so long to find ...

I did a re-review of that patch, and found more issues: the shell
doesn't do word splitting on the RHS of an assignment, but does do so
with function call arguments.  Fixed as follows.

Cheers,
Ralf

Fix more problematic code from "Add func_append_quoted and do..."

* libltdl/config/ltmain.m4sh (func_mode_link): Revert back
func_append instances that as assignments relied on the shell
not performing word splitting on the right hand side of the
assignment.

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index e5065fb..d677529 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2464,7 +2464,7 @@ func_extract_archives ()
 func_extract_an_archive "$my_xdir" "$my_xabs"
;;
   esac
-  func_append my_oldobjs " "`find $my_xdir -name \*.$objext -print -o 
-name \*.lo -print | sort | $NL2SP`
+  my_oldobjs="$my_oldobjs "`find $my_xdir -name \*.$objext -print -o -name 
\*.lo -print | sort | $NL2SP`
 done
 
 func_extract_archives_result="$my_oldobjs"
@@ -5854,7 +5854,7 @@ func_mode_link ()
  compile_deplibs="$new_inherited_linker_flags $compile_deplibs"
  finalize_deplibs="$new_inherited_linker_flags $finalize_deplibs"
else
- func_append compiler_flags " "`$ECHO " $new_inherited_linker_flags" | 
$SED 's% \([^ $]*\).ltframework% -framework \1%g'`
+ compiler_flags="$compiler_flags "`$ECHO " 
$new_inherited_linker_flags" | $SED 's% \([^ $]*\).ltframework% -framework 
\1%g'`
fi
   fi
   dependency_libs="$newdependency_libs"

Re: How to maintain compatibility with Automake.

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Tue, Aug 10, 2010 at 11:09:33AM CEST:
> On 10 Aug 2010, at 15:19, Peter Rosin wrote:
> > m4_defun([AM_PROG_AR],
> > [AC_CHECK_TOOLS(AR, [ar], false)
> > : ${AR=ar}
> > AC_SUBST([AR])dnl
> > ])# AM_PROG_AR
> > ])
> 
> Just like that!

NAK.  I don't have time to explain now, but this should be completely
unnecessary.  Esp since Libtool already sets $AR.

Re: How to maintain compatibility with Automake.

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Tue, Aug 10, 2010 at 11:15:21AM CEST:
> * Gary V. Vaughan wrote on Tue, Aug 10, 2010 at 11:09:33AM CEST:
> > On 10 Aug 2010, at 15:19, Peter Rosin wrote:
> > > m4_defun([AM_PROG_AR],
> > > [AC_CHECK_TOOLS(AR, [ar], false)
> > > : ${AR=ar}
> > > AC_SUBST([AR])dnl
> > > ])# AM_PROG_AR
> > > ])
> > 
> > Just like that!
> 
> NAK.  I don't have time to explain now, but this should be completely
> unnecessary.  Esp since Libtool already sets $AR.

Sorry for the short and harsh answer, here's a longer explanation:

First, LT_INIT already causes AC_CHECK_TOOLS([AR], ...) to be invoked.
Second, overrides of the form
  m4_ifndef([MACRO],
  [ AC_DEFUN([MACRO], [...]) ])

in public m4 files (installed in $datarootdir/aclocal) are very
problematic for third-party projects if MACRO does not come from
Autoconf itself: aclocal will pick it up and install libtool.m4 in
projects using MACRO even if the project otherwise doesn't use Libtool
at all!  Users were quite annoyed about that.

Now, in the above you don't use AC_DEFUN, so hopefully that particular
aclocal issue is lessened.  But still, I have had too much pain with
additions to lt~obsolete.m4[1] that I'd really prefer not adding macros
which belong to third parties to public Libtool macro files.

For macros that are otherwise present only in the Autoconf project, this
issue is not a problem: there is not an ordering problem between files
in $datarootdir/autoconf and $datarootdir/aclocal.  That's why Gary's
examples work fine.

Back on topic, I'm writing a reply to
<http://thread.gmane.org/gmane.comp.gnu.libtool.general/10927/focus=4438>
that hopefully addresses the remaining questions around AM_PROG_AR.

Cheers,
Ralf

[1] Case in point: $datarootdir/aclocal contains old lt~obsolete.m4
file, in-tree m4/ subdir contains yet another version; now, even with
the file naming done in the order that the other Libtool macro files
come first, doing 'aclocal -I m4' means that you will see macro names
twice, and suddenly not all of the obsolete names come last ...
I ended up just uninstalling the Libtool macro files.  I'm assuming some
of the scary bug reports that nobody addresses are due to issues like
this.

Re: [PATCH] Allow the use of a listing file if the archiver supports it.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Thu, Aug 12, 2010 at 03:28:57PM CEST:
> This is a patch that makes use of @FILE support in the
> archiver, if the archiver supports it. That makes linking
> succeed for long command lines when using MSVC, as MSVC
> can't do piecewise linking (-r -o) which is the current
> fallback. Absolute paths still needs work, but that will
> have to wait for Chucks work in that area.

Absolute paths are not a show stopper, for practical purposes.

This is ok for master with nits below addressed.

Thanks!
Ralf

> Subject: [PATCH] Allow the use of a listing file if the archiver supports it.
> 
> * libltdl/m4/libtool.m4 (_LT_CMD_OLD_ARCHIVE): Move detection
> of a suitable archiver...
> (_LT_PROG_AR): ...to here. New macro, also detect if the
> archiver supports a listing file with the new variable
> archiver_list_spec.
> * libltdl/config/ltmain.m4sh: If the archiver supports a listing
> file, use it when max_cmd_len is exceeded.  This is needed for
> tool chains such as MSVC which do not support piece by piece
> linking (-r -o).
> * doc/libtool.texi (libtool script contents): Update with
> archiver_list_spec description.

> --- a/doc/libtool.texi
> +++ b/doc/libtool.texi
> @@ -5875,6 +5875,10 @@ Commands used to create shared libraries, shared 
> libraries with
>  @option{-export-symbols} and static libraries, respectively.
>  @end defvar
>  
> +...@defvar archiver_list_spec
> +How to feed a file listing to the archiver.
> +...@end defvar

We already have

@defvar nm_file_list_spec
Specify filename containing input files for @code{NM}.
@end defvar

and I like that description a wee bit better, with s/NM/AR/.  WDYT?

> --- a/libltdl/config/ltmain.m4sh
> +++ b/libltdl/config/ltmain.m4sh
> @@ -7900,6 +7900,16 @@ EOF
>   len=$func_len_result
>   if test "$len" -lt "$max_cmd_len" || test "$max_cmd_len" -le -1; then
> cmds=$old_archive_cmds
> + elif test -n "$archiver_list_spec"; then
> +   func_verbose "using command file archive linking..."
> +   for obj in $oldobjs
> +   do
> + $ECHO \""$obj"\"

Have you tried and ensured that those \"extra\" quotes are necessary
and no problem?  I'd leave them out otherwise.

> +   done > $output_objdir/$libname.libcmd
> +   save_oldobjs="$oldobjs"
> +   oldobjs=" $archiver_list_spec$output_objdir/$libname.libcmd"
> +   eval cmds=\"\$old_archive_cmds\"

This eval looks spurious, it should be sufficient to just say
  cmds=$old_archive_cmds

here.  You do need to remove or move down the following line then,
however:

> +   oldobjs="$save_oldobjs"

Rationale I'm being picky here: the extra eval expands '~' in file
names listed in $old_archive_cmds which then causes failures such as

(Yes, I'm still not done with a general fix, but I'd like to avoid
proliferating the problem where possible.)

If my suggestions don't work, then feel free to go ahead with your
version, I'll make a note to investigate then.

> --- a/libltdl/m4/libtool.m4
> +++ b/libltdl/m4/libtool.m4
> @@ -1312,14 +1312,42 @@ need_locks="$enable_libtool_lock"
>  ])# _LT_ENABLE_LOCK
>  
>  
> +# _LT_PROG_AR
> +# ---
> +m4_defun([_LT_PROG_AR],
> +[AC_CHECK_TOOLS(AR, [ar], false)
> +: ${AR=ar}
> +: ${AR_FLAGS=cru}
> +_LT_DECL([], [AR], [1], [The archiver])
> +_LT_DECL([], [AR_FLAGS], [1], [Flags to create an archive])
> +
> +AC_CACHE_CHECK([for archiver @FILE support], [lt_cv_ar_at_file],
> +  [lt_cv_ar_at_file=no
> +   AC_COMPILE_IFELSE([[int some_variable = 0;]],
> + [echo conftest.$ac_objext > conftest.lst
> +  am_ar_try='$AR $AR_FLAGS libconftest.a @conftest.lst'
> +  AC_TRY_EVAL([am_ar_try])
> +  if test "$ac_status" -eq 0; then
> +lt_cv_ar_at_file=@
> +  fi
> +  rm -f conftest.* libconftest.a
> + ])
> +  ])
> +
> +if test "x$lt_cv_ar_at_file" = xno; then
> +  archiver_list_spec=
> +else
> +  archiver_list_spec=lt_cv_ar_at_file

There is a $ missing here.  I think this should cause at least some of
our current tests to fail.

> +fi
> +_LT_DECL([], [archiver_list_spec], [1],
> +  [How to feed a file listing to the archiver])
> +])# _LT_PROG_AR

Re: [PATCH 0/2] sysroot patches followup

[Ralf Wildenhues]

* Paolo Bonzini wrote on Thu, Aug 12, 2010 at 06:12:15AM CEST:
> Hi, I pushed the first 8 sysroot patches to refs/heads/sysroot on
> Savannah.

Thanks.  So far, with a merge of sysroot to master, I see one regression
on AIX with runtimelinking (configure LDFLAGS=-Wl,-brtl) and a different
one on Solaris, both of which could however also stem from a couple of
other patches that haven't made it into the mainline tree.  Will
investigate, hopefully by Saturday (and look at the --finish issue, if
you haven't solved it by then).

Cheers,
Ralf

../../libtool/tests/deplibs-ident.at:53: $LIBTOOL --mode=link $CC $CFLAGS 
$LDFLAGS -o liba$i.la liba$i.lo $depend_on_c -rpath /nowhere
stderr:
ld: 0706-006 Cannot find or open library file: -l cee
ld:open(): No such file or directory
stdout:
libtool: link: /bin/nm -B -BCpg  .libs/liba3.o   | awk '{ if ((($ 2 == "T") || 
($ 2 == "D") || ($ 2 == "B")) && (substr($ 3,1,1) != ".")) { print $ 3 } }' | 
sort -u > .libs/liba3.exp
libtool: link: cc -qlanglvl=extc89 -o .libs/liba3.so.0.0.0  .libs/liba3.o   
-L../c -lcee -lc -Wl,-bnoentry  -qlanglvl=extc89 -Wl,-brtl   `if test "x-berok" 
!= "x"; then func_echo_all "-Wl,-berok"; else :; fi` 
-Wl,-bexport:.libs/liba3.exp -Wl,-G
../../libtool/tests/deplibs-ident.at:53: exit code was 255, expected 0
../../libtool/tests/deplibs-ident.at:65: $CC $CFLAGS -c b.c
stderr:
stdout:
../../libtool/tests/deplibs-ident.at:66: $LIBTOOL --mode=link $CC $CFLAGS 
$LDFLAGS -o b$EXEEXT b.$OBJEXT ../liba1.la ../liba2.la ../liba3.la 
../../c/libcee.la -rpath /nowhere
stderr:
libtool: link: cannot find the library 
`/home/rwild/lt/build-powerpc-ibm-aix5.3.0.0-rtl/tests/testsuite.dir/106/a/liba3.la'
 or unhandled argument 
`/home/rwild/lt/build-powerpc-ibm-aix5.3.0.0-rtl/tests/testsuite.dir/106/a/liba3.la'
stdout:
../../libtool/tests/deplibs-ident.at:66: exit code was 1, expected 0
106. deplibs-ident.at:32: 106. build tree relpaths (deplibs-ident.at:32): 
FAILED (deplibs-ident.at:66)

Re: [PATCH v2 1/4] fix sysroot tests to pass on Fedora 13

[Ralf Wildenhues]

* Paolo Bonzini wrote on Fri, Aug 13, 2010 at 03:23:03AM CEST:
> * tests/sysroot.at: Link $prefix/include into the sysroot as well, as
> required by newer GCC.

Obviously.

Thanks!
Ralf

Re: [PATCH v2 2/4] fix sysroot handling for deplibs of preopened libtool libs

[Ralf Wildenhues]

* Paolo Bonzini wrote on Fri, Aug 13, 2010 at 03:23:04AM CEST:
> * libltdl/config/ltmain.m4sh: Pass $dependency_libs of preopened libtool
> through func_resolve_sysroot.

This looks ok, but is it covered in the testsuite?
(If not, I can try to do it later, but at least would like to be sure we
make a mental note.)

Thanks,
Ralf

> --- a/libltdl/config/ltmain.m4sh
> +++ b/libltdl/config/ltmain.m4sh
> @@ -4964,8 +4964,9 @@ func_mode_link ()
>   for lib in $dlprefiles; do
> # Ignore non-libtool-libs
> dependency_libs=
> +   func_resolve_sysroot "$lib"
> case $lib in
> -   *.la) func_source "$lib" ;;
> +   *.la) func_source "$func_resolve_sysroot_result" ;;
> esac
>  
> # Collect preopened libtool deplibs, except any this library

Re: [PATCH v2 3/4] reorganize parsing of --mode=finish arguments

[Ralf Wildenhues]

* Paolo Bonzini wrote on Fri, Aug 13, 2010 at 03:23:05AM CEST:
> * libltdl/config/ltmain.m4sh (func_mode_finish): Split arguments for
> directories and *.la files.  Add .la files for all directories.

OK if you fix the log entry.  IIUC the last sentence is wrong.

Thanks,
Ralf

Re: [PATCH v2 3/4] reorganize parsing of --mode=finish arguments

[Ralf Wildenhues]

* Paolo Bonzini wrote on Fri, Aug 13, 2010 at 03:23:05AM CEST:
> * libltdl/config/ltmain.m4sh (func_mode_finish): Split arguments for
> directories and *.la files.  Add .la files for all directories.

Ah, there's another nit.

> --- a/libltdl/config/ltmain.m4sh
> +++ b/libltdl/config/ltmain.m4sh
> @@ -1397,15 +1397,28 @@ test "$opt_mode" = execute && func_mode_execute 
> ${1+"$@"}
>  func_mode_finish ()
>  {
>  $opt_debug
> -libdirs="$nonopt"
> +libs=
> +libdirs=
>  admincmds=
>  
> -if test -n "$finish_cmds$finish_eval" && test -n "$libdirs"; then
> -  for dir
> -  do
> - func_append libdirs " $dir"
> -  done
> +for opt in "$nonopt" "$@"

This should be "$nonopt" ${1+"$@"} because you might not have any
arguments in $@ any more.

> +do
> +  if test -d "$opt"; then
> + func_append libdirs " $opt"
> +
> +  elif test -f "$opt"; then
> + if func_lalib_unsafe_p "$opt"; then
> +   func_append libs " $opt"
> + else
> +   func_warning "\`$opt' is not a valid libtool archive"
> + fi
> +
> +  else
> + func_fatal_error "invalid argument \`$opt'"
> +  fi
> +done

Re: [PATCH v2 4/4] add libtool --mode=finish mode for sysroot

[Ralf Wildenhues]

* Paolo Bonzini wrote on Fri, Aug 13, 2010 at 03:23:06AM CEST:
> ---

Erm, you should be mentioning the files you change in your log entries,
and Libtool also doesn't auto-generate its ChangeLog (yet), so you need
that, too, also for all the other patches in the sysroot branch.

Sorry for not noticing that sooner.

>  doc/libtool.texi   |   18 --
>  libltdl/config/ltmain.m4sh |   21 +
>  tests/sysroot.at   |3 +++

> --- a/doc/libtool.texi
> +++ b/doc/libtool.texi
> @@ -1721,12 +1721,18 @@ commands are also completed.
>  @cindex finish mode
>  @cindex mode, finish
>  
> -...@dfn{finish} mode helps system administrators install libtool libraries
> -so that they can be located and linked into user programs.
> -
> -Each @var{mode-arg} is interpreted as the name of a library directory.
> -Running this command may require superuser privileges, so the
> -...@option{--dry-run} option may be useful.
> +...@dfn{finish} mode has two functions.  One is to help system administrators
> +install libtool libraries so that they can be located and linked into
> +user programs.  To invoke this functionality, pass the name of a library
> +directory as @var{mode-arg}.  Running this command may require superuser
> +privileges, and the @option{--dry-run} option may be useful.
> +
> +The second is to facilitate transferring libtool libraries to a native
> +compilation environment after they were built in a cross-compilation
> +environment.  Cross-compilation environments may rely on recent libtool
> +features, and running libtool in finish mode will make it easier to
> +work with older versions of libtool.  This task is performed whenever
> +the @var{mode-arg} is a @samp{.la} file.

This is fine with me, but I think it wouldn't hurt if we mentioned
'sysroot' explicitly here.  You can of course also just do this when
you add general description of --with-sysroot.

> --- a/libltdl/config/ltmain.m4sh
> +++ b/libltdl/config/ltmain.m4sh
> @@ -1418,6 +1418,27 @@ func_mode_finish ()
>fi
>  done
>  
> +if test -n "$libs"; then
> +  tmpdir=`func_mktempdir`
> +  if test -n "$lt_sysroot"; then
> +sysroot_regex=`$ECHO "$lt_sysroot" | $SED 's/[].[^$\\*|]/&/g'`

I think libltdl/config/general.m4sh could have

  # Sed substitution that turns a string into a regex matching for the
  # string literally.
  sed_make_literal_regex='s/[].[^$\\*|]/&/g'

and use that also in func_cygming_dll_for_implib_fallback_core.
Hmpf, no, that won't work, there, /.../ is used as regex delimiter.
Using | here isn't a good idea because sed may interpret \| as
alternation or not; (and that means the regex in
func_cygming_dll_for_implib_fallback_core is slightly wrong, too).
So how about

  # Sed substitution that turns a string into a regex matching for the
  # string literally inside a regex delimited with a slash ('/').
  sed_make_literal_regex='s/[].[^$\\*/]/&/g'

and then use slashes here:

> +sysroot_cmd="s|\([ ']\)$sysroot_regex|\1|g;"

Again, since this suggestion is also fixing existing code, it's fine
to postpone this.  (I need to remember to not make people fix existing
code in their patches for new features.)

> +  else
> +sysroot_cmd=
> +  fi
> +
> +  # Remove sysroot references
> +  for lib in $libs; do
> + $opt_dry_run || {
> +   sed -e "${sysroot_cmd} s/\([ ']-[LR]\)=/\1/g; s/\([ ']\)=/\1/g" $lib \
> + > $tmpdir/tmp-la
> +   mv -f $tmpdir/tmp-la $lib
> + }

How about wrapping the whole loop in if $opt_dry_run and in the dry
case, print "removing references to $lt_sysroot and \`=' prefixes from
$libs"?

> + file="$outputname"

What's this line for?

> +  done
> +  $opt_dry_run || ${RM}r "$tmpdir"
> +fi
> +

OK with those fixed.

Thanks,
Ralf

Re: MSVC status

[Ralf Wildenhues]

* Christopher Hulbert wrote on Fri, Aug 13, 2010 at 01:45:37PM CEST:
> Is there interest (besides mine) in libtool being able to use native
> Windows compilers from cygwin. I just find cygwin easier to
> use/maintain than mingw/msys.
> 
> In the branch I had been working on, I defined the libtool variable
> link_search_path_spec=-LIBPATH: for native Windows compilers when host
> was cygwin/mingw, and empty otherwise. Then in the -L flag parsing of
> the libtool script, it would use $link_search_path_spec if non-empty,
> and -L otherwise.
> 
> If it's interesting to others, I would like to get it to work with
> current libtool and hopefully merged in, but I need help on how it
> should be done (otherwise it will never be merged in). Is what I
> previously did a good approach to this?

Well, one of the problems with all the libtool-only approaches was that
they would fail if the package in question did not use libtool.  In that
way I find the current strategy much better: it fixes each thing in one
place only (well, at least mostly), and with that also fixes packages
using only Automake; or even only Autoconf + aclocal + a couple of
macros from Automake.

I would prefer to keep adding support for different features:
- sysroot
- msys + cl
- cygwin + cl
- msys or cygwin + other w32 compiler

as separate and as orthogonal as possible.  For one in order to maintain
sanity for the developers, and also so we can remain being not to far
from a releasable state for each of the tools.

Other than that, I defer to Charles and Peter's excellent replies.

Please note that nontrivial patches require copyright assignment papers
to be completed, which typically means at least a few weeks delay from
the start.  More off-list.

Thanks,
Ralf

Re: [PATCH 0/2] sysroot patches followup

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Thu, Aug 12, 2010 at 11:28:31PM CEST:
> Thanks.  So far, with a merge of sysroot to master, I see one regression
> on AIX with runtimelinking (configure LDFLAGS=-Wl,-brtl)

OK so this one really is a regression with the patch series.  bisect
converges at the "teach libtool -L= and -R=" patch.

I think the issue is that some code paths now absolutize formerly
relative paths to in-tree deplibs which then somewhere messes up
later.  Below's a context diff of good vs. bad log output.

I'm still not sure whether it's the patch or the test that is wrong.
Will investigate further, but might be a couple of days.  I'm sure
this is fixable though.

Cheers,
Ralf

*** log-good-v2.2.10-82-g3334f7eSat Aug 14 07:06:53 2010
--- log-bad-v2.2.10-84-gadb8f84 Sat Aug 14 07:04:26 2010
***
*** 49,53 
  stdout:
  libtool: link: /bin/nm -B -BCpg  .libs/liba1.o   | awk '{ if ((($ 2 == "T") 
|| ($ 2 == "D") || ($ 2 == "B")) && (substr($ 3,1,1) != ".")) { print $ 3 } }' 
| sort -u > .libs/liba1.exp
! libtool: link: cc -qlanglvl=extc89 -o .libs/liba1.so.0.0.0  .libs/liba1.o   
-Wl,-blibpath:/home/rwild/lt/build-powerpc-ibm-aix5.3.0.0-rtl/tests/testsuite.dir/106/c/.libs:/nowhere:/usr/vac/lib:/usr/lib:/lib
 -L../c/.libs -lcee -lc -Wl,-bnoentry  -qlanglvl=extc89 -Wl,-brtl   `if test 
"x-berok" != "x"; then func_echo_all "-Wl,-berok"; else :; fi` 
-Wl,-bexport:.libs/liba1.exp -Wl,-G
  libtool: link: (cd ".libs" && rm -f "liba1.so.0" && ln -s "liba1.so.0.0.0" 
"liba1.so.0")
  libtool: link: (cd ".libs" && rm -f "liba1.so" && ln -s "liba1.so.0.0.0" 
"liba1.so")
--- 49,53 
  stdout:
  libtool: link: /bin/nm -B -BCpg  .libs/liba1.o   | awk '{ if ((($ 2 == "T") 
|| ($ 2 == "D") || ($ 2 == "B")) && (substr($ 3,1,1) != ".")) { print $ 3 } }' 
| sort -u > .libs/liba1.exp
! libtool: link: cc -qlanglvl=extc89 -o .libs/liba1.so.0.0.0  .libs/liba1.o   
-Wl,-blibpath:/home/rwild/lt/build-powerpc-ibm-aix5.3.0.0-rtl/tests/testsuite.dir/106/c/.libs:/nowhere:/usr/vac/lib:/usr/lib:/lib
 
-L/home/rwild/lt/build-powerpc-ibm-aix5.3.0.0-rtl/tests/testsuite.dir/106/c/.libs
 -lcee -lc -Wl,-bnoentry  -qlanglvl=extc89 -Wl,-brtl   `if test "x-berok" != 
"x"; then func_echo_all "-Wl,-berok"; else :; fi` -Wl,-bexport:.libs/liba1.exp 
-Wl,-G
  libtool: link: (cd ".libs" && rm -f "liba1.so.0" && ln -s "liba1.so.0.0.0" 
"liba1.so.0")
  libtool: link: (cd ".libs" && rm -f "liba1.so" && ln -s "liba1.so.0.0.0" 
"liba1.so")
***
*** 93,104 
  ++ /home/rwild/lt/build-powerpc-ibm-aix5.3.0.0-rtl/libtool --mode=link cc 
-qlanglvl=extc89 -g -Wl,-brtl -o liba3.la liba3.lo -L../c -lcee -rpath /nowhere
  stderr:
  stdout:
  libtool: link: /bin/nm -B -BCpg  .libs/liba3.o   | awk '{ if ((($ 2 == "T") 
|| ($ 2 == "D") || ($ 2 == "B")) && (substr($ 3,1,1) != ".")) { print $ 3 } }' 
| sort -u > .libs/liba3.exp
! libtool: link: cc -qlanglvl=extc89 -o .libs/liba3.so.0.0.0  .libs/liba3.o   
-Wl,-blibpath:/home/rwild/lt/build-powerpc-ibm-aix5.3.0.0-rtl/tests/testsuite.dir/106/c/.libs:/nowhere:/usr/vac/lib:/usr/lib:/lib
 
-L/home/rwild/lt/build-powerpc-ibm-aix5.3.0.0-rtl/tests/testsuite.dir/106/c/.libs
 -L/home/rwild/lt/build-powerpc-ibm-aix5.3.0.0-rtl/tests/testsuite.dir/106/c 
-lcee -lc -Wl,-bnoentry  -qlanglvl=extc89 -Wl,-brtl   `if test "x-berok" != 
"x"; then func_echo_all "-Wl,-berok"; else :; fi` -Wl,-bexport:.libs/liba3.exp 
-Wl,-G
! libtool: link: (cd ".libs" && rm -f "liba3.so.0" && ln -s "liba3.so.0.0.0" 
"liba3.so.0")
! libtool: link: (cd ".libs" && rm -f "liba3.so" && ln -s "liba3.so.0.0.0" 
"liba3.so")
! libtool: link: ar cru .libs/liba3.a  liba3.o
! libtool: link: ranlib .libs/liba3.a
! libtool: link: ( cd ".libs" && rm -f "liba3.la" && ln -s "../liba3.la" 
"liba3.la" )
  ++ cat
  ++ cd a/b
--- 93,102 
  ++ /home/rwild/lt/build-powerpc-ibm-aix5.3.0.0-rtl/libtool --mode=link cc 
-qlanglvl=extc89 -g -Wl,-brtl -o liba3.la liba3.lo -L../c -lcee -rpath /nowhere
  stderr:
+ ld: 0706-006 Cannot find or open library file: -l cee
+   ld:open(): No such file or directory
  stdout:
  libtool: link: /bin/nm -B -BCpg  .libs/liba3.o   | awk '{ if ((($ 2 == "T") 
|| ($ 2 == "D") || ($ 2 == "B")) && (substr($ 3,1,1) != ".")) { print $ 3 } }' 
| sort -u > .libs/liba3.exp
! libtool: link: cc -qlanglvl=extc89 -o .libs/liba3.so.0.0.0  .libs/liba3.o   
-L../c -lcee -lc -Wl,-bnoentry  -qlanglvl=extc89 -Wl,-brtl   `if test "x-berok" 
!= "x"; then func_echo_all "-Wl,-berok"; else :; fi` 
-Wl,-bexport:.libs/liba3.exp -Wl,-G
! ../../libtool/tests/deplibs-ident.at:53: exit code was 255, expected 0
  ++ cat
  ++ cd a/b

Re: [PATCH 0/2] sysroot patches followup

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Thu, Aug 12, 2010 at 11:28:31PM CEST:
> Thanks.  So far, with a merge of sysroot to master, I see one regression
> on AIX with runtimelinking (configure LDFLAGS=-Wl,-brtl) and a different
> one on Solaris,

The Solaris issue is shown below and is actually an old unrelated bug
that Bob reported previously and I had forgotten about again: lt_dlerror
might return NULL when it shouldn't, and that upsets Solaris printf %s,
understandably.

Cheers,
Ralf

81. lalib-syntax.at:24: testing syntax of .la files ...
[...]
++ for file in ./missing-closing-quote.la ./wrong-quotes.la ./no-dlname.la 
./nonexistent-dlname.la
++ lt_exe=./main
++ test -f ./main
++ lt_exe=./main
++ set +x
../../libtool/tests/lalib-syntax.at:128: if "$lt_exe" $file; then :; else 
lt_status=$?;test $lt_status != 1 && test "X$host" != 
"X$build" && test -x "$lt_exe" && exit 77; exit $lt_status; fi
++ ./main ./missing-closing-quote.la
++ lt_status=139
++ test 139 '!=' 1
++ test Xsparc-sun-solaris2.10 '!=' Xsparc-sun-solaris2.10
++ exit 139
stderr:
/home/rwild/lt/build-sparc-sun-solaris2.10/tests/testsuite.dir/at-groups/81/test-source:
 line 179: 11043 Segmentation Fault  (core dumped) "$lt_exe" $file
stdout:
../../libtool/tests/lalib-syntax.at:128: exit code was 139, expected 1
81. lalib-syntax.at:24:  FAILED (lalib-syntax.at:128)

Re: [PATCH] Factor the sed command used to make a regex from a literal.

[Ralf Wildenhues]

* Paolo Bonzini wrote on Sun, Aug 15, 2010 at 07:06:25PM CEST:
> In func_generate_dlsyms, the resulting regex is used with grep rather
> than sed.  I don't think grep has problems with \/ in practice, but of
> course I can change it to use sed, too.

Oh, I managed to overlook that.  In that case, sorry about my bad
suggestions.  \/ is undefined behavior for grep according to SUSv3,
I'd prefer to not delve into that territory any more than we have to,
somebody might come along and invent posix-hard-sed and file bug
reports with all nonconforming tools (hello, posh!).

> Ok? (if so, which way?)

I'd prefer if you drop the func_generate_dlsyms hunk, there's no bug to
be fixed here.  We can keep the rest though, in time the sed script will
be used elsewhere.

Thanks,
Ralf

> 2010-08-15  Paolo Bonzini  
> 
> * libltdl/config/general.m4sh (sed_make_literal_regex): New.
> * libltdl/config/ltmain.m4sh (func_generate_dlsyms,

FWIW, I think GCS style is
* file-name (function-name)
(function-name, ...):

i.e., close and reopen parens at EOL.

> func_cygming_dll_for_implib_fallback_core): Use it.  Suggested
> by Ralf Wildenhues.

Re: [PATCH] improve code for sysroot --mode=finish

[Ralf Wildenhues]

* Paolo Bonzini wrote on Sun, Aug 15, 2010 at 06:57:18PM CEST:
> Here are the improvements you suggested.  I'll send a patch for
> sed_make_literal_regex soon.
> 
> Ok?

Yes, with the nit addressed.  Thanks!
Ralf

> * libltdl/config/ltmain.m4sh (func_mode_finish): Change sysroot_regex
> and sysroot_cmd delimiter from pipe to slash.  Wrap the entire for
> loop with "if $opt_dry_run...fi" and print an explanatory message
> for the --dry-run case.

> --- a/libltdl/config/ltmain.m4sh
> +++ b/libltdl/config/ltmain.m4sh
> @@ -1419,24 +1419,27 @@ func_mode_finish ()
>  done
>  
>  if test -n "$libs"; then
> -  tmpdir=`func_mktempdir`
>if test -n "$lt_sysroot"; then
> -sysroot_regex=`$ECHO "$lt_sysroot" | $SED 's/[].[^$\\*|]/&/g'`
> -sysroot_cmd="s|\([ ']\)$sysroot_regex|\1|g;"
> +sysroot_regex=`$ECHO "$lt_sysroot" | $SED 's/[].[^$\\*/]/&/g'`

You need a \ before the / inside the bracket expression:
  +sysroot_regex=`$ECHO "$lt_sysroot" | $SED 's/[].[^$\\*\/]/&/g'`

'info Autoconf --index sed' explains why.

> +sysroot_cmd="s/\([ ']\)$sysroot_regex/\1/g;"

Re: [PATCH v2 4/4] add libtool --mode=finish mode for sysroot

[Ralf Wildenhues]

* Paolo Bonzini wrote on Sun, Aug 15, 2010 at 03:46:06PM CEST:
> On 08/13/2010 12:59 AM, Ralf Wildenhues wrote:
> >Erm, you should be mentioning the files you change in your log entries,
> >and Libtool also doesn't auto-generate its ChangeLog (yet), so you need
> >that, too, also for all the other patches in the sysroot branch.
> 
> I was planning to form a merged changelog at merge time.

Fine with me as well.  Just in case you didn't know, the
git-merge-changelog driver from gnulib, when configured correctly,
and when made sure you also have some fixes from a few weeks ago,
makes merging logs really easy, so it's not really necessary to
write them after the fact.

Cheers,
Ralf

Re: [PATCH v2 0/3] sysroot followup patches

[Ralf Wildenhues]

Hi Charles, Paolo,

* Charles Wilson wrote on Mon, Aug 16, 2010 at 05:12:03PM CEST:
> On 8/12/2010 9:23 PM, Paolo Bonzini wrote:
> > These cover bullets 3/5 of Charles' list:
> > 
> > 3) issue with '# Collect and forward deplibs of preopened libtool libs'
> >In progress? Anything?
> > 4,5)
> >* patch for old libtool, to not barf on '='
> >* TBD mechanism to strip '=' from .la after deployment on $host
> > 6) support in libltdl for '=' in .la files
> > 
> > I didn't do 4...
> 
> Well, sure. We really need to discuss how to approach this. It's not
> like we want to cut a new release of libtool-1.5; if people are going to
> update their local libtool, we'd really rather they update to
> libtool-2.2.latest, not a minor update to 1.5.
> 
> My impression was that Ralf was concerned about people who are using,
> say, libtool-2.2.6 which is fairly new, but don't want to update to the
> latest libtool for whatever reason.

Yes.  Typically, the "whatever" reason is that distributions don't
update the version of a package in a stable release.  You won't get
them to jump to 2.2.12 even if they are at 2.2.10 now.

And yes, I'm all fine with the answer being "distros, in case you need =
support, please git cherry-pick $commit" if we find out that works
reasonably well to solve this issue.  So yes, I agree with you on this.
(We might want to make a branch-2.2.X off of some of the release and
cherry-pick the patch there if that helps.)

If anybody is still using 1.5.x, let them do the backporting work.

> Also, I don't think we need try to backport the "=" support from
> libltdl-current, once we implement it, to libltdl-old.  At that point,
> it becomes a distributor question: if you ship .la files with '=', then
> you're requiring that all libltdl clients that access those particular
> .la files must link with libltdl-new.

Ah, but /usr/bin/foo which uses libltdl may want to be able to open
$HOME/local/lib/$package/module.so, no?

So distributors might be interested in fixed libltdl even if their own
libtool might not produce any =.

Of course, the answer may again be as simple as "git cherry-pick ...".

Or, then again, none of the libltdl may want to open .la files that
aren't --mode=finish'ed yet?  That could be a good zero order
approximation.

> I've tested the sysroot branch, with these four patches, as well as:
> 
> [PATCH] improve code for sysroot --mode=finish
> http://lists.gnu.org/archive/html/libtool-patches/2010-08/msg00143.html
> 
> [PATCH] Factor the sed command used to make a regex from a literal.
> http://lists.gnu.org/archive/html/libtool-patches/2010-08/msg00144.html
> 
> and the attached correction.  I tested on:

> linux native:
> =
> old: All 106 tests passed (*)
> new: 102 tests behaved as expected. 18 tests were skipped.
> 
> (*) I don't have fortran installed. It's not clear why the fc and f77
> tests aren't shown as 'skipped'.

Can you rerun only those tests with
  make check-local TESTSUITEFLAGS='-k FC -k F77 -v -d -x'

and post output?

> Here is the patch I found necessary:
> 
> 2010-08-15  Charles Wilson  <...>
> 
>   * libltdl/config/ltmain.m4sh (func_mode_finish): Fix logic
>   bug in $opt_dry_run test.

See comments below.

*snip*
> One those are addressed, I think this series would be ready for the
> sysroot branch.  After that, all we have left are: backport patch for
> old libtool+'=' in .la files (discussed above), and support in (new)
> libltdl for '=' in .la files, and we'll be ready to merge to master. I
> think.

I agree with your description of the current state, except that I
haven't re-read all past threads now (will do right before merge),
and except for the issue exposed on AIX which is a real regression,
independent of other bugs found so far, and requires fixing.

> diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
> index 8fc7a35..06dcdf6 100644
> --- a/libltdl/config/ltmain.m4sh
> +++ b/libltdl/config/ltmain.m4sh
> @@ -1427,7 +1427,11 @@ func_mode_finish ()
>fi
>  
># Remove sysroot references
> -  if $opt_dry_run; then
> +  if ${opt_dry_run-false}; then

I don't get it.  opt_dry_run is initialized unconditionally early in the
libtool script, from general.m4sh, and never unset.  What's the reason
for ${...-default}?

Other than that, the logic fix is obviously good, thanks!
(And I overlooked that in Paolo's patch, too)
You might want to fold this right in.

> +for lib in $libs; do
> +  echo "removing references to $lt_sysroot and \`=' prefixes from 
> $lib"
> +done
> +  else
>  tmpdir=`func_mktempdir`
[...]

Cheers,
Ralf

Re: [PATCH v2 0/3] sysroot followup patches

[Ralf Wildenhues]

* Charles Wilson wrote on Mon, Aug 16, 2010 at 10:27:46PM CEST:
> Taking all of this together, I wonder if a good approach might be the
> following: libltdl replaces the '=' with the value of the environment
> variable LIBLTDL_SYSROOT.  So usually -- with this variable empty -- '='
> is just stripped out, which would be typical on the $host system. This
> would open up possible exploits -- but if you --finish your .la files,
> then there ARE no '=' markers to replace, so you'd be safe.

Sounds good.  Make that LTDL_SYSROOT please, though, similar to the
other variables it uses.

> >> (*) I don't have fortran installed. It's not clear why the fc and f77
> >> tests aren't shown as 'skipped'.
> > 
> > Can you rerun only those tests with
> >   make check-local TESTSUITEFLAGS='-k FC -k F77 -v -d -x'
> 
> Err, sure, but the NEW testsuite did report the correct "skippage":

> It's just that the OLD testsuite didn't even mention the F77/FC tests:

Oh, sorry for the mis-parse.  Can you run
  VERBOSE=yes $srcdir/tests/fcdemo-conf.test; echo $?

and post the output of that?  VERBOSE=debug is even more informative, if
that is necessary.  Thanks.

> >> -  if $opt_dry_run; then
> >> +  if ${opt_dry_run-false}; then
> > 
> > I don't get it.  opt_dry_run is initialized unconditionally early in the
> > libtool script, from general.m4sh, and never unset.  What's the reason
> > for ${...-default}?
> 
> I was just copying the pattern I saw elsewhere. If it's safe to proceed
> without the default, then that's fine too.

Yep it should be.

Cheers,
Ralf

Re: [PATCH v2 0/3] sysroot followup patches

[Ralf Wildenhues]

* Charles Wilson wrote on Mon, Aug 16, 2010 at 10:50:21PM CEST:
> On 8/16/2010 4:42 PM, Ralf Wildenhues wrote:
> > 
> >   Can you run
> >   VERBOSE=yes $srcdir/tests/fcdemo-conf.test; echo $?
> > 
> > and post the output of that?  VERBOSE=debug is even more informative, if
> > that is necessary.  Thanks.
> 
> Attached.

Thanks.  The test exits 1:

[...]
| -rw-r--r-- 1 cwilson cwilson   2071 Aug 15 19:29 config-h.in
| -rw-r--r-- 1 cwilson cwilson  27264 Aug 15 19:29 Makefile.in
| 1

That should show up as FAIL in the output.  I have no idea why that
happens.

Which Automake version do you use?  I'm not aware of any problems with
the TESTS driver of it, and I've run its testsuite on Cygwin not too
long ago too.

Cheers,
Ralf

Re: [RFT PATCH v4 3/8] teach libtool -L= and -R=

[Ralf Wildenhues]

* Paolo Bonzini wrote on Sun, Aug 01, 2010 at 04:47:29PM CEST:
> * libltdl/config/ltmain.m4sh (func_resolve_sysroot): New.
> (func_mode_link): Always pass result of stripping -L and -R to
> func_resolve_sysroot before using it.  Remove absolute path expansion
> when func_resolve_sysroot subsumes it.  Expand sysroot in -rpath.
> When processing dependent libraries also resolve sysroot paths there.

> --- a/libltdl/config/ltmain.m4sh
> +++ b/libltdl/config/ltmain.m4sh
> @@ -544,6 +544,36 @@ func_source ()
>  }
>  
>  
> +# func_resolve_sysroot PATH
> +# Change PATH to an absolute path or replace a leading = with a
> +# sysroot.  Store the result into func_resolve_sysroot_result
> +func_resolve_sysroot ()
> +{
> +  func_resolve_sysroot_result=$1
> +  case $func_resolve_sysroot_result in
> +  [\\/]* | [A-Za-z]:[\\/]*) ;;
> +  =*)
> +func_stripname '=' '' "$func_resolve_sysroot_result"
> +func_resolve_sysroot_result=$lt_sysroot$func_stripname_result
> +;;
> +  *)
> +if test -d "$1"; then
> +  absdir=`cd "$1" && pwd`
> +  test -z "$absdir" && \
> +func_fatal_error "cannot determine absolute directory name of 
> \`$dir'"
> +  func_resolve_sysroot_result=`cd "$dir" && pwd`
> +else
> +  func_dirname_and_basename "$1" "" "."
> +  absdir=`cd "$func_dirname_result" && pwd`
> +  test -z "$absdir" && \
> +func_fatal_error "cannot determine absolute directory name of 
> \`$func_dirname_result'"
> +  func_resolve_sysroot_result="$absdir/$func_basename_result"
> +fi
> +;;
> +  esac
> +}

Why does this function absolutize paths that have nothing to do with
sysroot, even in-tree deplib paths?
Is there a deeper reason in this?  If yes, there should probably be a
test which is fixed by it.

Asking because inserting
  func_resolve_sysroot_result=$1
  return

in the '*)' case makes the test pass on AIX.


The callers previously did this in only one place (and checked for it to
be true in one other place), namely here:

> @@ -4340,29 +4370,26 @@ func_mode_link ()
>   ;;
>  
>-L*)
> - func_stripname '-L' '' "$arg"
> - dir=$func_stripname_result
> - if test -z "$dir"; then
> + func_stripname "-L" '' "$arg"
> + if test -z "$func_stripname_result"; then
> if test "$#" -gt 0; then
>   func_fatal_error "require no space between \`-L' and \`$1'"
> else
>   func_fatal_error "need path for \`-L' option"
> fi
>   fi
> - # We need an absolute path.
> - case $dir in
> - [\\/]* | [A-Za-z]:[\\/]*) ;;
> - *)
> -   absdir=`cd "$dir" && pwd`
> -   test -z "$absdir" && \
> - func_fatal_error "cannot determine absolute directory name of 
> \`$dir'"
> -   dir="$absdir"
> -   ;;
> - esac
> + func_resolve_sysroot "$func_stripname_result"
> + dir=$func_resolve_sysroot_result
>   case "$deplibs " in
> - *" -L$dir "*) ;;
> + *" -L$dir "* | *" $arg "*)
> +   # Will only happen for absolute or sysroot arguments
> +   ;;
>   *)
> -   func_append deplibs " -L$dir"
> +   # Preserve sysroot, but never include relative directories
> +   case $dir in
> + [\\/]* | [A-Za-z]:[\\/]* | =*) func_append deplibs " $arg" ;;
> + *) func_append deplibs " -L$dir" ;;
> +   esac
> func_append lib_search_path " $dir"
> ;;
>   esac

and here:

> @@ -4514,6 +4541,10 @@ func_mode_link ()
>   # We need an absolute path.
>   case $dir in
>   [\\/]* | [A-Za-z]:[\\/]*) ;;
> + =*)
> +   func_stripname '=' '' "$dir"
> +   dir=$lt_sysroot$func_stripname_result
> +   ;;
>   *)
> func_fatal_error "only absolute run-paths are allowed"
> ;;
> @@ -5042,7 +5073,8 @@ func_mode_link ()
>   test "$pass" = conv && continue
>   newdependency_libs="$deplib $newdependency_libs"
>   func_stripname '-L' '' "$deplib"
> - func_append newlib_search_path " $func_stripname_result"
> + func_resolve_sysroot "$func_stripname_result"
> + func_append newlib_search_path " $func_resolve_sysroot_result"
>   ;;
> prog)
>   if test "$pass" = conv; then
> @@ -5056,7 +5088,8 @@ func_mode_link ()
> finalize_deplibs="$deplib $finalize_deplibs"
>   fi
>   func_stripname '-L' '' "$deplib"
> - func_append newlib_search_path " $func_stripname_result"
> + func_resolve_sysroot "$func_stripname_result"
> + func_append newlib_search_path " $func_resolve_sysroot_result"
>   ;;
> *)
>   func_warning "\`-L' is ignored for archives/objects"
> @@ -5067,7 +5100,8 @@ func_mode_link ()
>   -R*)
> if test "$pass" = link; then
>   func_stripname '-R' '' "$deplib"
> - dir=$func_stripname_result
> + func_resolve_sysroot "$func_stripname_result"
> + dir=$func_resolve_sysroot_result
>   # Make sure the xrpath contains only uniq

Re: [RFT PATCH v4 3/8] teach libtool -L= and -R=

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Thu, Aug 19, 2010 at 06:58:31AM CEST:
> * Paolo Bonzini wrote on Sun, Aug 01, 2010 at 04:47:29PM CEST:
> > +# func_resolve_sysroot PATH
> > +# Change PATH to an absolute path or replace a leading = with a
> > +# sysroot.  Store the result into func_resolve_sysroot_result
> > +func_resolve_sysroot ()
> > +{
> > +  func_resolve_sysroot_result=$1
> > +  case $func_resolve_sysroot_result in
> > +  [\\/]* | [A-Za-z]:[\\/]*) ;;
> > +  =*)
> > +func_stripname '=' '' "$func_resolve_sysroot_result"
> > +func_resolve_sysroot_result=$lt_sysroot$func_stripname_result
> > +;;
> > +  *)
> > +if test -d "$1"; then
> > +  absdir=`cd "$1" && pwd`
> > +  test -z "$absdir" && \
> > +func_fatal_error "cannot determine absolute directory name of 
> > \`$dir'"
> > +  func_resolve_sysroot_result=`cd "$dir" && pwd`
> > +else
> > +  func_dirname_and_basename "$1" "" "."
> > +  absdir=`cd "$func_dirname_result" && pwd`
> > +  test -z "$absdir" && \
> > +func_fatal_error "cannot determine absolute directory name of 
> > \`$func_dirname_result'"
> > +  func_resolve_sysroot_result="$absdir/$func_basename_result"
> > +fi
> > +;;
> > +  esac
> > +}
> 
> Why does this function absolutize paths that have nothing to do with
> sysroot, even in-tree deplib paths?

Also, has this been tried with relative paths pointing to nonexistent
directories?  We cannot afford to fail at '-L../optional-package/lib'.

Thanks,
Ralf

[PATCH] Do not absolutize paths eagerly.

[Ralf Wildenhues]

* libltdl/config/ltmain.m4sh (func_resolve_sysroot): Partly
revert v2.2.10-83-gc45a288: Do not absolutize path here, only do
sysroot replacement.
(func_mode_link): Adjust.
Fixes AIX testsuite regression.
---

* Paolo Bonzini wrote on Thu, Aug 19, 2010 at 09:40:11AM CEST:
> On 08/19/2010 06:58 AM, Ralf Wildenhues wrote:
> >Why does this function absolutize paths that have nothing to do with
> >sysroot, even in-tree deplib paths?
> >Is there a deeper reason in this?  If yes, there should probably be a
> >test which is fixed by it.
> 
> It's a bug, I think I did it to simplify other places but this was
> wrong as the AIX case shows.  I had the same idea more or less, but
> I didn't have time to make a patch.

Maybe it's as simple as this?  I'm testing this patch now.  Would be
nice if somebody could test it on a sysroot-enabled setup (i.e., where
the sysroot tests don't skip).

I agree that the absolutization issue should probably cleaned up,
but independently of the sysroot feature, and it likely needs a bit
more testsuite exposure, too.

Thanks,
Ralf

 libltdl/config/ltmain.m4sh |   29 -
 1 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index d29fd5d..a3e8955 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -547,31 +547,16 @@ func_source ()
 
 
 # func_resolve_sysroot PATH
-# Change PATH to an absolute path or replace a leading = with a
-# sysroot.  Store the result into func_resolve_sysroot_result
+# Replace a leading = in PATH with a sysroot.  Store the result into
+# func_resolve_sysroot_result
 func_resolve_sysroot ()
 {
   func_resolve_sysroot_result=$1
   case $func_resolve_sysroot_result in
-  [\\/]* | [A-Za-z]:[\\/]*) ;;
   =*)
 func_stripname '=' '' "$func_resolve_sysroot_result"
 func_resolve_sysroot_result=$lt_sysroot$func_stripname_result
 ;;
-  *)
-if test -d "$1"; then
-  absdir=`cd "$1" && pwd`
-  test -z "$absdir" && \
-func_fatal_error "cannot determine absolute directory name of \`$dir'"
-  func_resolve_sysroot_result=`cd "$dir" && pwd`
-else
-  func_dirname_and_basename "$1" "" "."
-  absdir=`cd "$func_dirname_result" && pwd`
-  test -z "$absdir" && \
-func_fatal_error "cannot determine absolute directory name of 
\`$func_dirname_result'"
-  func_resolve_sysroot_result="$absdir/$func_basename_result"
-fi
-;;
   esac
 }
 
@@ -4440,6 +4425,16 @@ func_mode_link ()
fi
func_resolve_sysroot "$func_stripname_result"
dir=$func_resolve_sysroot_result
+   # We need an absolute path.
+   case $dir in
+   [\\/]* | [A-Za-z]:[\\/]*) ;;
+   *)
+ absdir=`cd "$dir" && pwd`
+ test -z "$absdir" && \
+   func_fatal_error "cannot determine absolute directory name of 
\`$dir'"
+ dir="$absdir"
+ ;;
+   esac
case "$deplibs " in
*" -L$dir "* | *" $arg "*)
  # Will only happen for absolute or sysroot arguments
-- 
1.7.2.rc3.47.g996ce

Don't hide the table of contents in the manual.

[Ralf Wildenhues]

This moves the ToC to the beginning in the PDF output, and IMHO looks
so much nicer.  Will push soon unless somebody complains.

Thanks Bruno!
Ralf

Don't hide the table of contents in the manual.

* doc/libtool.texi: Move the table of contents to the beginning.
Prompted by patch from Bruno Haible against Automake.

diff --git a/doc/libtool.texi b/doc/libtool.texi
index 606b232..f508015 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -70,6 +70,8 @@ the section entitled "GNU Free Documentation License".
 @syncodeindex tp cp
 @synindex pg cp
 
+...@contents
+
 @ifnottex
 @node Top, Introduction, (dir), (dir)
 @comment  node-name,  next,  previous,  up
@@ -6368,6 +6370,4 @@ order to test new changes without having to rerun 
@code{configure}.
 
 @printindex cp
 
-...@c summarycontents
-...@contents
 @bye

Remove superfluous dependency in Makefile.am.

[Ralf Wildenhues]

Pushed as obvious: there is nothing that would generate demo-conf.test
and I couldn't find any reason for the test result to depend on the
libtool script in particular.

Cheers,
Ralf

Remove superfluous dependency in Makefile.am.

* Makefile.am (tests/demo-conf.test): Remove dependency on
libtool, this test is a primary source and not generated.

diff --git a/Makefile.am b/Makefile.am
index e0bf83d..d358e09 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -690,8 +690,6 @@ if HAVE_FC
 TESTS += $(FC_TESTS)
 endif
 
-tests/demo-conf.test: libtool
-
 EXTRA_DIST += $(srcdir)/tests/defs.in tests/defs.m4sh \
  $(COMMON_TESTS) $(CXX_TESTS) $(F77_TESTS) $(FC_TESTS)
 DIST_SUBDIRS   += $(CONF_SUBDIRS)

Bump copyright years in manual.

[Ralf Wildenhues]

Pushed as obvious.

Bump copyright years in manual.

* doc/libtool.texi: Bump copyright years.

diff --git a/doc/libtool.texi b/doc/libtool.texi
index f508015..d0eaec4 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -26,7 +26,7 @@
 @ifnottex
 This file documents GNU Libtool @value{VERSION}
 
-Copyright (C) 1996-2009 Free Software Foundation, Inc.
+Copyright (C) 1996-2010 Free Software Foundation, Inc.
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3
@@ -53,7 +53,7 @@ identical to this one except for the removal of this paragraph
 
 @page
 @vskip 0pt plus 1filll
-Copyright @copyright{} 2009 Free Software Foundation, Inc.
+Copyright @copyright{} 2010 Free Software Foundation, Inc.
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3
@@ -6345,7 +6345,7 @@ trick$ chmod +x libtool
 trick$ libtool --version
 ltmain.sh (GNU @@PACKAGETIMESTAMP@@) @@VERSION@@
 
-Copyright (C) 2009 Free Software Foundation, Inc.
+Copyright (C) 2010 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 trick$

using git Libtool with Autoconf 2.59, Automake 1.9.6

[Ralf Wildenhues]

I tried running the Libtool test suites with old Autoconf 2.59 and
Automake 1.9.6 (on GNU/Linux only) after 'autoreconf -fvi'-ing all
but the toplevel directory with those tools.  I was surprised to see
that it still works more or less!  :-)

This patch fixes the fall-out.  OK to push if the use of $at_status is
sanctioned?


Thanks,
Ralf

Fix getopt tests to skip with Autoconf < 2.61.

* tests/getopt-m4sh.at (_LT_AT_GETOPT_M4SH_SETUP): Skip the test
of 'autom4te --language=m4sh' exits 63 because version 2.61 is
required.  Allows the testsuite to complete successfully with
Autoconf 2.59 and Automake 1.9.6.

diff --git a/tests/getopt-m4sh.at b/tests/getopt-m4sh.at
index 3e58db1..d2df827 100644
--- a/tests/getopt-m4sh.at
+++ b/tests/getopt-m4sh.at
@@ -48,12 +48,9 @@ M4SH_GETOPTS(
 ]])
 m4_pattern_forbid([m4_include])
 m4_pattern_forbid([AS_INIT])
-
-$M4SH -B $abs_top_srcdir/libltdl/config options.m4sh \
-| $SED \
-   -e "s,@LN_S\@,$LN_S,g" \
-   -e "s,@SED\@,$SED,g" \
-> options
+AT_CHECK([$M4SH -B $abs_top_srcdir/libltdl/config options.m4sh > t-options],
+[], [], [], [AT_CHECK([test $at_status -eq 63 && exit 77])])
+$SED "s,@LN_S\@,$LN_S,g;s,@SED\@,$SED,g" t-options > options
 ])# _LT_AT_GETOPT_M4SH_SETUP
 
 

Re: [PATCH] Do not absolutize paths eagerly.

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Fri, Aug 20, 2010 at 06:34:58AM CEST:
> * libltdl/config/ltmain.m4sh (func_resolve_sysroot): Partly
> revert v2.2.10-83-gc45a288: Do not absolutize path here, only do
> sysroot replacement.
> (func_mode_link): Adjust.
> Fixes AIX testsuite regression.

> Maybe it's as simple as this?  I'm testing this patch now.  Would be
> nice if somebody could test it on a sysroot-enabled setup (i.e., where
> the sysroot tests don't skip).

Fixed the regression as expected, didn't show up any other failures.
OK to apply to the sysroot branch?
I still need somebody to test a sysroot-enabled setup with this.

Thanks!
Ralf

Re: versioning test on AIX

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Sat, Aug 07, 2010 at 12:30:01AM CEST:
> The test tries to ensure that with an incompatible library upgrade,
> programs previously linked against the old library still work.  This
> usually works on systems where different major versions of a library
> have different file names.  Which isn't the case for AIX without
> runtimelinking (liba.a is the same name whether it contains liba.so.2
> or liba.so.0):
[...]

> Now, the part that really surprised me was that this doesn't even work
> with runtimelinking (configure LDFLAGS=-Wl,-brtl), even though the file
> names aren't the issue here:
[...]

> So, while I'm not completely sure yet that there isn't another bug
> lurking in libtool here, it seems that this is another AIX limitation.
> 
> One way out may be to use loader domains; see here for a description:
> <http://stromberg.dnsalias.org/~strombrg/AIX-shared-libs.html>
> 
> I don't really see how to apply this concept in general, i.e., without
> user intervention.  So, for now I propose the patch below to skip this
> part of the part; I will leave time for comments before pushing it.

No comments, so I'm pushing this patch.

Also pushing the trivial cleanup patch below.

Cheers,
Ralf

> Skip part of versioning test on AIX.
> 
> * tests/versioning.at (versioning): The AIX linker always
> records the unversioned library name, even with runtimelinking,
> so skip the execution test for the incompatibly upgraded
> library.
> Report by Rainer Tammer.
> 
> diff --git a/tests/versioning.at b/tests/versioning.at
> index eef7c4a..1d75f62 100644
> --- a/tests/versioning.at
> +++ b/tests/versioning.at

> @@ -227,6 +227,11 @@ AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o 
> liba.la liba4.lo ]dnl
>  # available, so test_uninstalled will not necessarily work here any more.
>  AT_CHECK([$LIBTOOL --mode=install cp liba.la $libdir], [], [ignore], 
> [ignore])
>  AT_CHECK([$LIBTOOL --mode=clean rm -f liba.la], [], [ignore], [ignore])
> +
> +# This test does not work on AIX, not even with runtimelinking, because
> +# the linker always records the unversioned name as dependency.
> +AT_CHECK([:; case $host_os in aix*) exit 77;; esac])
> +
>  test_installed


Remove dead code from versioning test.

* tests/versioning.at (versioning): No need to build unused
prog3.

diff --git a/tests/versioning.at b/tests/versioning.at
index 69bf731..eef7c4a 100644
--- a/tests/versioning.at
+++ b/tests/versioning.at
@@ -91,14 +91,6 @@ int main (void)
 }
 ]])
 
-AT_DATA([prog3.c], [[
-extern int a (void), internal_detail;
-int main (void)
-{
-  return a () + internal_detail - 42;
-}
-]])
-
 
 inst=`pwd`/inst
 libdir=$inst/lib
@@ -109,7 +101,7 @@ mkdir $inst $libdir $bindir
 for file in liba1.c liba2.c liba3.c liba4.c libb.c; do
   $LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c $file
 done
-for file in prog1.c prog2.c prog3.c; do
+for file in prog1.c prog2.c; do
   $CC $CPPFLAGS $CFLAGS -c $file
 done
 

Re: libtool-2.2.11a on AIX 5.3 current git master / followup on the old test suite and failures in the new testsuit

[Ralf Wildenhues]

* Rainer Tammer wrote on Sat, Aug 07, 2010 at 09:35:56AM CEST:
> I have added one additional patch (as I did for the last run):
> 
> # diff /daten/source/libtool-2.2.11a/tests/defs.in defs.in
[...]
> < # On AIX, shared libraries remain loaded in memory after use if they
> < # are world-readable, until root issues slibclean.  On NFS, this causes
> < # a testsuite rerun to fail to clean up test group directories.  Avoid
> < # this with a suitable umask.  Do not do this on other systems, for
> < # example HP-UX suffers unless shared libraries are mode 555.
> < case $host_os in
> < aix*) umask o-rwx ;;
> < esac

I have pushed your patch now, as below.

> Now I get some new errors from the old test suite:
> 
> # grep FAIL check.log
> FAIL: tests/f77demo-exec.test
> FAIL: tests/f77demo-exec.test
> FAIL: tests/fcdemo-exec.test
> FAIL: tests/fcdemo-exec.test
> ...
> 
> This is because the LIBPATH is not OK:

This has been fixed since in git Libtool.

Cheers, and thanks again,
Ralf

2010-08-21  Rainer Tammer   (tiny change)

Avoid issues with AIX resident shared libraries in old testsuite.
* tests/defs.m4sh [aix]: Remove file mode permission for others,
so shared libraries are not kept in memory after execution.
Fixes failures of repeated mdemo-inst.test with on AIX 5.3.

diff --git a/tests/defs.m4sh b/tests/defs.m4sh
index 1230555..183783e 100644
--- a/tests/defs.m4sh
+++ b/tests/defs.m4sh
@@ -130,6 +130,7 @@ func_get_config "objext
 objdir
 CC
 host
+host_os
 host_alias
 build
 build_alias" "$LIBTOOL --config" ": fatal"
@@ -351,6 +352,15 @@ m4dir=$srcdir/libltdl/m4
 auxdir=$srcdir/libltdl/config
 scripts="$auxdir/ltmain.m4sh $srcdir/libtoolize.m4sh"
 
+# On AIX, shared libraries remain loaded in memory after use if they
+# are world-readable, until root issues slibclean.  On NFS, this causes
+# a testsuite rerun to fail to clean up test group directories.  Avoid
+# this with a suitable umask.  Do not do this on other systems, for
+# example HP-UX suffers unless shared libraries are mode 555.
+case $host_os in
+aix*) umask o-rwx ;;
+esac
+
 func_msg "Running $progname"
 
 # Local Variables: