Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Right now there's no version info on the .so's. Going forward with .so version info that's unique, it won't. :) -sc -- Sean Chittenden On Oct 29, 2009, at 12:51 PM, Vladimir Prus wrote: Sean Chittenden wrote: /usr local lib boost-1.40.0 boost-1.41.0 boost -> boost-

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Sean Chittenden wrote: >>> /usr >>> local >>> lib >>> boost-1.40.0 >>> boost-1.41.0 >>> boost -> boost-1.41.0 >>> >>> Lazy developers will use boost and not boost-1.40.0 and suddenly >>> things will break in strange, hard to figure out ways. >> >> Could you clarify what wil

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

2009/10/29 Sean Chittenden > I'm still coming up to speed on boost's convention for micro versions, but > couldn't the SONAME be set to "*.so.1.41" instead of "*.1.41.0" ? > > -sc > That makes a lot of sense (at least to me), of course. But, as Volodya suggests, there is no guarantee that "ups

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Boost has no separate interface and implementation versions, so it may be best to just set the VERSION property on all libraries and no SOVERSION (or vice-versa...each defaults to the other). Then CMake will only create libboost.so -> libboost.so.1.41.0 libboost.so.1.41.0 and the SONAME

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Denis Arnaud wrote: > > 2009/10/28 Vladimir Prus > > > This might be obvious, but such a soname would be wrong if the above > naming > of libraries is used, since there would be no > libboost_date_time-mt.so.4. > > - Volodya > > > I've jus

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

/usr local lib boost-1.40.0 boost-1.41.0 boost -> boost-1.41.0 Lazy developers will use boost and not boost-1.40.0 and suddenly things will break in strange, hard to figure out ways. Could you clarify what will break? The usual suspects for dynamic linker issues. It's

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

2009/10/28 Vladimir Prus > This might be obvious, but such a soname would be wrong if the above naming > of libraries is used, since there would be no libboost_date_time-mt.so.4. > > - Volodya > I've just checked what Debianers do. Currently, they set the soname to match the full library name (w

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Ingmar Vanhassel wrote: > Excerpts from troy d. straszheim's message of Wed Oct 28 21:23:26 +0100 2009: >> Ingmar Vanhassel wrote: >> > Excerpts from Sean Chittenden's message of Wed Oct 28 21:08:19 +0100 2009: >> Avoid pkg-config, it's very Linux and drags in a ton of dependencies >> (m

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Denis Arnaud wrote: > 2009/10/28 troy d. straszheim > >> Would it be possible to have the option, with CMake build, to use a >>>more conventional soname, so that Linux distribution packagers >>>(Debianers and RPM-based packagers such as me, for instance) be >>>happy (i.e., have l

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Sean Chittenden wrote: >> For sure it is. Debian is my primary platform and I'd like this to >> be seamless. I've pondered support for multiple simultaneous >> installations, possibly with a layout like this: > > Because of the trickery of the loader using unresolved symlinks (for > non-statica

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

2009/10/28 troy d. straszheim > And the soname would read something like: >> $ readelf -a /usr/lib/libboost_date_time-mt.so | grep -i soname >> 0x000e (SONAME) Library soname: >> [libboost_date_time-mt.so.4] >> (that example is taken from Fedora 11, with Boost 1.37.0; the

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Michael Jackson wrote: > This is THE SINGLE IMPROVEMENT someone could make for those of us using > CMake and are dependent on the boost libraries. Finding Boost with CMake > is historically a pain and is extremely error prone. There is no support > for future versions in the current FindBoost. You

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Excerpts from troy d. straszheim's message of Wed Oct 28 21:23:26 +0100 2009: > Ingmar Vanhassel wrote: > > Excerpts from Sean Chittenden's message of Wed Oct 28 21:08:19 +0100 2009: > Avoid pkg-config, it's very Linux and drags in a ton of dependencies > (most of the time, never required

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

gettext-0.17_1 gmake-3.81_3 libiconv-1.13.1 I'm fairly sure you can --disable-nls to get rid of gettext & libiconv. pkgconfig has a tendency to suck in other gnome projects due to its gnome lineage. Ugh. If you're referring to its limited use of glib, you can disable this too, and it'll

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Denis Arnaud wrote: 2009/10/28 troy d. straszheim > Would it be possible to have the option, with CMake build, to use a more conventional soname, so that Linux distribution packagers (Debianers and RPM-based packagers such as m

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Ingmar Vanhassel wrote: Excerpts from Sean Chittenden's message of Wed Oct 28 21:08:19 +0100 2009: Avoid pkg-config, it's very Linux and drags in a ton of dependencies (most of the time, never required, but that's the way it goes with everyone's packaging system of choice). A cmake variable wou

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Excerpts from Sean Chittenden's message of Wed Oct 28 21:08:19 +0100 2009: > >> Avoid pkg-config, it's very Linux and drags in a ton of dependencies > >> (most of the time, never required, but that's the way it goes with > >> everyone's packaging system of choice). A cmake variable would be > >> p

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Avoid pkg-config, it's very Linux and drags in a ton of dependencies (most of the time, never required, but that's the way it goes with everyone's packaging system of choice). A cmake variable would be preferred, imo (similar to the cmake boost version foo). -sc So let's make pkg-config opt-in

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

2009/10/28 troy d. straszheim > Would it be possible to have the option, with CMake build, to use a >>more conventional soname, so that Linux distribution packagers >>(Debianers and RPM-based packagers such as me, for instance) be >>happy (i.e., have less extra code to write)? >>

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Denis ARNAUD wrote: 2009/10/28 Denis ARNAUD > [...] Would it be possible to have the option, with CMake build, to use a more conventional soname, so that Linux distribution packagers (Debianers and RPM-based packagers such as me, for instance)

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Excerpts from Sean Chittenden's message of Wed Oct 28 20:39:59 +0100 2009: > Avoid pkg-config, it's very Linux and drags in a ton of dependencies > (most of the time, never required, but that's the way it goes with > everyone's packaging system of choice). A cmake variable would be > preferr

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

This is THE SINGLE IMPROVEMENT someone could make for those of us using CMake and are dependent on the boost libraries. Finding Boost with CMake is historically a pain and is extremely error prone. There is no support for future versions in the current FindBoost. You can take a guess, but t

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

For sure it is. Debian is my primary platform and I'd like this to be seamless. I've pondered support for multiple simultaneous installations, possibly with a layout like this: Because of the trickery of the loader using unresolved symlinks (for non-statically linked apps, but who does th

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Denis ARNAUD wrote: Hello, from what I understand by reading that thread (title: "**Re: [Boost-build] Help deciphering gcc.jam, please* *", in April 2004

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

2009/10/28 Denis ARNAUD > [...] > Would it be possible to have the option, with CMake build, to use a more > conventional soname, so that Linux distribution packagers (Debianers and > RPM-based packagers such as me, for instance) be happy (i.e., have less > extra code to write)? > Last year, Ste