This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch to update libtool in GCC and binutils trees


* Charles Wilson wrote on Fri, Mar 30, 2007 at 05:55:23AM CEST:
> This:
> 
> >	if ${CONFIG_SHELL-/bin/sh} ./libtool --tag CXX --features |
[...]
> isn't the correct mechanism, anymore.  From the new libtool's .info:
> 
> ===========================================
>    With 1.3 era libtool, if you wanted to know any details of what
> libtool had discovered about your architecture and environment, you had
> to run the script with `--config' and grep through the results.  This
> idiom was supported up to and including 1.5.x era libtool, where it was
> possible to call the generated libtool script from `configure.ac' as
> soon as `LT_INIT' had completed.  However, one of the features of
> libtool 1.4 was that the libtool configuration was migrated out of a
> separate `ltconfig' file, and added to the `LT_INIT' macro (nee
> `AC_PROG_LIBTOOL'), so the results of the configuration tests were
> available directly to code in `configure.ac', rendering the call out to
> the generated libtool script obsolete.
> 
>    Starting with libtool 2.0, the multipass generation of the libtool
> script has been consolidated into a single `config.status' pass, which
> happens after all the code in `configure.ac' has completed.  The
> implication of this is that the libtool script does not exist during
> execution of code from `configure.ac', and so obviously it cannot be
> called for `--config' details anymore.  If you are upgrading projects
> that used this idiom to libtool 2.0 or newer, you should replace those
> calls with direct references to the equivalent Autoconf shell variables
> that are set by the configure time tests before being passed to
> `config.status' for inclusion in the generated libtool script.

This is only half of the truth; you can still use the generated libtool
script, but then you have to ensure that it is generated earlier.
Quoting the paragraph following the one you quoted:

|  -- Macro: LT_OUTPUT
|      By default, the configured `libtool' script is generated by the
|      call to `AC_OUTPUT' command, and there is rarely any need to use
|      `libtool' from `configure'.  However, sometimes it is necessary to
|      run configure time compile and link tests using `libtool'.  You
|      can add `LT_OUTPUT' to your `configure.ac' any time after
|      `LT_INIT' and any `LT_LANG' calls; that done, `libtool' will be
|      created by a specially generated `config.lt' file, and available
|      for use in later tests.
| 
|      Also, when `LT_OUTPUT' is used, for backwards compatibility with
|      Automake regeneration rules, `config.status' will call `config.lt'
|      to regenerate `libtool', rather than generating the file itself.


Of course, your suggestion:

> So, short version: the code above should be replaced with [untested]:
> 
> 	LIBSUPCXX_PICFLAGS=
> 	test "$enable_shared" = yes && LIBSUPCXX_PICFLAGS=-prefer-pic

is still good, and IMVHO the right thing to do here.

Hope that helps.

Cheers,
Ralf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]