Re: per-deplib static/dynamic flags

[Ralf Wildenhues]

Hi Peter,

* Peter O'Gorman wrote on Thu, Feb 02, 2006 at 03:04:19PM CET:
> Ralf Wildenhues wrote:
> |
> | This is precisely and only because I wasn't sure whether we would find a
> | linker which allows to set the preferred more but not force it to.
> 
> The odcctools  linker has a
> - -Bstatic/-Bdynamic flag that sets preferred, but does not force it. 
> However,
> since this linker is probably only used by people cross-compiling a darwin
> targetted gcc, it can probably be ignored :)

Well, does it also have a different flag to force static mode?  If not:
why not invent one?  :-)

Cheers,
Ralf

Re: per-deplib static/dynamic flags

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Thu, Feb 02, 2006 at 11:45:48AM CET:
> Ralf Wildenhues wrote:
> > This fixes the failure uncovered by the new tests posted previously.
> > 
> > OK to apply?
> 
> Looks good to me!  Please go right ahead :-)

Thanks!  Since this really is a 1.5.22 regression, I applied it to
branch-1-5, too.  Respective patch shown below.

Cheers,
Ralf

* ltmain.in (link mode): Fix logic for adding run paths to
also add paths for installed libtool libraries in case
`-static' is used.

Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v
retrieving revision 1.334.2.118
diff -u -r1.334.2.118 ltmain.in
--- ltmain.in   21 Jan 2006 16:46:08 -  1.334.2.118
+++ ltmain.in   3 Feb 2006 09:25:20 -
@@ -2497,7 +2497,9 @@
 
if test "$linkmode,$pass" = "prog,link"; then
  if test -n "$library_names" &&
-{ test "$prefer_static_libs" = no || test -z "$old_library"; }; 
then
+{ { test "$prefer_static_libs" = no ||
+test "$prefer_static_libs,$installed" = "built,yes"; } ||
+  test -z "$old_library"; }; then
# We need to hardcode the library path
if test -n "$shlibpath_var" && test -z "$avoidtemprpath" ; then
  # Make sure the rpath contains only unique directories.

Re: libtool-2.0 release [WAS per-deplib static/dynamic flags]

[Bob Friesenhahn]

On Thu, 2 Feb 2006, Bob Friesenhahn wrote:


I have also noticed some disturbing "leakage" of default compiler (GCC) path 
information into the build which causes -m64 to not work properly (at least 
under Solaris, but seems likely to impact other targets as well).  This bug 
did not used to exist on the 2.0 branch. In my test case, the compiler is 
always run via a shell script wrapper (gcc-64) which always runs gcc with 
-m64 so I am not sure what libtool did to encourage gcc to undo the effect of 
that option.


In order to clarify this issue some more, the problem only happens 
when linking a C++ library and occurs because while libtool does link 
using the C++ compiler, it supplies the options '-shared -nostdlib' 
and then proceeds to tell the compiler what it should already have 
done by default except that it gets something wrong and passes the 
path to the 32-bit version of libstdc++.so rather than the 64-bit 
version the compiler would have used when given the -m64 option.  So I 
think that it is wrong for libtool to be specifying -nostdlib 
and that it would be more reliable to allow the compiler to find its 
own crt objects and libraries.  The operation may be a vestige of when 
C++ libraries were linked directly using ld, except that this problem 
did not occur a year ago so it has somehow been added since then.


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

Re: libtool-2.0 release [WAS per-deplib static/dynamic flags]

[Bob Friesenhahn]

On Thu, 2 Feb 2006, Gary V. Vaughan wrote:


According to: http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap, the
three remaining release blockers for 2.0 are:

*  libtool.m4 macro ordering/requirement audit. pending
*  LT_WITH_LTDL should build libltdl by default; currently
  nothing happens unless LTDL_CONVENIENCE or LTDL_INSTALLABLE
  is also given.
*  fix potential denial of service with compilers that do not
  understand "-c -o".
  * not very likely to happen
  * http://lists.gnu.org/archive/html/libtool-patches/2005-03/msg00252.html


I know that Ralf is aware of a few more release-blocking issues than 
these.  One of them is to be able to libtoolize with a libltdl 
directory using the non-recursive option and end up with a subordinate 
Makefile.inc which works.  Currently the generated Makefile.inc takes 
some hand-tweaking.


I have also noticed some disturbing "leakage" of default compiler 
(GCC) path information into the build which causes -m64 to not work 
properly (at least under Solaris, but seems likely to impact other 
targets as well).  This bug did not used to exist on the 2.0 branch. 
In my test case, the compiler is always run via a shell script wrapper 
(gcc-64) which always runs gcc with -m64 so I am not sure what libtool 
did to encourage gcc to undo the effect of that option.


I have been re-libtoolizing various projects with libtool 2.0 and have 
encountered resounding success with MinGW (very good!).


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

libtool-2.0 release [WAS per-deplib static/dynamic flags]

[Gary V. Vaughan]

Hallo Ralf, Bob, Peter, Eric,

Is this patch really necessary for 2.0?  I think that introducing so
much code churn in to libtool at this stage is going to bring yet more
release delays.  Surely the feature is useful and desireable, but I
really *really* want to avoid more delays for 2.0.

Now is the time to branch!  Either a feature branch for developing the
per-deplib feature for merging after 2.0, or else a 2.0 branch that we
can keep stable.

My preference is to make a feature branch now, and not branch for 2.0
at least until the release blockers are resolved, so that we can commit
any bugfixes we discover during testing just once (we went through the
mess of porting to three branches during the last branch-2-0 debacle,
and I don't want to do that again!).

According to: http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap, the
three remaining release blockers for 2.0 are:

 *  libtool.m4 macro ordering/requirement audit. pending
 *  LT_WITH_LTDL should build libltdl by default; currently
   nothing happens unless LTDL_CONVENIENCE or LTDL_INSTALLABLE
   is also given.
 *  fix potential denial of service with compilers that do not
   understand "-c -o".
   * not very likely to happen
   * http://lists.gnu.org/archive/html/libtool-patches/2005-03/msg00252.html

And I would even dispute whether the first of those is really a release
blocker -- the code *does* need an audit, but it's been in that state for
several existing releases already.  lists.gnu.org and mail.gnu.org appear
to be down, so I can't read the post attached to the final blocker to
remind myself of that issue.

So here are the action points, initialed where I plan to take them
pending agreement from (most of) you guys.

 1. strike the macro ordering audit from the release blocker list.   GVV
 2. fix LTDL_{CONVENIENCE,INSTALLABLE} bug on CVS HEAD.  GVV
 3. make a per-deblib-branch for these changes.
 4. evaluate whether -c -o DoS is a release blocker too.
4a. fix it if it is
4b. strike it from the blocker list if it isn't
 5. test like crazy. and fix any platform issues uncovered   GVV
 6. release libtool-2.0 already! GVV

Once 2.0 is finally out, I will take a back seat with libtool for a while
to work on m4-2.0 and my new book.

Ralf Wildenhues wrote:
> 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 

Re: per-deplib static/dynamic flags

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ralf Wildenhues wrote:
|
| Hmm.  If we were to invent new flags, I currently like
|   -force-static, -prefer-shared
| best.
|
|
|>>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 :)
|
|
| This is precisely and only because I wasn't sure whether we would find a
| linker which allows to set the preferred more but not force it to.
|

The odcctools  linker has a
- -Bstatic/-Bdynamic flag that sets preferred, but does not force it. However,
since this linker is probably only used by people cross-compiling a darwin
targetted gcc, it can probably be ignored :)

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQ+IRY7iDAg3OZTLPAQL+pgQAuwg9Eq4iJGRsZLLvXBmwkKBPZseI0a+C
t5hfnE6hhYLr56WqEuaa8KGv4w5e7yilRQT1qv+rhhW61evtIxZnLZ9rwhhB1iRO
SoWGt/c29qaXd+Zik52WLPSyVEekykvOOJjLvcDcZlxZnxETri8JOFVBxB2tS5dh
u7a+vKeVa2Q=
=NhEY
-END PGP SIGNATURE-

Re: per-deplib static/dynamic flags

[Gary V. Vaughan]

Hallo Ralf,

Ralf Wildenhues wrote:
> This fixes the failure uncovered by the new tests posted previously.
> 
> OK to apply?

Looks good to me!  Please go right ahead :-)

> * libltdl/config/ltmain.m4sh (func_mode_link): Fix logic for
> adding run paths to also add paths for installed libtool
> libraries in case `-static' is used.

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: per-deplib static/dynamic flags

[Bob Friesenhahn]

On Thu, 2 Feb 2006, Ralf Wildenhues wrote:

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.


Note that `-Wl,-Bstatic' will *not* be useful in LDFLAGS, but LIBS at
best, because of the ordering issues.


Minor issue.  No complaints here!


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.


I don't see any reason against supporting both
  -force-static and -Wl,-Bstatic
as two names for the same thing.


I like that.  There are likely linkers which will reject -Wl,-Bstatic, 
but at least it provides an opportunity for success with configure.


In the future, we should discuss some way to support pre-processing of 
options passed to the configure script so that configure tests work as 
closely to libtool as possible.  I don't know how to address that now.



By the way, I'd like to fix ordering issues for `-Wl,'-given flags that
we don't understand, too; there have been several bug reports about
this.


Order is often quite important.

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

Re: per-deplib static/dynamic flags

[Ralf Wildenhues]

Hi Bob,

* Bob Friesenhahn wrote on Thu, Feb 02, 2006 at 05:39:02AM CET:
> 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.

True.

> >How about -static-only and -shared-only?

Hmm.  If we were to invent new flags, I currently like
  -force-static, -prefer-shared
best.

> >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 :)

This is precisely and only because I wasn't sure whether we would find a
linker which allows to set the preferred more but not force it to.

And also, because we then need to define the semantics of linking
against a libtool library (*.la) that was created shared-only.

> There is something else we have not considered.  How is all this going 
> to mesh properly with autoconf configure?

This question is *not* new.  `-static-libtool-libs' requires thought,
even `-static', because it has a different meaning for $CC than for
libtool.  Look at GCC's libtool-ldflags script which I pointed to in
my first post in this thread.

We should think about whether:
- we add a similar script to the Libtool package, or
- detect more option forms in the libtool script itself, e.g.:
   -Wl,-rpath
   -Wl,-Bstatic
   ...

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

Note that `-Wl,-Bstatic' will *not* be useful in LDFLAGS, but LIBS at
best, because of the ordering issues.

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

I don't see any reason against supporting both
   -force-static and -Wl,-Bstatic
as two names for the same thing.

By the way, I'd like to fix ordering issues for `-Wl,'-given flags that
we don't understand, too; there have been several bug reports about
this.

Cheers,
Ralf

Re: per-deplib static/dynamic flags

[Ralf Wildenhues]

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.

Re: per-deplib static/dynamic flags

[Bob Friesenhahn]

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

[Albert Chin]

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

[Albert Chin]

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

[Bob Friesenhahn]

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.


I am very interested in this new feature!

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

Re: per-deplib static/dynamic flags

[Bob Friesenhahn]

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


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

Re: per-deplib static/dynamic flags

[Albert Chin]

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.

-- 
albert chin ([EMAIL PROTECTED])

HEAD: static tests (was: per-deplib static/dynamic flags)

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Mon, Jan 30, 2006 at 02:01:53PM CET:
> 
> I will followup to this mail (to libtool-patches only for size) with a
> patch to implement per-deplib flags for programs (for CVS HEAD) and add
> comprehensive tests for the static flags.

Here goes the test.  Note that the tests uncovered that hardcoding
was not done in all cases where necessary with the `-static' flag
since we changed its behavior; a fix will be proposed in a followup.

BTW, this was by far the most time-consuming task of these patches.

OK to apply?

Cheers,
Ralf

* tests/static.at: New tests for comprehensive test exposure of
all current and proposed static linking flags for programs.
* Makefile.am, tests/testsuite.at: Updated.

--- tests/testsuite.at  2006-01-30 18:33:32.0 +0100
+++ tests/testsuite.at  2006-01-30 18:34:21.0 +0100
@@ -290,6 +290,8 @@
 m4_include([link-order.at])
 # ensure failure
 m4_include([fail.at])
+# all the diverse static flags
+m4_include([static.at])
 # Ensure our continued support for old interfaces.
 m4_include([old-m4-iface.at])
 # Torturing subdir-objects builds
--- Makefile.am 2006-01-30 18:33:32.0 +0100
+++ Makefile.am 2006-01-30 18:34:21.0 +0100
@@ -396,6 +396,7 @@
  tests/fail.at \
  tests/convenience.at \
  tests/early-libtool.at \
+ tests/static.at \
  tests/template.at
 
 EXTRA_DIST += $(TESTSUITE) $(TESTSUITE_AT) tests/package.m4
--- /dev/null   2006-01-25 19:46:43.433914872 +0100
+++ tests/static.at 2006-01-30 22:11:38.0 +0100
@@ -0,0 +1,294 @@
+# Hand crafted tests for GNU Libtool. -*- Autotest -*-
+# Copyright 2006 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+# 02110-1301, USA.
+
+# Test flags for controlling static/dynamic linking,
+# when creating programs.
+
+# NOTES #
+#
+# - How do we test whether a library was linked statically?
+#   We could
+#   - try $NM on the program to see whether it includes the symbol definitions.
+# disadvantage: for uninstalled programs, we may need to find out the name
+# of the _real_ linked-against-uninstalled executable
+# (.libs/prog vs .libs/lt-prog etc).
+#   - simply remove the libraries before execution.  If the program still 
works,
+# then the library was linked statically.
+# -Does this work on all systems?
+# -No, it will fail on AIX with non-rtl-created libraries: plain `-static'
+# will only cause the linker not to consider `*.so' libraries, but only
+# `*.a'.  The latter, however, may still be shared images.  :-/
+# `-all-static' still works, however.
+#   
+# It will not work with dlpreloading until we fix its related bug.
+#   
+#   Let's try the latter until we know better.
+
+# - Test -Bstatic/-Bdynamic.  It should work with all of:
+#   - (un)installed libtool libraries
+#   - non-libtool libraries
+#   - direct or pulled-in libraries
+#   - libraries of which there are only one kind available (TODO)
+# (in the static case, should having only the shared one provoke failure?)
+
+# - Check no extraneous run paths have been added.
+
+# - make sure -Bstatic/-Bdynamic cannot be mixed with -all-static (TODO)
+
+# - should -Bstatic/-Bdynamic be mixable with -static or -static-libtool-libs?
+#   Semantics could be as follows:
+#   - `-static'/`-static-libtool-libs' set the default which is the initial
+# value, then `-Bstatic'/`-Bdynamic' override that
+#   - `-Bdefault' resets to the default value given by the other switches.
+
+# - TODO: test exposure for dlopened and dlpreopened modules,
+#   without and with diverse static flag combinations.
+
+# - TODO: test other tags: C++ etc.
+#   (most likely the Sun compiler suite will be the only problem child).
+
+AT_SETUP([static linking flags for programs])
+
+LDFLAGS="$LDFLAGS -no-undefined"
+prefix=`pwd`/inst
+libdir=$prefix/lib
+bindir=$prefix/bin
+srcdir_broken=`pwd`/b
+libdir_broken=`pwd`/b-lib
+
+have_static=false
+have_shared=false
+per_deplib=false
+$LIBTOOL --features | grep 'enable static libraries' >/dev/null && 
have_static=:
+$LIBTOOL --features | grep 'enable shared libraries' >/dev/null && 
have_shared=:
+eval `$LIBTOOL --config | $EGREP '^per_deplib_(static|dynamic)_flag='`
+if test

Re: per-deplib static/dynamic flags

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Mon, Jan 30, 2006 at 02:01:53PM CET:
> 
> I will followup to this mail (to libtool-patches only for size) with a
> patch to implement per-deplib flags for programs (for CVS HEAD) and add
> comprehensive tests for the static flags.

Here goes the per-deplib implementation.  The patch depends upon the
pending `-static-libtool-libs' patch and the `-static' hardcoding fix.
Comments and test results appreciated.

Tested with
- some GNU/Linux (also CC=g++),
- AIX 5.3 (rtl and non-rtl), 
- Solaris, GCC and Sun Studio 5.8.

All other platforms mentioned in _LT_LINKER_STATIC_DYNAMIC are basically
guesses, so please test and report back here or on the mentioned wiki
page.

OK to apply to HEAD?

Cheers,
Ralf

Implement per-deplib static/dynamic linking flags for programs.

* libltdl/config/ltmain.m4sh (help output, func_mode_link)
< -Bstatic, -Bdynamic >: New user flags to control per-deplib
linking mode for creating programs.  The flags may be specified
multiple times, are position-dependent, and set the preferred
linking mode for libraries following on the link line (including
pulled in dependencies).
* libltdl/m4/libtool.m4 (_LT_LINKER_STATIC_DYNAMIC): New
macro to specify new tag variables `per_deplib_static_flag'
and `per_deplib_dynamic_flag'.
(_LT_LANG_C_CONFIG, _LT_LANG_CXX_CONFIG, _LT_LANG_F77_CONFIG)
(_LT_LANG_FC_CONFIG, _LT_LANG_GCJ_CONFIG): Call it.
* doc/libtool.texi (Link mode): Document the new user flags.

diff -ur libtool/NEWS libtool2/NEWS
--- libtool/NEWS2006-01-30 18:33:32.0 +0100
+++ libtool2/NEWS   2006-01-30 18:34:21.0 +0100
@@ -31,6 +31,8 @@
 * Support for Interix 3 (Windows SFU).
 * Basic support for PIE (position-independent executables).
 * Initial support for RDOS.
+* Support for per-deplib linking flags `-Bstatic' and `-Bdynamic' when
+  creating programs.
 * Bug fixes.
 
 New in 1.9f: 2004-10-23; CVS version 1.9e, Libtool team:
diff -ur libtool/doc/libtool.texi libtool2/doc/libtool.texi
--- libtool/doc/libtool.texi2006-01-30 18:34:06.0 +0100
+++ libtool2/doc/libtool.texi   2006-01-30 18:34:21.0 +0100
@@ -1329,6 +1329,26 @@
 i.e.@: no version information is stored and no symbolic links are created.
 If the platform requires versioning, this option has no effect.
 
[EMAIL PROTECTED] -Bstatic
+If @var{output-file} is a program, prefer linking statically against the
+libraries following on the command line, if the linker allows to specify
+the preferred link [EMAIL PROTECTED] that depending on the system, this
+may link against shared @file{*.a} archives, for example on AIX without
+runtimelinking.}  This switch may be used multiple times and is reverted
+by @option{-Bdynamic}.  In case no suitable library of the preferred type
+is found, it is unspecified whether the link will fail or succeed with a
+library of different type.  It is usually necessary to reset the preferred
+link mode with @option{-Bdynamic} at the end of the command line so that
+system libraries are added correctly.
+
+If @var{output-file} is a library, or if @option{-Bstatic} or 
@option{-Bdynamic}
+and either one of @option{-static}, @option{-static-libtool-libs}, or
[EMAIL PROTECTED] are used together, the action is unspecified and may
+change in a future version.
+
[EMAIL PROTECTED] -Bdynamic
+This switch undoes @option{-Bstatic}, see there for more information.
+
 @item -dlopen @var{file}
 Same as @option{-dlpreopen @var{file}}, if native dlopening is not
 supported on the host platform (@pxref{Dlopened modules}) or if
diff -ur libtool/libltdl/config/ltmain.m4sh libtool2/libltdl/config/ltmain.m4sh
--- libtool/libltdl/config/ltmain.m4sh  2006-01-30 18:34:06.0 +0100
+++ libtool2/libltdl/config/ltmain.m4sh 2006-01-30 18:34:21.0 +0100
@@ -327,6 +327,8 @@
 
   -all-static   do not do any dynamic linking at all
   -avoid-versiondo not add a version suffix if possible
+  -Bstatic  prefer static linking for following libraries
+  -Bdynamic prefer dynamic linking for following libraries
   -dlopen FILE  \`-dlpreopen' FILE if it cannot be dlopened at runtime
   -dlpreopen FILE   link in FILE and add its symbols to lt_preloaded_symbols
   -export-dynamic   allow symbols from OUTPUT-FILE to be resolved with dlsym(3)
@@ -2205,8 +2207,10 @@
 no_install=no
 objs=
 non_pic_objects=
+per_deplib_static=no
 precious_files_regex=
 prefer_static_libs=no
+prefer_static_mode=default
 preload=no
 prev=
 prevarg=
@@ -2263,6 +2267,9 @@
build_old_libs=yes
break
;;
+  -Bstatic | -Bdynamic)
+per_deplib_static=yes
+   ;;
   esac
 done
 
@@ -2530,6 +2537,9 @@
   case $arg in
   -all-static)
# The effects of -all-static are defined in a previous loop.
+   if test "$per_deplib_static" = yes; then
+ func_fatal_error "

per-deplib static/dynamic flags

[Ralf Wildenhues]

The 1.5.20 regression fix for `-static' for programs has made it clear
that per-deplib static/shared flags are desirable for libtool.

I will followup to this mail (to libtool-patches only for size, removing
all Cc:s) with a patch to implement per-deplib flags for programs (for
CVS HEAD) and add comprehensive tests for the static flags.

Notes and open questions:

- The patch depends upon the pending `-static-libtool-libs' patch[1].
  The new tests exercises all the added flags (this is how this patch
  got started).

- I have added the flag names for various systems of which I could grab
  some documentation; the corresponding list is certainly incomplete
  and too broad in some cases; help is much appreciated to refine this.[2]

- Note semantics vary between preferred and forced linking in either
  type.  For now the patch only offers (and chooses) to prefer rather
  than to force one linkage mode, if possible; the documentation should
  allow us to fix this later if desirable.  We could instead also allow
  a kind of fat interface of the form
-Bprefer-static -Bprefer-dynamic -Bforce-static -Bforce-dynamic -Bdefault

  (the naming is obviously open to improvement)
  and state that we may be able to control this for libtool libraries,
  but for non-libtool ones only on systems with linkers that have this
  functionality.

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

- All non-libtool uses of per-deplib flags I know of may be prefixed
  with a linker prefix `$wl'.  Should libtool go to the lengths to also
  detect and treat
${wl}-Bstatic ${wl}-Bdynamic
  and also these (possibly different!)
-Wl,-Bstatic -Wl,-Bdynamic
  or even these
-Wc,-Bstatic -Wc,-Bdynamic
  as identical to the non-prefixed ones?

The latter question is connected to how Makefiles should be written that
deal with both libtool and non-libtool links, and scripts such as GCCs
libtool-ldflags to deal with this.[3]

Apologies for letting other pending items slip a bit for this one. ;-)

Cheers,
Ralf

[1] http://thread.gmane.org/gmane.comp.gnu.libtool.general/7097
[2] http://tkd.kicks-ass.net/GnuLibtoolProject/FeatureRequests/PerDeplibFlags
[3] http://gcc.gnu.org/ml/libstdc++/2005-07/msg00067.html
http://gcc.gnu.org/ml/libstdc++/2005-12/msg00261.html