Re: Supporting -export-dynamic on AIX

[Peter O'Gorman]

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
> exceeded so the patch needs a little more work. I'll try to address
> this soon.

As far as I can see we never check max_cmd_len when building programs,
only libraries, so there is no need to do this.

Peter


signature.asc
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool

LT_* equivalent to AC_CHECK_LIB?

[Tim Mooney]

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 (and the libfoo.la is hopefully installed on the system), is there
an extant macro something like LT_CHECK_LIB(foo,foo_amazing_func) that
will try find foo_amazing_func() in libfoo *and* will pull in all the
necessary dependencies for libfoo, automatically?

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), and
definitely requires one of libxml2 (which might have requirements like
zlib, pthread, libm, et. al.) or expat.  If I want to check for
libneon at configure time, using just AC_CHECK_LIB or AC_SEARCH_LIB will
be extremely painful, because even with the fourth argument to either of
those macros, I'll still have to write a battery of configure tests to
figure out which particular combination of libraries is required to get
libneon and its dependencies.  If there's a libtool-aware equivalent
macro, it would be so much easier.

Tim
--
Tim Mooney  [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building  (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Bob Friesenhahn]

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 libfoo, and libfoo was built with
libtool (and the libfoo.la is hopefully installed on the system), is there
an extant macro something like LT_CHECK_LIB(foo,foo_amazing_func) that
will try find foo_amazing_func() in libfoo *and* will pull in all the
necessary dependencies for libfoo, automatically?


I don't believe there is.  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.  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.  The macro would need to emulate the operation of 
libtool since libtool is not available yet.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Albert Chin]

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 PROTECTED])


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Albert Chin]

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 extant macro something like
> LT_CHECK_LIB(foo,foo_amazing_func) that will try find
> foo_amazing_func() in libfoo *and* will pull in all the necessary
> dependencies for libfoo, automatically?
> 
> 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), and definitely requires one of libxml2
> (which might have requirements like zlib, pthread, libm, et. al.) or
> expat.  If I want to check for libneon at configure time, using just
> AC_CHECK_LIB or AC_SEARCH_LIB will be extremely painful, because
> even with the fourth argument to either of those macros, I'll still
> have to write a battery of configure tests to figure out which
> particular combination of libraries is required to get libneon and
> its dependencies.  If there's a libtool-aware equivalent macro, it
> would be so much easier.

Is libneon a static library? If not, and libneon has the 3rd-party
libraries as dependencies, why shouldn't linking with just -lneon
work?

-- 
albert chin ([EMAIL PROTECTED])


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Albert Chin]

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 to use
libtool. Libtool should replace things like AC_CHECK_LIB,
AC_TRY_COMPILE, etc. with invocations to use ./libtool rather than
$CC, $CXX, etc.

-- 
albert chin ([EMAIL PROTECTED])


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Bob Friesenhahn]

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 shouldn't have to go through any more effort to use
libtool. Libtool should replace things like AC_CHECK_LIB,
AC_TRY_COMPILE, etc. with invocations to use ./libtool rather than
$CC, $CXX, etc.


In this case, users would be doing less work.  With the current 
scheme, portable software needs to know about all of the library 
dependencies in order for AC_CHECK_LIB to work at all.  This can be a 
lot of work and is a common point of failure.  The current workaround 
is to use a -config script to obtain library dependency info.


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.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Bob Friesenhahn]

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 linking.  Failure results 
when a shared lib does not specify any dependencies, or the OS does 
not support it.


For example, specifying just -lpng might not cause the linker to 
implicitly add -lz.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Tim Mooney]

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 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 extant macro something like LT_CHECK_LIB(foo,foo_amazing_func) that
will try find foo_amazing_func() in libfoo *and* will pull in all the
necessary dependencies for libfoo, automatically?


I don't believe there is.  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.  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.  The macro would 
need to emulate the operation of libtool since libtool is not available yet.


Thanks Bob.  It seems like this is one area where pkg-config provides
useful functionality that libtool could but doesn't currently.  I would
prefer to avoid pkg-config, mainly because it introduces another
dependency.

I haven't looked at the upcoming libtool 2.0 much, and I'm sure there's a
very good reason for delaying the generation of libtool until the end of
the configure run, but it does appear that it's unfortunate from the
aspect of creating a macro like the one we're talking about.

Tim
--
Tim Mooney  [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building  (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Tim Mooney]

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), and definitely requires one of libxml2
(which might have requirements like zlib, pthread, libm, et. al.) or
expat.  If I want to check for libneon at configure time, using just
AC_CHECK_LIB or AC_SEARCH_LIB will be extremely painful, because
even with the fourth argument to either of those macros, I'll still
have to write a battery of configure tests to figure out which
particular combination of libraries is required to get libneon and
its dependencies.  If there's a libtool-aware equivalent macro, it
would be so much easier.


Is libneon a static library? If not, and libneon has the 3rd-party
libraries as dependencies, why shouldn't linking with just -lneon
work?


It is static.  The default for libneon is to build static only, so on
many systems where the main package would be configured, there would only
be a static libneon available.

You would certainly know better than I, but I was also under the
impression that not all of the common UNIX variants automatically pull
in dependant libraries, even when they're listed as dependencies for
a shared libneon.  I know that works on many (Linux and most/all?
ELF-based systems) systems, but I thought a few of the platforms
didn't.

Tim
--
Tim Mooney  [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building  (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Tim Mooney]

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
write a robust LT_CHECK_LIB.  It probably makes sense to fall back to what
AC_CHECK_LIB does in that case, but a macro like LT_CHECK_LIB would
definitely need to handle the case where there are a mix of non-libtool
and libtool libraries.

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?

Tim
--
Tim Mooney  [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building  (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Bob Friesenhahn]

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?


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 it finds them in the .la files.


You may see that autoconf encourages configure scripts to supply all 
of the library dependencies since the tests require it.  Likewise, 
libtool applies all of the libraries it is instructed to apply as well 
as additional dependencies obtained via the .la files.  A smarter 
build system would allow libtool to distinguish between immediate 
dependencies and "extraneous" dependencies and only apply the 
immediate dependencies if the OS/linke support it.


Bob



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Ralf Wildenhues]

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 not available for use.
> 
> Didn't Ralf address this?

Yes, well, Gary did:  LT_OUTPUT.  See the second test in
tests/early-libtool.at (and the documentation).

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Ralf Wildenhues]

* 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 describe.
> 
> I disagree. Users shouldn't have to go through any more effort to use
> libtool. Libtool should replace things like AC_CHECK_LIB,
> AC_TRY_COMPILE, etc. with invocations to use ./libtool rather than
> $CC, $CXX, etc.

This would definitely not match the expectations of many users.

With pkg-config (and other hand-written solutions), and many systems not
installing .la files, you can't be sure to get all dependent libraries.

A real solution to LT_CHECK_LIB should also incorporate the semantics of
direct and indirect dependencies: on some systems, you really do not
want to link against all indirect dependencies.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Russ Allbery]

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 it finds them in the .la files.

And mostly because, unlike pkg-config, libtool doesn't distinguish between
dependencies required for static linking and dependencies required for
shared linking.

> You may see that autoconf encourages configure scripts to supply all of
> the library dependencies since the tests require it.

Except in practice the tests don't on systems using shared libraries and
shared linking with reasonable shared library dependency support (the
default most places now).

> Likewise, libtool applies all of the libraries it is instructed to apply
> as well as additional dependencies obtained via the .la files.  A
> smarter build system would allow libtool to distinguish between
> immediate dependencies and "extraneous" dependencies and only apply the
> immediate dependencies if the OS/linke support it.

That would be very nice.  It does require input from the person building
the library, though, or very recent GNU ld with options that don't work
properly on some more obscure platforms.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Russ Allbery]

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 linker
> applies implicit dependency libraries during linking.  Failure results
> when a shared lib does not specify any dependencies, or the OS does not
> 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 link time actually re-adds
most of the problems that libtool currently causes.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Ralf Wildenhues]

* 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.
> 
> I thought about that last problem too, which makes it more difficult to
> write a robust LT_CHECK_LIB.  It probably makes sense to fall back to what
> AC_CHECK_LIB does in that case, but a macro like LT_CHECK_LIB would
> definitely need to handle the case where there are a mix of non-libtool
> and libtool libraries.

Probably, yes.

> 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.

To avoid linking against indirect dependencies.  Or to avoid link
failure when other dependencies' .la files have been removed or moved.

> 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 it up.  I've suggested an
extensive set of testsuite tests (in some Debian bug report) which I
would see as a prerequisite to rewriting the deplib search algorithm
in ltmain.  One point is that, for consistency, the algorithm would
need to recursively include all indirect dependencies.

If anyone really cares, I can dig up a list of URLs to some important
discussion pieces.  I also have some half-finished notes, unpublished.
What is definitely lacking on my side is something like some months
with lots of time...

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Tim Mooney]

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 libtool 2.0) gone into addressing
the reason(s) why they were doing that?


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 it finds them in the .la files.


Ah yes, thanks for reminding me.  That makes sense -- I recall the message
about the pain that was going to happen for some distribution that was
going to up the soname major for freetype.

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
  dependencies
- when creating a shared library, make sure that it's dependent
  libraries are recorded (however that's done for a particular
  platform, probably just linking) by the library when it's created.
- when linking against a shared library of this type, detect which
  libraries are recorded as dependant for the shared library and
  leave those out of the list of dependency_libs for the shared
  library.

Is that about it?

Tim
--
Tim Mooney  [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building  (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Ralf Wildenhues]

* 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.  Libtool has been specifying the full list of
> > dependencies to the linker, as it finds them in the .la files.
> 
> And mostly because, unlike pkg-config, libtool doesn't distinguish between
> dependencies required for static linking and dependencies required for
> shared linking.

This is a common misconception.  Not all systems allow you to omit
indirect dependencies even for shared linking, AFAIK.

The issue really is direct vs. indirect dependencies, with static
linking not allowing indirect ones.

> > You may see that autoconf encourages configure scripts to supply all of
> > the library dependencies since the tests require it.
> 
> Except in practice the tests don't on systems using shared libraries and
> shared linking with reasonable shared library dependency support (the
> default most places now).

Yes.  Every now and then you get a bug report from someone linking
statically.  Like users of dietlibc or another tiny libc.

> > Likewise, libtool applies all of the libraries it is instructed to apply
> > as well as additional dependencies obtained via the .la files.  A
> > smarter build system would allow libtool to distinguish between
> > immediate dependencies and "extraneous" dependencies and only apply the
> > immediate dependencies if the OS/linke support it.
> 
> That would be very nice.  It does require input from the person building
> the library, though,

Yes.

> or very recent GNU ld with options that don't work
> properly on some more obscure platforms.

That may not even be enough: You may _want_ to link against libfoo, even
if you don't use it, in order to have those symbols available when you
later dlopen some module.  (This isn't portable, but people still want
to be able to do this.)

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Bob Friesenhahn]

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 link time actually re-adds
most of the problems that libtool currently causes.


Right.  The linker needs to record that libpng.so is dependent on 
libz.so.X.X.X when libpng.so is built.  When a library or application 
links using -lpng, a system with full dependency support does not 
require (or want) -lz to be specified.  On the other hand, when using 
static libraries, or on systems lacking the dependency support, all 
the libraries involved need to be specified.  Usually the configure 
script has no reliable way to know if a library is static or shared.


Under Microsoft Windows (and versions of AIX) it is definitely 
necessary for all libraries to be specified.


libpng is an interesting case because some users of libpng will use 
libz functions directly (e.g. to compute a PNG chunk CRC).  In such 
cases, libz is also a direct dependency.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Ralf Wildenhues]

* 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 the linker follows library
>   dependencies
>   - when creating a shared library, make sure that it's dependent
> libraries are recorded (however that's done for a particular
> platform, probably just linking) by the library when it's created.
>   - when linking against a shared library of this type, detect which
> libraries are recorded as dependant for the shared library and
> leave those out of the list of dependency_libs for the shared
> library.
> 
> Is that about it?

No.  It's much more complicated.

If you allow the concept of indirect dependencies,

- you must make sure that uninstalled libraries which happen to be
  indirect dependencies, are properly linked against (instead of an
  earlier installed version) when executing uninstalled programs,

- that upon installation, libraries and programs properly do not contain
  any build-tree paths any more,

- match that with an aim to get -fast-install and -no-fast-install
  working properly, and with relink-upon-execution and relink-upon-
  installation,

- the many different semantics for hardcoding make this even "more
  interesting" ... for example, one we would need the information
  whether the linker and/or the runtime loader respect runpaths (and
  in which priority) for indirect dependencies, and whether with
  priority over the shlibpath variable.  This is trickier than you
  think: some GNU/Linux distributions even install GNU binutils with a
  different default...

Cheers,
Ralf
  


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Bob Friesenhahn]

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
 dependencies
- when creating a shared library, make sure that it's dependent
  libraries are recorded (however that's done for a particular
  platform, probably just linking) by the library when it's created.
- when linking against a shared library of this type, detect which
  libraries are recorded as dependant for the shared library and
  leave those out of the list of dependency_libs for the shared
  library.

Is that about it?


Hardly. :-)

The problem is exceedingly challenging.  You did not mention that on 
some systems libraries need to be listed in a (particular) order of 
diminishing dependency.  For example, -lm and -lpthread would 
typically appear at the end of the dependency list.


Autotools has a policy of allowing the person running configure to 
specify additional configuration information via CFLAGS, LDFLAGS, 
and LIBS.  This mechanism should not be broken.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Tim Mooney]

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 doing what it's already doing
- for shared libraries on platforms where the linker follows library
  dependencies
- when creating a shared library, make sure that it's dependent
  libraries are recorded (however that's done for a particular
  platform, probably just linking) by the library when it's created.
- when linking against a shared library of this type, detect which
  libraries are recorded as dependant for the shared library and
  leave those out of the list of dependency_libs for the shared
  library.

Is that about it?


No.  It's much more complicated.


That's what I was afraid of.  Even the steps I outlined were complex, but
I figured someone would have solved it if it was "that easy".

Thanks for clarifying.

Tim
--
Tim Mooney  [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building  (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_* equivalent to AC_CHECK_LIB?

[Tim Mooney]

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 it up.


Will do.


 I've suggested an
extensive set of testsuite tests (in some Debian bug report) which I
would see as a prerequisite to rewriting the deplib search algorithm
in ltmain.  One point is that, for consistency, the algorithm would
need to recursively include all indirect dependencies.

If anyone really cares, I can dig up a list of URLs to some important
discussion pieces.  I also have some half-finished notes, unpublished.
What is definitely lacking on my side is something like some months
with lots of time...


Thanks Ralf.  I subscribe to this list but not -patches so I'm much less
aware of what goes on there.  If I feel the need to dig any deeper on this
(pretty doubtful at this point, you and Bob have completely disabused me
of the notion that this is something I want to try help "solve"), I'll
do the necessary digging in the archives.

Tim
--
Tim Mooney  [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building  (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


___
http://lists.gnu.org/mailman/listinfo/libtool

Interix Shared Libraries

[Duft Markus]

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 also created a little patch 
for libtool 1.5.22 which allows building it shared with wgcc. This works ok for 
now (just some little probs with globals ;o//), and i'm prudktively building 
lots of libraries (about 200 MB Sources => about 4 GB Binaries...) with 
little or no modification (except updating libtool) (many of those sources have 
never seen windows!!).
 
The thing works on 
Interix 3.5, 5.2 and 6.0 (!!) (with the newest config.guess)
 
If anybody is 
interested in this, everything can be found at sourceforge (www.sourceforge.net/projects/interix-wgcc) 
(the patches for libtool too)
 
(if you wonder what ucl and 
ulink are: these are tool for the windows command line which allow linking in 
libraries with unix style names
without having to change the 
command line from cl.exe. Additionally the whole environment gcc would listen to 
is take into account,
and the pxwc library (wgcc) is 
linked in to allow in place path conversion at runtime with 
getenv...)
 
Any feedback would 
be really great!!
 
Regards, 
Markus
___
http://lists.gnu.org/mailman/listinfo/libtool