Improving --layout=system

Caleb Epstein wrote:
> lrwxrwxrwx 1 cepstein   33 Aug  2 13:44
libboost_date_time-mt-d.so -> 
> libboost_date_time-mt-d.so.1.35.0
> -rwxrwxr-x 1 cepstein 388K Aug  2 13:44
libboost_date_time-mt-d.so.1.35.0
> lrwxrwxrwx 1 cepstein   31 Aug  2 13:44
libboost_date_time-mt.so -> 
> libboost_date_time-mt.so.1.35.0
> -rwxrwxr-x 1 cepstein  52K Aug  2 13:44
libboost_date_time-mt.so.1.35.0
> ...

This sounds very reasonable.

Btw.: I have a question about static linking.
Do you know how this is supposed to happen on linux?

I mean the -lmylib AFAIK always will choose the .so in
favour of the .a.
Is there a way to force static linking?

Thank you
Roland

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Roland Schwarz wrote, on 8/2/2007 2:45 PM:
> Caleb Epstein wrote:
>   
>> lrwxrwxrwx 1 cepstein   33 Aug  2 13:44
libboost_date_time-mt-d.so -> 
>> libboost_date_time-mt-d.so.1.35.0
>> -rwxrwxr-x 1 cepstein 388K Aug  2 13:44
libboost_date_time-mt-d.so.1.35.0
>> lrwxrwxrwx 1 cepstein   31 Aug  2 13:44
libboost_date_time-mt.so -> 
>> libboost_date_time-mt.so.1.35.0
>> -rwxrwxr-x 1 cepstein  52K Aug  2 13:44
libboost_date_time-mt.so.1.35.0
>> ...
>>     
>
> This sounds very reasonable.
>
> Btw.: I have a question about static linking.
> Do you know how this is supposed to happen on linux?
>
> I mean the -lmylib AFAIK always will choose the .so in
favour of the .a.
> Is there a way to force static linking?
>
> Thank you
> Roland

The gcc toolset (and msvc, for that matter) puts the paths
to the static 
libraries on the link line instead of using the
"-l" option 
("../../bin/gcc/release/link-static/mylib.a"
instead of "-lmylib", e.g.).

Phillip
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Thanks for providing this. I've been using a hacked patch
for a long
while now to do this when building rpms.

Just for kicks I attached another patch I use that modifies
the
optimization levels a little:
off = -O0, basic=-O1, speed=-O2, space=-Os, insane=-O3

This makes release variants default to -O2 since in some
cases the
aggressive loop unrolling and inlining in -O3 hinders
instead of
helps.

Chris

On 8/2/07, Caleb Epstein <caleb.epsteingmail.com> wrote:
> On systems that support shared library version numbers,
I believe that these
> should be used even when building with
--layout=system.
>
> At present, when you build Boost with --layout=system,
you end up with
> libraries called libboost_xyz-mt.so that have this same
value set at their
> ELF SONAME (this is the shared library version number
embedded into the
> library itself).
>
> The problem with these libraries is that you can never
have multiple
> versions of them installed side-by-side in the same
place. Go too far down
> this road and you end up with Windows-style 'DLL
hell'.
>
> If instead the BOOST_VERSION is appended to the target
name as it is with
> --layout=versioned, you end up with SONAME'd libraries
that can live
> side-by-side with earlier/later versions of Boost.
>
> For example, by adding the version number to the
libraries, you end up with
> a lib directory that looks like:
>
> lrwxrwxrwx 1 cepstein   33 Aug  2 13:44
libboost_date_time-mt-d.so ->
> libboost_date_time-mt-d.so.1.35.0
> -rwxrwxr-x 1 cepstein 388K Aug  2 13:44
libboost_date_time-mt-d.so.1.35.0
>  lrwxrwxrwx 1 cepstein   31 Aug  2 13:44
libboost_date_time-mt.so ->
> libboost_date_time-mt.so.1.35.0
>  -rwxrwxr-x 1 cepstein  52K Aug  2 13:44
libboost_date_time-mt.so.1.35.0
> ...
>
> Now when you link applications using
-lboost_date_time-mt, the linker
> records the dependency on the library's SONAME, which
is
> libboost_date_time_mt.so.1.35.0.  No other name will
satisfy this runtime
> dependency.  As a result, you can install the
(hypothetical) Boost 1.36.0
> libs into the same directory and old applications will
continue to pick up
> the *.so.1.35.0 libs correctly, while new applications
built when the
> symlink points to the new library versions will pick up
*.so.1.36.0.
>
> This is how Boost.Build v1 handled --layout=system and
I believe this is the
> most correct and desirable behavior for platforms that
support versioned
> shared libraries.  Attached is my simple patch against
the latest SVN trunk
> to make this work.
>
> --
> Caleb Epstein
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost-build
>
>
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build