On Mon, 2006-07-03 at 01:29 -0500, Albert Chin wrote:
> On Sun, Jul 02, 2006 at 10:58:23PM +0900, Peter O'Gorman wrote:
> > Here are patches against branch-1-5 and HEAD, okay (with apropriate
> > ChangeLog, of course)?
>
> The patch I submitted doesn't work when the command-line length is
> exceed
This seems like it should be an obvious question, but I'm not finding any
obvious answers in either the libtool or autoconf documentation.
Is there a libtool-aware equivalent to AC_CHECK_LIB? In other words, if I
want to check for foo_amazing_func() in libfoo, and libfoo was built with
libtool
On Mon, 3 Jul 2006, Tim Mooney wrote:
This seems like it should be an obvious question, but I'm not finding any
obvious answers in either the libtool or autoconf documentation.
Is there a libtool-aware equivalent to AC_CHECK_LIB? In other words, if I
want to check for foo_amazing_func() in lib
On Mon, Jul 03, 2006 at 02:20:45PM -0500, Bob Friesenhahn wrote:
> A challenge is that in libtool 2.0, the libtool script is not
> generated until the end of the configure script run (an
> `enhancement' in 2.0) so it is not available for use.
Didn't Ralf address this?
--
albert chin ([EMAIL PROT
On Mon, Jul 03, 2006 at 01:52:36PM -0500, Tim Mooney wrote:
>
> Is there a libtool-aware equivalent to AC_CHECK_LIB? In other
> words, if I want to check for foo_amazing_func() in libfoo, and
> libfoo was built with libtool (and the libfoo.la is hopefully
> installed on the system), is there an e
On Mon, Jul 03, 2006 at 02:20:45PM -0500, Bob Friesenhahn wrote:
> Autoconf can not depend on libtool, so Autoconf should not provide
> such a macro, but it certainly makes sense for libtool to provide a
> LT_CHECK_LIB as you describe.
I disagree. Users shouldn't have to go through any more effort
On Mon, 3 Jul 2006, Albert Chin wrote:
On Mon, Jul 03, 2006 at 02:20:45PM -0500, Bob Friesenhahn wrote:
Autoconf can not depend on libtool, so Autoconf should not provide
such a macro, but it certainly makes sense for libtool to provide a
LT_CHECK_LIB as you describe.
I disagree. Users should
On Mon, 3 Jul 2006, Albert Chin wrote:
Is libneon a static library? If not, and libneon has the 3rd-party
libraries as dependencies, why shouldn't linking with just -lneon
work?
As you are well aware, this only works on systems where the linker
applies implicit dependency libraries during lin
In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Bob Friesenhahn said...:
On Mon, 3 Jul 2006, Tim Mooney wrote:
This seems like it should be an obvious question, but I'm not finding any
obvious answers in either the libtool or autoconf documentation.
Is there a libtool-aware equivalent to
In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Albert Chin said (at...:
The specific case I'm looking at is for a package that wants to
check for libneon. Neon (which is a libtool library) might have
been linked against OpenSSL (which might require pthread libraries
and/or krb5 libraries),
In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Bob Friesenhahn said...:
Unfortunately, various OS distributions have made a habit of deleting the .la
files so a LT_CHECK_LIB would not be as helpful as it might appear.
I thought about that last problem too, which makes it more difficult to
On Mon, 3 Jul 2006, Tim Mooney wrote:
I seem to recall discussion on this list in the past about why
distributions were doing that, but I don't recall what any of the reasons
were. Has any work (perhaps as part of libtool 2.0) gone into addressing
the reason(s) why they were doing that?
Opera
Hello,
* Albert Chin wrote on Mon, Jul 03, 2006 at 10:14:39PM CEST:
> On Mon, Jul 03, 2006 at 02:20:45PM -0500, Bob Friesenhahn wrote:
> > A challenge is that in libtool 2.0, the libtool script is not
> > generated until the end of the configure script run (an
> > `enhancement' in 2.0) so it is no
* Albert Chin wrote on Mon, Jul 03, 2006 at 10:23:43PM CEST:
> On Mon, Jul 03, 2006 at 02:20:45PM -0500, Bob Friesenhahn wrote:
> > Autoconf can not depend on libtool, so Autoconf should not provide
> > such a macro, but it certainly makes sense for libtool to provide a
> > LT_CHECK_LIB as you desc
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> Operating systems with robust library dependency support don't like the
> libraries explicitly specifying dependendies on libraries they are not
> immediately dependent on. Libtool has been specifying the full list of
> dependencies to the linker, as
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> On Mon, 3 Jul 2006, Albert Chin wrote:
>> Is libneon a static library? If not, and libneon has the 3rd-party
>> libraries as dependencies, why shouldn't linking with just -lneon
>> work?
> As you are well aware, this only works on systems where the li
* Tim Mooney wrote on Mon, Jul 03, 2006 at 10:50:23PM CEST:
> In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Bob Friesenhahn said...:
>
> >Unfortunately, various OS distributions have made a habit of deleting the
> >.la files so a LT_CHECK_LIB would not be as helpful as it might appear.
>
>
In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Bob Friesenhahn said...:
On Mon, 3 Jul 2006, Tim Mooney wrote:
I seem to recall discussion on this list in the past about why
distributions were doing that, but I don't recall what any of the reasons
were. Has any work (perhaps as part of li
* Russ Allbery wrote on Mon, Jul 03, 2006 at 11:14:34PM CEST:
> Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> > Operating systems with robust library dependency support don't like the
> > libraries explicitly specifying dependendies on libraries they are not
> > immediately dependent on. Libtoo
support it.
For example, specifying just -lpng might not cause the linker to
implicitly add -lz.
Note that the linker that needs to figure this out is actually the dynamic
linker as such dependencies should be resolved at run-time, *not* at link
time. A linker that does such resolution at li
* Tim Mooney wrote on Mon, Jul 03, 2006 at 11:17:03PM CEST:
> So to address this, libtool would need to
>
> - know how the platform behaves regarding shared library dependencies
> - in the case of static libraries, continue doing what it's already doing
> - for shared libraries on platforms where
On Mon, 3 Jul 2006, Tim Mooney wrote:
So to address this, libtool would need to
- know how the platform behaves regarding shared library dependencies
- in the case of static libraries, continue doing what it's already doing
- for shared libraries on platforms where the linker follows library
d
In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Ralf Wildenhues said...:
* Tim Mooney wrote on Mon, Jul 03, 2006 at 11:17:03PM CEST:
So to address this, libtool would need to
- know how the platform behaves regarding shared library dependencies
- in the case of static libraries, continue d
In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Ralf Wildenhues said...:
Has any work (perhaps as part of libtool 2.0) gone into addressing
the reason(s) why they were doing that?
Hmm. There has been quite some discussion on this and the -patches
list. Please use the mail archives to dig
Hey ho
;o)
To bring some (good)
news (i think ;o)). I wrote a little compiler wrapper you may have heard of
-> wgcc (www.sourceforge.net/projects/interix-wgcc)
which behaves like gcc and uses microsofts toolchain in the background. As of
0.6.0 the shared library support is quite stable. I
25 matches
Mail list logo
