
Hi, Suppose two systems, a Fedora based on gcc 4.1 and a Debian based on gcc 4.2, both sporting Boost 1.35.0 built with --layout=system, for simplicity. Now Joe User writes his app on the Fedora system and links Boost.DateTime using the familiar -lboost_date_time switch. He builds the app and tries it on both his Fedora system and the friend's Debian one. What is going to happen? BTW, the user is a free software developer and his app is going to be ported also to other Microsoft, UNIX and popular embedded operating systems, where Boost has been built mixing --layout=system and --layout=versioned. Now he faces the problem of linking to the Boost library of interest. How he is supposed to solve the problem? This is a new summary of the binary and source portability problems that current build system is inflicting on the Boost libraries. My proposal is: 1) dump the --layout= thing, versioned/decorated sonames are always used 2) provide symlinks like the following, when appropriate: /usr/lib/libboost_date_time-gcc42-1_34_1.so -> libboost_date_time-gcc42-1_34_1.so.1.34.1 /usr/lib/libboost_date_time-gcc42-d-1_34_1.so -> libboost_date_time-gcc42-d-1_34_1.so.1.34.1 /usr/lib/libboost_date_time-gcc42-mt-1_34_1.so -> libboost_date_time-gcc42-mt-1_34_1.so.1.34.1 /usr/lib/libboost_date_time-gcc42-mt-d-1_34_1.so -> libboost_date_time-gcc42-mt-d-1_34_1.so.1.34.1 3) provide also these symlinks, if desired: /usr/lib/libboost_date_time.so -> libboost_date_time-gcc42-1_34_1.so /usr/lib/libboost_date_time-d.so -> libboost_date_time-gcc42-d-1_34_1.so /usr/lib/libboost_date_time-mt.so -> libboost_date_time-gcc42-mt-1_34_1.so /usr/lib/libboost_date_time-mt-d.so -> libboost_date_time-gcc42-mt-d-1_34_1.so 4) add more decorations as required. e.g. Python version to Boost.Python library name. This way multiple Boost.Python libraries, every built with a different Python version, could coexist on the same system. 5) provide a program, say boost-config, that may be invoked to find the right build parameters for a given library, toolset and variant(s). some examples (suppose default compiler is gcc 4.0, the one used to build Boost): $ boost-config --name=DateTime --ldflags -lboost_date_time-gcc40-1_34_1 $ boost-config --name=DateTime --toolset=gcc-4.1 --variant=mt,d --ldflags -lboost_date_time-gcc41-mt-d-1_34_1 $ boost-config --name=Threads --toolset=gcc-4.2 --ldflags -lboost_threads-gcc42-mt-1_34_1 $ boost-config --name=DateTime --toolset=gcc-4.2 --variant=python-2.5 --ldflags Error: unknown variant python-2.5 for the given library $ boost-config --name=Python --variant=python-2.4 --ldflags -lboost_python-gcc40-python24-1_34_1 $ boost-config --name=Python --toolset=gcc-4.2 --variant=python --cxxflags -I/usr/include/python if toolset is omitted, the default system compiler is used, if any (e.g. cc/c++ under linux), otherwise an error is reported. Point 1) is really optional. In case --layout is kept, the subsequent points would be related only to --layout=versioned and --layout=system should be documented as source of any sort of portability issues. Point 2) is required only on UNIX systems where GNU ld is used, it might have not sense with other linkers. Every linker has its own story. Point 3) is applicable only where 2) is and would be handy only when source portability is not an issue, to the user discretion. Big warning about source portability should be placed nearby its documentation. Point 4) would allow packaging Boost.Python on distributions in which multiple versions of Python may be available. Point 5) is the way to the complete source portability, at least across sane systems (read, probably not Windows/MSVC). Note that if Boost is built using a compiler different from the one asked to boost-config, the linker will complain about the inexistent library. It would be easy to make boost-config extract allowed parameter combinations from an XML file built by Boost.Build at build time. That's all, good night. Domenico -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

Domenico Andreoli wrote:
Hi,
Suppose two systems, a Fedora based on gcc 4.1 and a Debian based on gcc 4.2, both sporting Boost 1.35.0 built with --layout=system, for simplicity.
Now Joe User writes his app on the Fedora system and links Boost.DateTime using the familiar -lboost_date_time switch. He builds the app and tries it on both his Fedora system and the friend's Debian one. What is going to happen?
What is going to happen? It sounds like you've omitted some part of your email. - Volodya

Martin Wille wrote:
Vladimir Prus wrote:
What is going to happen? It sounds like you've omitted some part of your email.
The message looks complete here.
Let me clarify -- the message goes like this:
Now Joe User writes his app on the Fedora system and links Boost.DateTime using the familiar -lboost_date_time switch. He builds the app and tries it on both his Fedora system and the friend's Debian one. What is going to happen?
BTW, ....
So either "What is going to happen?" is a question to recipients of the email (and I don't know what exactly is being asked), or Domenico meant do tell what is going to happen, but did not. The only reason why said app won't work on one of the systems is possibly binary incompatibility between gcc/libstdc++/libc, which is probably not what's being discussed. - Volodya

Vladimir Prus wrote:
Martin Wille wrote:
Vladimir Prus wrote:
What is going to happen? It sounds like you've omitted some part of your email.
The message looks complete here.
Let me clarify -- the message goes like this:
Now Joe User writes his app on the Fedora system and links Boost.DateTime using the familiar -lboost_date_time switch. He builds the app and tries it on both his Fedora system and the friend's Debian one. What is going to happen?
BTW, ....
So either "What is going to happen?" is a question to recipients of the email (and I don't know what exactly is being asked), or Domenico meant do tell what is going to happen, but did not.
Oh, I see. I considered it a rethoric question: the application won't work without recompiling because the (dynamically linked) Boost libraries won't be found. Of course, it wouldn't work even if those libraries were found on the other system, because the libraries are not binary compatible. There are at least two solutions for the OP: 1. embed Boost into your software. This seems to be a common practice. Not desirable on embedded systems. 2. write a script that configures your software for the target system. This isn't an extremely difficult, even without a boost-config script, except, maybe, for finding the versions of libraries used by Boost (Python, ICU, etc). Regards, m

Martin Wille wrote:
Vladimir Prus wrote:
Martin Wille wrote:
Vladimir Prus wrote:
What is going to happen? It sounds like you've omitted some part of your email.
The message looks complete here.
Let me clarify -- the message goes like this:
Now Joe User writes his app on the Fedora system and links Boost.DateTime using the familiar -lboost_date_time switch. He builds the app and tries it on both his Fedora system and the friend's Debian one. What is going to happen?
BTW, ....
So either "What is going to happen?" is a question to recipients of the email (and I don't know what exactly is being asked), or Domenico meant do tell what is going to happen, but did not.
Oh, I see. I considered it a rethoric question: the application won't work without recompiling because the (dynamically linked) Boost libraries won't be found.
Err, if --layoyt=system does not include toolset name in library path, the libraries will be found.
Of course, it wouldn't work even if those libraries were found on the other system, because the libraries are not binary compatible.
It depends, generally speaking. And in any case, that's independent from the naming issue, that why I'm not sure what's being asked. - Volodya

I believe this proposal is relevant to the discussion on http://lists.debian.org/debian-release/2007/07/msg00293.html

On Sat, Aug 04, 2007 at 11:02:42PM +0800, manphiz wrote:
I believe this proposal is relevant to the discussion on
http://lists.debian.org/debian-release/2007/07/msg00293.html
This is the follow-up of the Debian Release Manager: http://lists.debian.org/debian-release/2007/08/msg00016.html BTW, I just finished the Boost 1.34.1-1 package for experimental in order to start a better transition. I readded default symlinks to let people link _single-thread_ libraries simply using switches like -lboost_date_time, while for the multi-thread ones -lboost_date_time-mt is still required. It looks like users can't live without them. Evidently source portability is not such a hot-topic for many. I cannot care less, now it is their problem. Cheers, Domenico -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

On Sat, Aug 04, 2007 at 07:55:26AM +0200, Martin Wille wrote:
Vladimir Prus wrote:
Martin Wille wrote:
Vladimir Prus wrote:
What is going to happen? It sounds like you've omitted some part of your email.
The message looks complete here.
Let me clarify -- the message goes like this:
Now Joe User writes his app on the Fedora system and links Boost.DateTime using the familiar -lboost_date_time switch. He builds the app and tries it on both his Fedora system and the friend's Debian one. What is going to happen?
BTW, ....
So either "What is going to happen?" is a question to recipients of the email (and I don't know what exactly is being asked), or Domenico meant do tell what is going to happen, but did not.
Oh, I see. I considered it a rethoric question: the application won't work without recompiling because the (dynamically linked) Boost libraries won't be found.
Of course, it wouldn't work even if those libraries were found on the other system, because the libraries are not binary compatible.
There are at least two solutions for the OP:
1. embed Boost into your software. This seems to be a common practice. Not desirable on embedded systems.
I don't think people is very eager to build Boost from scratch. IMHO this is a common practice because is still more difficult to manage correct Boost installations respect to other libraries. Boost was clearly not thought to be packaged and installed to make 3rd party use it. I also tried to use Boost.Build to build my software in the hope it would have correctly managed decorations but it does not work this way out of the Boost source tree.
2. write a script that configures your software for the target system. This isn't an extremely difficult, even without a boost-config script, except, maybe, for finding the versions of libraries used by Boost (Python, ICU, etc).
Free software world had this kind of problems and some "standard" solutions have been developed right to stop people reinventing the wheel. Moreover, it frequently happens that some library build flags have to be used also at application build time, so the library user need to have a way to figure them out. -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

On Sat, Aug 04, 2007 at 09:41:05AM +0400, Vladimir Prus wrote:
Martin Wille wrote:
Vladimir Prus wrote:
What is going to happen? It sounds like you've omitted some part of your email.
The message looks complete here.
Let me clarify -- the message goes like this:
Now Joe User writes his app on the Fedora system and links Boost.DateTime using the familiar -lboost_date_time switch. He builds the app and tries it on both his Fedora system and the friend's Debian one. What is going to happen?
BTW, ....
So either "What is going to happen?" is a question to recipients of the email (and I don't know what exactly is being asked), or Domenico meant do tell what is going to happen, but did not.
The only reason why said app won't work on one of the systems is possibly binary incompatibility between gcc/libstdc++/libc, which is probably not what's being discussed.
I was referring to this reason. I find that fully decorated names are a wanted feature to achieve sane binary portability. The case I mentioned might even run but crash subtly. If instead the toolset was encoded in the library name, app would not even run, saving the user from the debugger. This is a binary compatibility issue induced by current --layout=system. -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
participants (5)
-
Domenico Andreoli
-
Domenico Andreoli
-
manphiz
-
Martin Wille
-
Vladimir Prus