Re: Using libtool 2.0 in autoconf tests

[Sander Niemeijer]

The theory:
It is my belief that an actual link should not be necessary to test
for some characteristic.  Libtool runs a whole lot of autoconf tests
at configure time to decide how it is going to link when the results
of those tests are added to the generated libtool script.  
Consequently,
you should be able to work out how the generated libtool script will
behave under any circumstance by examining the results of the configure
time tests that LT_INIT (and maybe LT_WITH_LTDL) have made available to
you at link time.

There are still a small number of host dependent decision that are made
by the code in ltmain.sh, and it is possible that you need to know what
decision will be made in that case.  In order for this to work, we need
to parameterize any such decisions at configure time, and change 
ltmain.sh to use the new parameter rather that a hardcoded $host_os
decision.  We need to consider any occurences of these that turn up to
be priority bugs.

The practice:
If you think about what it is you need to know in these terms, you
should be able to figure out what libtool will do by looking at the
results of the LT_INIT configure time tests.  If you can't, then try
to express your problem in those terms on this list, and we will be
able to figure it out for you -- and maybe make a new macro that rolls
that condition case up to help make it easier to figure out next time;
and maybe notice that there is something in ltmain.sh that needs to be
parameterised to make it possible.  It might be worth adding some notes
about this to libtool.texi, where we can later collect additional notes
that walk through some examples to help future users get into the right
mindset.
I hope it is clear that I only want to perform a test that checks 
whether a certain library is available and whether it is possible to 
link this library against another shared library (which means it should 
be a shared library itself). Now, of course, in theory I could write 
such a test without performing an actual link or without making use of 
libtool. This, however, would mean I would have to add a _lot_ of 
knowledge to my test in order to have it work on many platforms with 
many compilers/linkers. Knowledge which is usually already available in 
the linker (i.e. just trying to link will usually tell you whether it 
works or not) and/or the libtool script. Not even considering the 
practical points here, even from a theoretical standpoint duplicating 
knowledge is _not_ a good idea.

Now suppose I would use the knowledge provided by libtool are you then 
suggesting that libtool should have _two_ interfaces that I should use? 
One for use from makefiles (i.e. the libtool script) and one to use 
from the configure script (some undocumented combination of lt_ 
variables and ltmain.sh)? If this is it, then so be it and I will try 
to rewrite my autoconf test to use the lt_/ltmain.sh combination for 
libtool 2.0,
but libtool 2.0 surely won't get my vote for the 
best-design-of-the-year-award.

An aside:
As we rewrite the testsuite on HEAD, I want to change as many of the
tests as possible to use this paradigm instead of  configuring an
entire mini-project to test that some aspect of linking is working.
We need some of these slow tests too; but the current testsuite is
very slow because of the number of unneccessary project bootstraps
it has to run.  Fixing this will also affect the libtool distcheck
time dramatically in more than the obvious sense, because we won't
need to bootstrap all of these directories with aclocal, autoconf
and automake.
I can perfectly understand why you want to take this approach for 
libtool tests and I think it is a good idea. But IMHO the libtool 
configure script variables and the ltmain.sh script should not be part 
of the interface that is presented to the end-user of libtool. Users 
should only have to be confronted with the libtool script. Just give us 
_one_ consistent interface please.

Best regards,
Sander

___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool 2.0 in autoconf tests

[Ralf Wildenhues]

* Sander Niemeijer wrote on Mon, Nov 22, 2004 at 11:00:13AM CET:
 
 The practice:
 
 If you think about what it is you need to know in these terms, you
 should be able to figure out what libtool will do by looking at the
 results of the LT_INIT configure time tests.  If you can't, then try
 to express your problem in those terms on this list, and we will be
 able to figure it out for you -- and maybe make a new macro that rolls
 that condition case up to help make it easier to figure out next time;
 and maybe notice that there is something in ltmain.sh that needs to be
 parameterised to make it possible.  It might be worth adding some notes
 about this to libtool.texi, where we can later collect additional notes
 that walk through some examples to help future users get into the right
 mindset.
 
 I hope it is clear that I only want to perform a test that checks 
 whether a certain library is available and whether it is possible to 
 link this library against another shared library (which means it should 
 be a shared library itself). Now, of course, in theory I could write 
 such a test without performing an actual link or without making use of 
 libtool. This, however, would mean I would have to add a _lot_ of 
 knowledge to my test in order to have it work on many platforms with 
 many compilers/linkers. Knowledge which is usually already available in 
 the linker (i.e. just trying to link will usually tell you whether it 
 works or not) and/or the libtool script. Not even considering the 
 practical points here, even from a theoretical standpoint duplicating 
 knowledge is _not_ a good idea.
 
 Now suppose I would use the knowledge provided by libtool are you then 
 suggesting that libtool should have _two_ interfaces that I should use? 
 One for use from makefiles (i.e. the libtool script) and one to use 
 from the configure script (some undocumented combination of lt_ 
 variables and ltmain.sh)? If this is it, then so be it and I will try 
 to rewrite my autoconf test to use the lt_/ltmain.sh combination for 
 libtool 2.0,
 but libtool 2.0 surely won't get my vote for the 
 best-design-of-the-year-award.

C'mon Gary, two questions: is it *possible* to provide the old behavior
without too much pain?  Would that destroy some cool abstraction or some
really fundamental thing?

Or are you just waiting for a patch to do this?  (ok, that was three
questions now).

Sander, please don't start implementing such a thing *yet*.  I don't
think going this route is a good idea, but at least I think you should
wait until we are through with it.

Regards,
Ralf


___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool 2.0 in autoconf tests

[Peter O'Gorman]

Ralf Wildenhues wrote:
C'mon Gary, two questions: is it *possible* to provide the old behavior
without too much pain?  Would that destroy some cool abstraction or some
really fundamental thing?
Or are you just waiting for a patch to do this?  (ok, that was three
questions now).
I would approve a patch which added LT_TRY_LINK or some such macro, and 
created a temporary configure time libtool script to do so. I think it would 
be a fairly hefty patch though. There is certainly enough information 
available to allow this as soon as the LT_INIT macro is complete, though 
there will be issues with quoting, as things are quoted one extra time 
because of the intervening config.status.

The issue is a real one, and should be addressed. I am not convinced that it 
need be addressed for libtool-2.0 though, nor that it requires reverting to 
libtool-1.5 behavior.

Peter
--
Peter O'Gorman - http://www.pogma.com
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool 2.0 in autoconf tests

[Sander Niemeijer]

On maandag, nov 22, 2004, at 12:05 Europe/Amsterdam, Peter O'Gorman 
wrote:

Ralf Wildenhues wrote:
C'mon Gary, two questions: is it *possible* to provide the old 
behavior
without too much pain?  Would that destroy some cool abstraction or 
some
really fundamental thing?
Or are you just waiting for a patch to do this?  (ok, that was three
questions now).
I would approve a patch which added LT_TRY_LINK or some such macro, 
and created a temporary configure time libtool script to do so. I 
think it would be a fairly hefty patch though. There is certainly 
enough information available to allow this as soon as the LT_INIT 
macro is complete, though there will be issues with quoting, as things 
are quoted one extra time because of the intervening config.status.
If such a macro ever gets created it is essential that it is possible 
to chose the kind of target one wants to link (i.e. program, library 
(static/shared) or module). The whole reason why I had to step away 
from the autoconf AC_CHECK_LIB macro is because I needed to create a 
shared library instead of a program (otherwise, my libtool 1.5.x 
solution would just have been to replace CC and LD temporarily with the 
appropriate libtool commands and call AC_CHECK_LIB).

The issue is a real one, and should be addressed. I am not convinced 
that it need be addressed for libtool-2.0 though, nor that it requires 
reverting to libtool-1.5 behavior.
Don't tell me you are saying that I won't be able to use libtool 2.0 
unless I create such a LT_TRY_LINK myself (or follow the lt_ 
variables/ltmain.sh approach). This rather shatters the hope that Ralf 
was trying to give me.

Best regards,
Sander

___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Convincing Automake to support libtool

[Ralf Wildenhues]

* Alexandre Duret-Lutz wrote on Sun, Nov 21, 2004 at 07:20:01PM CET:
  Bob == Bob Friesenhahn [EMAIL PROTECTED] writes:
 
  Bob What I have now learned the hard way is that aclocal ignores the
  Bob AC_CONFIG_MACRO_DIR([m4]) definition in configure.ac.
 
 IMHO it's a bug in whatever let you think aclocal would honor
 AC_CONFIG_MACRO_DIR to way you thought.  It certainly isn't the
 Automake manual.
 
 See also
   http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00097.html

Gary, can we revert libtool--release--2.0--patch-67 or fix it?
This is a major pain for people when testing branch-2-0.

Regards,
Ralf


___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Convincing Automake to support libtool

[Gary V. Vaughan]

Hi Ralf,

Ralf Wildenhues wrote:
 * Alexandre Duret-Lutz wrote on Sun, Nov 21, 2004 at 07:20:01PM CET:
 
Bob == Bob Friesenhahn [EMAIL PROTECTED] writes:

 Bob What I have now learned the hard way is that aclocal ignores the
 Bob AC_CONFIG_MACRO_DIR([m4]) definition in configure.ac.

IMHO it's a bug in whatever let you think aclocal would honor
AC_CONFIG_MACRO_DIR to way you thought.  It certainly isn't the
Automake manual.

See also
  http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00097.html
 
 
 Gary, can we revert libtool--release--2.0--patch-67 or fix it?
 This is a major pain for people when testing branch-2-0.

The automake-1.4 compatibility patch?  Why, what is wrong with it?

Cheers,
Gary.
-- 
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook


signature.asc
Description: OpenPGP digital signature
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool 2.0 in autoconf tests

[Gary V. Vaughan]

Hallo Ralf,

Ralf Wildenhues wrote:
 C'mon Gary, two questions: is it *possible* to provide the old behavior
 without too much pain?

I can't think of a way to do it cleanly :-(  But I have no objections in
principle.  How much machinery is there to make the config.status parts
of AC_OUTPUT work?  Maybe we can create an _LT_OUTPUT macro to generate
libtool at the end of LT_CONFIG?

 Would that destroy some cool abstraction or some
 really fundamental thing?

It means that we no longer have to run configure twice, and cleans up the
the LT_INIT (nee AC_PROG_LIBTOOL) code path immensely.  I really don't
want to go back to the old way of doing things... it was a mess.  However,
there are certainly advantages to being able to call libtool from within
configure.

 Or are you just waiting for a patch to do this?  (ok, that was three
 questions now).

I was hoping that we would be able to factor the common lt_* variable
tests into new LT_* macros for people to use.

 Sander, please don't start implementing such a thing *yet*.  I don't
 think going this route is a good idea, but at least I think you should
 wait until we are through with it.

Seconded.

Sander, if you want to check whether a particular library is shared,
we should be able to write a macro for you to figure that out without
actually needing to roll and run an entire libtool script.  Or is
there more to your problem than that?

Cheers,
Gary.
-- 
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook


signature.asc
Description: OpenPGP digital signature
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Convincing Automake to support libtool

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Mon, Nov 22, 2004 at 03:19:13PM CET:
 Ralf Wildenhues wrote:
  * Alexandre Duret-Lutz wrote on Sun, Nov 21, 2004 at 07:20:01PM CET:
 Bob == Bob Friesenhahn [EMAIL PROTECTED] writes:
 
  Bob What I have now learned the hard way is that aclocal ignores the
  Bob AC_CONFIG_MACRO_DIR([m4]) definition in configure.ac.
 
 IMHO it's a bug in whatever let you think aclocal would honor
 AC_CONFIG_MACRO_DIR to way you thought.  It certainly isn't the
 Automake manual.
 
 See also
   http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00097.html
  
  
  Gary, can we revert libtool--release--2.0--patch-67 or fix it?
  This is a major pain for people when testing branch-2-0.
 
 The automake-1.4 compatibility patch?  Why, what is wrong with it?

Brother.  I meant libtool--release--2.0--patch-68.
Where's the coffee?

Sorry for the noise,
Ralf


___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Convincing Automake to support libtool

[Gary V. Vaughan]

Peter O'Gorman wrote:
 Ralf Wildenhues wrote:
 Brother.  I meant libtool--release--2.0--patch-68.
 Where's the coffee?
 
 
 What, I hadn't even realized that this was applied, shows how much
 attention I've been paying :(

:-)

 Me too, please revert this for now.

Okay.  It looks as though we have enough issues to sort out that
we should have another alpha before 2.0, and the parallel installs
are just adding to the confusion.  I'd quite like to leave it on
HEAD so that we can work through the problems with the patch when
we have branch-2-0 in a releasable state.  Guess we're not quite
as close to a 2.0 release as I'd hoped :-(

Yes, please revert --patch-68 from branch-2-0.

Cheers,
Gary.
-- 
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook


signature.asc
Description: OpenPGP digital signature
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool 2.0 in autoconf tests

[Kevin P. Fleming]

Gary V. Vaughan wrote:
Sander, if you want to check whether a particular library is shared,
we should be able to write a macro for you to figure that out without
actually needing to roll and run an entire libtool script.  Or is
there more to your problem than that?
There _is_ more to his problem than that; I have run into this situation 
as well.

Here's the rub: at configure time, you want to check if a particular 
library is available, and will be linkable into your project when its 
needed. This is done using AC_CHECK_LIB and checking for a particular 
function (usually an init function) to be present in the library.

What happens if the only version of the library present is libfoo.a, but 
the configure script has been passed --disable-static? AC_CHECK_LIB will 
succeed, but final linking will fail.

What happens if the .la file is in the library search path, but the 
.a/.so files are not? AC_CHECK_LIB will fail, but final linking would 
have succeeded. (I'll grant that this is an abnormal situation, but I've 
had reports of it).

What happens if the shared library being linked to has dependent 
libraries (and was installed using libtool), and you are building on a 
platform that does not automatically link in shared deplibs? 
AC_CHECK_LIB will fail, but using libtool for linking would succeed.

I can probably come up with a dozen more situations where using libtool 
for library link testing _at configure time_ is really necessary, and 
not having it makes our projects work less well than they should. Like 
Sander, I have built some home-grown autoconf macros to use libtool for 
link testing at configure time, and if libtool-2.0 will no longer 
support this activity I'll have a significant problem.

___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool 2.0 in autoconf tests

[Gary V. Vaughan]

Hi Sander,

Sander Niemeijer wrote:
 I hope it is clear that I only want to perform a test that checks
 whether a certain library is available and whether it is possible to
 link this library against another shared library (which means it should
 be a shared library itself). Now, of course, in theory I could write
 such a test without performing an actual link or without making use of
 libtool. This, however, would mean I would have to add a _lot_ of
 knowledge to my test in order to have it work on many platforms with
 many compilers/linkers. Knowledge which is usually already available in
 the linker (i.e. just trying to link will usually tell you whether it
 works or not) and/or the libtool script. Not even considering the
 practical points here, even from a theoretical standpoint duplicating
 knowledge is _not_ a good idea.

Agreed.  I think that there are a small number of circumstances where
the early-build of libtool was genuinely useful, and I think we should
be able to wrap each of those cases is a shipped macro that leverages
the knowledge already probed for libtool without needing to actually
have a libtool script present.

Most of the time people were just grepping the libtool script for the
value of some variable.  But your's is one of the few cases that needs
a whole new macro.  I'd be delighted if you want to help us write it,
but it should then be part of libtool.m4, not your package!

 Now suppose I would use the knowledge provided by libtool are you then
 suggesting that libtool should have _two_ interfaces that I should use?
 One for use from makefiles (i.e. the libtool script) and one to use from
 the configure script (some undocumented combination of lt_ variables and
 ltmain.sh)? If this is it, then so be it and I will try to rewrite my
 autoconf test to use the lt_/ltmain.sh combination for libtool 2.0,
 but libtool 2.0 surely won't get my vote for the
 best-design-of-the-year-award.

No no, I think that the post-1.5 interface is incomplete.  And with good
reports like yours, we should be able to fill in the gaps.

It may turn out that we have to figure out a new way to generate libtool
without config.status in the end, but considering the mess it got us into
before, I'd like to try to solve configure time problems by enhancing
the configure interface.

 I can perfectly understand why you want to take this approach for
 libtool tests and I think it is a good idea. But IMHO the libtool
 configure script variables and the ltmain.sh script should not be part
 of the interface that is presented to the end-user of libtool. Users
 should only have to be confronted with the libtool script. Just give us
 _one_ consistent interface please.

No, they should not, and are not.  Nor should grepping the libtool script,
or .la files be part of the user interface to Libtool.  We just need to
figure out which parts of the LT_ macro interface need opening up and
documenting.

Cheers,
Gary.
-- 
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook


signature.asc
Description: OpenPGP digital signature
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool 2.0 in autoconf tests

[Gary V. Vaughan]

Hi Kevin,

Kevin P. Fleming wrote:
 Gary V. Vaughan wrote:
 
 Sander, if you want to check whether a particular library is shared,
 we should be able to write a macro for you to figure that out without
 actually needing to roll and run an entire libtool script.  Or is
 there more to your problem than that?
 
 
 There _is_ more to his problem than that; I have run into this situation
 as well.

 [[examples of failure modes with AC_CHECK_LIB vs libtool link]]
 
 I can probably come up with a dozen more situations where using libtool
 for library link testing _at configure time_ is really necessary, and
 not having it makes our projects work less well than they should. Like
 Sander, I have built some home-grown autoconf macros to use libtool for
 link testing at configure time, and if libtool-2.0 will no longer
 support this activity I'll have a significant problem.

Sounds to me like if we had provided LT_CHECK_LIB in libtool-1.5 (which
quite incidentally would have been implemented by running libtool) that
you could have written your tests in terms of that?

So we need an LT_CHECK_LIB macro in libtool-2-0, which may be possible
by looking in .la files and the results of the other libtool configure
time tests to construct an ld based link line -- or may force us to go
back to a non-config.status generated libtool.

Either way, the correct interface is (not yet implemented) LT_CHECK_LIB,
no?

Cheers,
Gary.
-- 
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook


signature.asc
Description: OpenPGP digital signature
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool 2.0 in autoconf tests

[Sander Niemeijer]

Agreed.  I think that there are a small number of circumstances where
the early-build of libtool was genuinely useful, and I think we should
be able to wrap each of those cases is a shipped macro that leverages
the knowledge already probed for libtool without needing to actually
have a libtool script present.
Most of the time people were just grepping the libtool script for the
value of some variable.
Ok. That is definitely not an approach that should be encouraged. Such 
macros should indeed be based on lt_ variables.

But your's is one of the few cases that needs
a whole new macro.  I'd be delighted if you want to help us write it,
but it should then be part of libtool.m4, not your package!
If more people require this functionality then I am all for including 
it in the libtool package. However, this doesn't answer the question 
whether the macro should be based on a libtool script or not. 
Furthermore, other users might have other macros that are also 
perfectly valid in wanting to use the libtool script. How do we deal 
with those macros?

Best regards,
Sander

___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool 2.0 in autoconf tests

[Gary V. Vaughan]

Hi Sander,

Sander Niemeijer wrote:
 If more people require this functionality then I am all for including it
 in the libtool package. However, this doesn't answer the question
 whether the macro should be based on a libtool script or not.
 Furthermore, other users might have other macros that are also perfectly
 valid in wanting to use the libtool script. How do we deal with those
 macros?

Oversimplifying, but: In a configure script, you can spell
`libtool -[options] [objects]' as `LT_CHECK_LIB([options], [objects])'.
Maybe we need LT_LINK_IFELSE instead/as well.

Cheers,
Gary.
-- 
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook


signature.asc
Description: OpenPGP digital signature
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool 2.0 in autoconf tests

[Sander Niemeijer]

Oversimplifying, but: In a configure script, you can spell
`libtool -[options] [objects]' as `LT_CHECK_LIB([options], [objects])'.
Maybe we need LT_LINK_IFELSE instead/as well.
What I need is a replacement for the LT_AC_LINK_SHLIB_IFELSE macro in:
  http://lists.gnu.org/archive/html/libtool/2004-10/msg00222.html
So I would rather see at least a LT_LINK_IFELSE and second probably 
also a LT_CHECK_LIB.

Remember that I mentioned in a previous email that the target is 
important. Having just one LT_LINK_IFELSE is maybe not enough (unless 
we allow some parameterization), since a test that produces a program 
does not necessarily have to have to same result as a test that 
produces a shared library (for instance when trying to link with a 
static library). And maybe we also need to have a special case for 
modules.

Second, my test relied on the fact that libtool produced an error when 
I was trying to link a static library against a shared library 
(something most linkers will happily accept, right?). Any 
LT_LINK_IFELSE macro implementation should have this same check (and 
for that matter any other check that an actual libtool script would 
perform).

Best regards,
Sander

___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool 2.0 in autoconf tests

[Bob Friesenhahn]

On Mon, 22 Nov 2004, Peter O'Gorman wrote:
I would approve a patch which added LT_TRY_LINK or some such macro, and 
created a temporary configure time libtool script to do so. I think it would 
be a fairly hefty patch though. There is certainly enough information 
available to allow this as soon as the LT_INIT macro is complete, though 
there will be issues with quoting, as things are quoted one extra time 
because of the intervening config.status.
In my configure.ac file, which I have been updating for libtool-2.0, 
LT_LANG(C++) occurs after LT_INIT() so it seems that the above 
statement may be bogus.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool 2.0 in autoconf tests

[Kevin P. Fleming]

Gary V. Vaughan wrote:
So we need an LT_CHECK_LIB macro in libtool-2-0, which may be possible
by looking in .la files and the results of the other libtool configure
time tests to construct an ld based link line -- or may force us to go
back to a non-config.status generated libtool.
Either way, the correct interface is (not yet implemented) LT_CHECK_LIB,
no?
That would be ideal, yes.
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Application is pre approved

[Bennett Sadler]

Dear Sir or Madam,

Would you REFINANCE if you knew you'd SAVE TH0USANDS? 

We'll get you lnterest as low as 1.92%. 
Don't believe me? Fill out our small online questionaire and we'll show you 
how. 

Get the house/home and/or car you always wanted, it only takes 10 seconds of 
your time:
http://www.your-financial.com/

Best Regards,
Andrew Banks

No thanks: http://www.your-financial.com/r1/




___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

急募在宅ワーカー 日給6900円可能

[soho6900]

$B"#6HL33HBg$K$D$-:_Bp%9%?%C%U$rJg=8CW$7$^$9!#(B
$BFq$7$$FbMF$G$O$"$j$^$;$s$,%$%s%?!<%M%C%H!"%a!<%k$NAw\:Y$O"*!!(Bhttp://discovery.sub.jp
$B"($*Ld9g$;$O"*!!([EMAIL PROTECTED](B
$B"($*?=9~$_$N:]$K$O!">R2p

oral health, 40, 000 hospitals, 25, 000 nursing homes and 400, 000 doctors.

[Chris Atkins]

The New 2005 United States Healthcare Database.

This complete database includes all hospitals, nursing homes,
and physicians in the country.

In a rapidly-changing industry, current healthcare information is an
invaluable resource to businesses and organizations.  The United States
Healthcare Database includes comprehensive information on more than
7,000 hospitals, 25,000 nursing homes and 400,000 doctors.  It is the
most extensive and reliable mailing list and database of key decision
makers in the health care market.

Each record is indexed by such features as name, address, phone and
fax. The database is available in Excel format on CD Rom.  It is
designed for mailing lists and merges.  The data can be selected by
state or other criteria such as type of practice. It can be used on
an unlimited basis.

For the past 14 years, MedCom has maintained the most comprehensive
healthcare lists.  Our directories are 100% telephone verified and
updated every quarter. MedCom continues to hold the nation's most
extensive and reliable databases of key decision-makers in the health
care market.

Available exclusively on CD-Rom (Excel), the data can be used on an
unlimited basis. It is easily exportable to other programs for
mailing or faxing purposes.

For a limited time, this extensive database is offered at an introductory 

Price of $195 (reg. $745).

To order, please print this e-mail, complete the information below and
fax it to 416-765-0029 (tel: 416-765-0028).

NAME:

TITLE:

ORGANIZATION:

ADDRESS:

CITY:

STATE:

POSTAL:

TEL:

FAX:

EMAIL:



___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool