Re: per-deplib static/dynamic flags

2006-02-02 Thread 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

2006-02-02 Thread 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

2006-02-02 Thread 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 http://www.opendarwin.org/projects/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

2006-02-02 Thread 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 http://www.opendarwin.org/projects/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-


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

Re: per-deplib static/dynamic flags

2006-02-01 Thread 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

2006-02-01 Thread 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

2006-02-01 Thread 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

2006-02-01 Thread 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

2006-02-01 Thread 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/


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

Re: per-deplib static/dynamic flags

2006-02-01 Thread 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


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

Re: per-deplib static/dynamic flags

2006-01-31 Thread 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])

Re: per-deplib static/dynamic flags

2006-01-31 Thread 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

2006-01-31 Thread 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])


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