From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2002-10-16 14:07:39
Vladimir Prus wrote:
> Markus Schöpflin wrote:
>> David Abrahams wrote:
>>> And given recent discussions on this list about GCC, it might
>>> be neccessary to represent "link to this one statically" or
>>> "link to this one dynamically", somehow...
>> I think this facility is absolutely essential. I usually have the
>> requirement to link to all the system libraries dynamically but
>> link statically to all the rest. (See our previous discusion
> For your specific use case, we can have <runtime-link> affect
> linking of system libraries, while <shared> will affect user
> lib my : a.cpp ;
> exe hello : hello.cpp my : <find-library>pcre ;
> Given this Jamfile, you can call
> bjam shared=false runtime-link=dynamic
> And "pcre" will be dynamically linked, while "my" will be static
Don't you think that this will confuse most users? And isn't that
supported already for jam built libraries with <lib>my or <dll>my?
> For a more general case, we might try <find-library-static> and
I think we absolutely need this. In the use case I mentioned above the
system libs are libm and libc and the libs I have to link to
statically are libs like openssl or libz which aren't build by
> Note that for use libraries, you can have this already:
> exe hello : hello.cpp my/<shared>false ;
> Will cause static linked version of "my" to be used, whatever build
> request is.
Good to know.
There is another use case I have: Linking to oracle libs. On most
platforms, you _have_ to specify very exactly what get's linked and
how. Currenty I'm using the fact that a rule name can appear as the
prerequisite of a target. For example:
exe hello : hello.cpp : link_to_oracle_libs ;
and link_to_oracle_libs is a rule which inserts the right things in
the linker command line depending on the current build settings and
platform. It would be great if something like this would be supported
in v2 as well.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk