Re: [jamboost] Re: v2: gcc and static linking

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-09-22 07:23:13

Hi Andre,

sorry it took a while to get back to you.

> > What about using fully static linking with
> >
> > bjam link=statuc link-runtime=static
> >
> > ?
>
> The issue is more complex than that. First, I need to be selective
> about what gets linked statically, which is doable. Second, "link=static
> link-runtime=static" also links statically against the libc and does not
> allow me to use libsup++ (instead of libstdc++).

You mean, different versions of libc is not a problem for you? And linking to 
libc statically does not work with libsup++

> >>	Yes, that's what I have in mind. If I use <find-static-library>, I
> >>expect it to fail if there's no libwhatever.a. In fact, -Bstatic is
> >>linker-specific, not platform-specific.
> >
> > Anyway, I don't really like feature which works only sometimes and on
> > some linkers. Maybe, <linkflags> is better.
>
> Using <linkflags> to link a library is a bit awkward. For starters, I
> don't think I can control library ordering that way. 

Yes, it a bit awkward, but then, you're trying to use a feature which is only 
available on gcc/unix. On other toolsets, you can't force static linking to a 
library. 

About library ordering: yes, <linkflags> won't assure right order. But 
<find-library> won't do this either. Only 'lib' targets allow to specify 
order dependencies.

I should note that we can only generate command line line this

<static libraries generated by boost.build> 
-Wl,-Bstatic -lstatic_library_1, -Wl,-Bstatic_library2

I.e. searched libraries will be always after those created by Boost.Build. I 
guess that's OK? 

Anyway, I believe that in your case library order is not an issue? If so, I'd 
recomment using linkflags for a while, until more users come complaining.

If they come, the right thing to do, IMO, would be
1. Drop <find-shared-library> and <find-static-library>, as they are not 
symmetric and platfrom-specific.
2. Add a new '<force-static-link>' feature. The name more accurately reflects 
the behaviour of -Wl,-Bstatic

> Also, what would be 
> the point of <find-static-library>, then?

I think it should be removed.

> >>That is also the case for
> >>"-Wl,-R", "-Wl,-h", "-Wl,-rpath-link" and "-Wl,--strip-all". I'm
> >>updating my BB setup and haven't got to solaris yet but I believe
> >>--strip-all is going to cause problems.
> >
> > I don't think we use it in V2.
>
> We do. In fact, it just failed for me on solaris (with sun's LD).
> According to the comments in the code, --strip-all is there because icc
> doesn't understand -s.

Understood.

> >>-rpath-link is also potentialy
> >>problematic but I'm not using it so it's not a biggie.
> >
> > I think we have this issue solved on solaris, anyway.
>
> I don't see how it was solved but again I don't use that feature.
> gcc.jam does say "-Wl,-rpath-link" and last time I checked sun's LD
> does not accept that.

The story is that gcc.jam has:

-Wl,-rpath-link$(SPACE)-Wl,"$(RPATH_LINK)"

and RPATH_LINK is always empty on sun. That's a recent fix.

> Volodya, allow me to suggest something along the lines of the attached
> patch for consideration. I'll happily polish it if people believe it
> represents a good alternative. It allows the compiler configuration to
> be done like this:
>
> using gcc : : : : <linker>sun ;
>
> And <linker> default to gnu. It may also be possible to automagically
> figure out which linker is being used by gcc. The whole point is that
> compiler and linker options are orthogonal.

This is a good idea. In fact, some other questions, like "is this cygwin or 
mingw, or what version of gcc", can be easily answered with additional 
options to "using". 

+# Goes throuh the given-options and find one that matched
+# <option-name>value. Returns 'value' if found or $(default)
+# otherwise.
+rule get-option ( toolset : option-name : default : given-options ? )
+{
+ local value = $(default) ;
+ for local opt in $(given-options)
+ {
+ if $(opt:G) = "<$(option-name)>"
+ {
+ value = $(opt:G=) ;
+ }
+ }
+ return $(value) ;
+}
+

What's the point of 'toolset' parameter? I don't see it being used in the rule 
body.

Also, I think this rule is better defined be 'common.get-toolset-option', 
since it's not necessary gcc-specific. Otherwise, your patch looks fine and 
I'll be happy to apply it once we solve the above question.

Thanks,
Volodya