Re: Remove redundant mention of new testsuite files
Hallo Ralf! Ralf Wildenhues wrote: It's really nice to mention stuff exactly once. :-) OK to apply this to HEAD? It really is a work saver for me. Yes please, nice patch! :-D * Makefile.am (TESTSUITE_AT): List testsuite files in the order in which they are to be expanded in the suite. (tests/TESTSUITE): Rebuild by passing all $(TESTSUITE_AT) files, with their path suitably adjusted. This enables us to.. * tests/testsuite.at: ..get rid of their redundant mention here. 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
Re: Remove redundant mention of new testsuite files
Hi Gary, * Gary V. Vaughan wrote on Wed, Feb 01, 2006 at 08:44:23PM CET: Ralf Wildenhues wrote: It's really nice to mention stuff exactly once. :-) OK to apply this to HEAD? It really is a work saver for me. Yes please, nice patch! :-D Thanks! Applied. Cheers, Ralf * Makefile.am (TESTSUITE_AT): List testsuite files in the order in which they are to be expanded in the suite. (tests/TESTSUITE): Rebuild by passing all $(TESTSUITE_AT) files, with their path suitably adjusted. This enables us to.. * tests/testsuite.at: ..get rid of their redundant mention here.
Re: per-deplib static/dynamic flags
On Wed, Feb 01, 2006 at 12:47:51AM -0600, Bob Friesenhahn wrote: On Tue, 31 Jan 2006, Albert Chin wrote: On Mon, Jan 30, 2006 at 10:28:52PM +0100, Ralf Wildenhues wrote: - Should the corresponding libtool flags be named `-Bstatic' resp. `-Bdynamic'? Those were the most common names I could find, but IMHO they are not very self-explanatory for users not used to them. -prefer-static, -prefer-dynamic/-prefer-shared? The -Bxxx doesn't seem similar with current libtool options. At least for the static case, I would prefer the link to entirely fail if a static library is requested but one can not be found. Usually there is a very important reason to use a static library if it has specifically been requested. So the wording should not be 'prefer' for the static case. I agree that the -B syntax does not fit the style of other libtool options (but does match many linkers). Fine. -Bstatic on Linux means Do not link against shared libraries. anyway. -- albert chin ([EMAIL PROTECTED])
Re: per-deplib static/dynamic flags
On Wed, Feb 01, 2006 at 05:40:51PM -0600, Bob Friesenhahn wrote:
On Wed, 1 Feb 2006, Albert Chin wrote:
Fine. -Bstatic on Linux means Do not link against shared libraries.
anyway.
Good. GCC uses -B to mean something else. So -Bstatic is a
linker-only option. It is likely useful to use something new which
won't be confusing due the different meaning between GCC and ld.
How about -static-only and -shared-only?
Note though that Ralf has -Bstatic defined as:
If @var{output-file} is a program, prefer linking statically
^^
This is not -Bstatic under Linux according to ld(1). If this is what
is intended, then -prefer-static is back :)
--
albert chin ([EMAIL PROTECTED])
Re: per-deplib static/dynamic flags
On Wed, 1 Feb 2006, Albert Chin wrote:
Good. GCC uses -B to mean something else. So -Bstatic is a
linker-only option. It is likely useful to use something new which
won't be confusing due the different meaning between GCC and ld.
How about -static-only and -shared-only?
Note though that Ralf has -Bstatic defined as:
If @var{output-file} is a program, prefer linking statically
^^
This is not -Bstatic under Linux according to ld(1). If this is what
is intended, then -prefer-static is back :)
There is something else we have not considered. How is all this going
to mesh properly with autoconf configure?
I would love to be able to supply LDFLAGS options to configure and
have them work appropriately within the configure script, and then
work similarly for libtool. If the options do not work in LDFLAGS,
then it will be necessary to pass them explicitly via the Makefile.
In this case
-Wl,-Bstatic
may work better even though it is more obtuse.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: per-deplib static/dynamic flags
Hi Bob, Albert, * Bob Friesenhahn wrote on Wed, Feb 01, 2006 at 07:47:51AM CET: On Tue, 31 Jan 2006, Albert Chin wrote: On Mon, Jan 30, 2006 at 10:28:52PM +0100, Ralf Wildenhues wrote: - Should the corresponding libtool flags be named `-Bstatic' resp. `-Bdynamic'? Those were the most common names I could find, but IMHO they are not very self-explanatory for users not used to them. -prefer-static, -prefer-dynamic/-prefer-shared? The -Bxxx doesn't seem similar with current libtool options. At least for the static case, I would prefer the link to entirely fail if a static library is requested but one can not be found. Usually there is a very important reason to use a static library if it has specifically been requested. So the wording should not be 'prefer' for the static case. I agree that the -B syntax does not fit the style of other libtool options (but does match many linkers). Several different issues here: - the option naming, which I will not delve into in this post, and - whether what I'll call -Bstatic for now should fail if it does not find a static library to link against. The latter point is intricate, and requires much more elaboration to be completely specified. That's the main reason I kept the semantics so vague in my proposal. The issues are: library search algorithm, difference between libtool and non-libtool libraries, linker capability. 1) The linker may not allow to specify per-deplib linkage at all, or may not have a flag to force static linkage (as opposed to only _prefer_ it). Examples for the former are Darwin; I haven't found an example for the latter yet (good!). But this means, that for non-libtool libraries we cannot guarantee a certain linking mode, unless we were to change our search algorithm quite drastically (which I don't see as an option ATM). 2) Difference between libtool libraries (*.la) and non-libtool ones, and libtool search algorithm and native linker search algorithm. The current libtool library search algorithm looks a bit like this (before my patch): - given `path/to/libfoo.la', that is taken and nothing else. - given `path/to/libfoo.a' ($libext), that is taken and nothing else. - given `-lfoo' for all searchdirs that we look at, for the extensions `.la', `$std_shrext', `.so', `.a' [1] check whether there exists a file libfoo.$extension if yes, exit search algorithm My patch skips `$std_shrext' and `.so' when in Bstatic mode, but it still happily picks the first `.la' file it can find, even iff that one was shared-only, for example. Currently it then links shared or fails to link, depending on hardcoding features of the linker, and on whether the linker fails to link shared in Bstatic mode. It may be more useful to either - fail outright if the first .la library wasn't good, or - go back and scan the rest of the searchdirs for a better candidate library. But this would open new questions: would we then accept .la libraries as better candidates only, or also $libext archives? The same question already goes for `-static' and `-static-libtool-libs': Should they fail upon encounter of a disable-static libtool library? Obviously that is more of an issue for `-static-libtool-libs' because it also involves libraries not in the current package tree. Now about non-libtool libaries: while I believe all linkers (that have Bstatic flags) will fail if they find a shared but no static library anywhere in the search path, this needs testing. I will extend static.at to do this as well, but even then there's no guarantee another system may have this limitation. Hope that helps a bit. Cheers, Ralf [1] we need to exchange `.a' with $libext, or add $libext if != `.a' for w32 systems, I believe.
