I would appreciate it if an item could be added to the TODO list for
the new 2.x branch that solves the issue discussed in the following
thread from about a year ago:
http://lists.gnu.org/archive/html/libtool/2004-11/msg00372.html
Best regards,
Sander Niemeijer
Hi Sander,
* Sander Niemeijer wrote on Wed, Aug 24, 2005 at 10:54:53AM CEST:
I would appreciate it if an item could be added to the TODO list for
the new 2.x branch that solves the issue discussed in the following
thread from about a year ago:
Hi Sander,
On 24 Aug 2005, at 09:54, Sander Niemeijer wrote:
I would appreciate it if an item could be added to the TODO list
for the new 2.x branch that solves the issue discussed in the
following thread from about a year ago:
* Sander Niemeijer wrote on Wed, Aug 24, 2005 at 10:54:53AM CEST:
I would appreciate it if an item could be added to the TODO list for
the new 2.x branch that solves the issue discussed in the following
thread from about a year ago:
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
* 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
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
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
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?
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
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
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
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
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
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:
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
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
Ralf Wildenhues wrote:
* Sander Niemeijer wrote on Thu, Nov 18, 2004 at 01:54:12PM CET:
I have some self written autoconf tests that check for linking shared
libraries against some specific other libraries (these other libraries
should be available as shared libraries or we might have a PIC
Gary V. Vaughan wrote:
Ralf Wildenhues wrote:
* Sander Niemeijer wrote on Thu, Nov 18, 2004 at 01:54:12PM CET:
I have some self written autoconf tests that check for linking
shared libraries against some specific other libraries (these other
libraries should be available as shared libraries
Hi,
I have send this question to the list about a month ago, but
unfortunately, there hasn't been an answer yet, and the release of
libtool 2.0 is not that far away (right?).
http://lists.gnu.org/archive/html/libtool/2004-10/msg00219.html
Sander Niemeijer wrote:
Hi,
I have send this question to the list about a month ago, but
unfortunately, there hasn't been an answer yet, and the release of
libtool 2.0 is not that far away (right?).
http://lists.gnu.org/archive/html/libtool/2004-10/msg00219.html
* Sander Niemeijer wrote on Thu, Nov 18, 2004 at 01:54:12PM CET:
I have send this question to the list about a month ago, but
unfortunately, there hasn't been an answer yet, and the release of
libtool 2.0 is not that far away (right?).
Hmm. We need to at least wait for the copyright issue
22 matches
Mail list logo
