On 5/13/2013 10:09 AM, Mathias Gaunard wrote:

On 13/05/13 14:08, Andrey Semashev wrote:

...

I would like to hear opinions on the possible course of action to tackle this problem. Currently, I see 2 choices:

1. Avoid using C++11 features in binary interfaces. This may also mean avoiding STL types in binary interfaces, if they differ between C++03 and C++11 (I didn't verify that). This is my suggested hotfix solution for Boost.Filesystem [1] and the approach I took in Boost.Log. Obviously, this cripples code and error prone, but it keeps a single binary that can be used from any flavor of C++ on the user's side. 2. Compile different versions of Boost libraries, for each supported C++ version. The C++ version should be encoded into the library file names, so that different versions can coexist. This would require changes in Boost.Build and autolinking support code, but I think this would be a better long-term solution.

Opinions?

[1] https://svn.boost.org/trac/boost/ticket/6779

I prefer [1].

Does boost ever claim support for abi compatibility with different compiler settings? I thought not. If there needs to be a change beyond users just building the version they actually need, I would prefer 2. Binding Boost to C++03 seems counter to Boost's stated goals.

On Monday 13 May 2013 18:26:38 Klaim - Joël Lamotte wrote:

On Mon, May 13, 2013 at 5:29 PM, Michael Marcin wrote:

...

Does boost ever claim support for abi compatibility with different compiler settings? I thought not.

I thought boost explicitely, somewhere, stated that binary compatibility is not a requirement for libraries. I remember it being the main argument for developing "booster" which is a "fixed" set of boost libraries used in CPPCMS.

I think that was about binary compatibility between different releases of Boost or its libraries. It's a bit different from compatibility between single release builds for different C++ versions. Speaking of different releases, Boost does mangle library names with the release version, so linked applications will always use the correct binaries. This counts in favor for the solution (2), with mangling library names differently in C++03 and C++11.

On Monday 13 May 2013 15:35:06 Michael Marcin wrote:

On 5/13/13 12:21 PM, Andrey Semashev wrote:

...

On Monday 13 May 2013 18:26:38 Klaim - Joël Lamotte wrote:

...

On Mon, May 13, 2013 at 5:29 PM, Michael Marcin

wrote:

...

...

Does boost ever claim support for abi compatibility with different compiler settings? I thought not.

I thought boost explicitely, somewhere, stated that binary compatibility is not a requirement for libraries. I remember it being the main argument for developing "booster" which is a "fixed" set of boost libraries used in CPPCMS.

I think that was about binary compatibility between different releases of Boost or its libraries. It's a bit different from compatibility between single release builds for different C++ versions.

Speaking of different releases, Boost does mangle library names with the release version, so linked applications will always use the correct binaries. This counts in favor for the solution (2), with mangling library names differently in C++03 and C++11.

There are also parameters where the names do not encoding important settings. If the code is compiled for x86 or x64 for instance. The user is just expected to build and use the libraries they need.

Libraries for different architectures are installed into different system folders, so it's not a problem. Surely there are compiler options that affect ABI and do not get encoded in the file names. Things like stack alignment and calling conventions are far from being commonly changed in projects, and if they are people know the caveats. C++ flavor is another kind of option. You should typically _expect_ more and more people enable C++11, despite the fact it's not the default on current systems. And, IMHO, Boost should honor and help that trend.

On Monday 13 May 2013 19:14:16 Michael Marcin wrote:

On 5/13/13 3:47 PM, Andrey Semashev wrote:

...

Libraries for different architectures are installed into different system folders, so it's not a problem.

Not on windows.

There is no common place for libraries on Windows, so you can arrange them the way you like for your project.

On Tue, May 14, 2013 at 11:06:34AM +0200, Mathias Gaunard wrote:

On 14/05/13 05:21, Andrey Semashev wrote:

...

On Monday 13 May 2013 19:14:16 Michael Marcin wrote:

...

On 5/13/13 3:47 PM, Andrey Semashev wrote:

...

Libraries for different architectures are installed into different system folders, so it's not a problem.

Not on windows.

There is no common place for libraries on Windows, so you can arrange them the way you like for your project.

There is a common place for dlls, and it is indeed two different directories for 32 and 64 bit.

Noting of course that system32 and syswow64 are completely off limits to end users and end user applications. Anyone who puts anything in there in this day and age I will personally keelhaul for polluting system directories. It's bad enough that people pollute the %PATH% with DLLs, keep them out of the system directories. The recommended way to deploy third party libraries is to bundle them in the application directory and keep them out of %PATH%. -- Lars Viklund | zao@acc.umu.se

On 13/05/13 22:35, Michael Marcin wrote:

There are also parameters where the names do not encoding important settings. If the code is compiled for x86 or x64 for instance. The user is just expected to build and use the libraries they need.

A linker will automatically reject linking together code that was built for two different incompatible architectures

On Monday 13 May 2013 10:29:47 Michael Marcin wrote:

Does boost ever claim support for abi compatibility with different compiler settings? I thought not.

If there needs to be a change beyond users just building the version they actually need, I would prefer 2.

Binding Boost to C++03 seems counter to Boost's stated goals.

Building and distributing custom builds of libraries with applications is typical in Windows but not in Linux. And with the current state of affair applications cannot use Boost libraries in C++11 mode, which also contradicts Boost goals. I'm not advocating for solution (1) here, I'm just saying that custom builds are not the answer in this case, IMHO.

[Jürgen Hunold]

(Un-)fortunately, msvc just enables c++11 features by default without any switches.

That's definitely a "fortunately". If VC's compiler or STL had C++03 modes, that'd be yet another thing for you to worry about. This is a deliberate design choice.

But as the msvc runtimes are ABI-incompatible from version to version, this should be a non-issue for msvc users.

Yep. VC's STL absolutely forbids mixing different major versions. Stephan T. Lavavej Visual C++ Libraries Developer

On 13/05/13 23:26, Vicente J. Botet Escriba wrote:

I'm completely against option 1, it would kill Boost.

Why would it kill Boost? Binary interfaces are purely implementation details. There is no problem lowering them to C++03 while still exposing C++11 features to the user or using C++11 internally.

On 14/05/13 00:23, Vicente J. Botet Escriba wrote:

The binaries not only can not use c++11 features in their interface, them can not use any class or function that can have a different form on C++11 or C++03.

They can as long as it's not on the ABI boundary.

I would say that it could be good if a library author follows this advice, but I would not require it.

Of course this would not need to apply to libraries that are C++11-only.

Did you ever get anywhere with this? This issue has bitten me now, and I would really like to avoid having to build custom boost versions on Linux. The ease of installation when using the distro repos is *so* nice. Cheers Lars On Mon, May 20, 2013 at 2:15 PM, Andrey Semashev wrote:

On Mon, May 20, 2013 at 3:44 PM, Petr Machata wrote:

...

I maintain Boost in Fedora, and C++03/11 incompatibility has been on my list of things to look into for some time now.

...

2. Compile different versions of Boost libraries

I'm not sure how this fares with respect to autotools (by any name). We might need to update some automation to adapt to the changes in soname mangling, and to take any C++11-enabling switches into account. But I didn't look closely. Covering autotools and cmake would take us a long way towards the goal, which seems doable, so maybe #2 is the way to go.

Great, nice to hear from package maintainers. I got the same impression from the discussion, so maybe I'll try to implement a Boost.Build property to select C++ flavor.

However, I don't know much about autotools or cmake internals, so I can't tell how it will affect them.

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

Ok, I didn't really think so, since there is a distinct lack of further discussions of the issue on the mailing lists. Unfortunately this issue probably stops me from using C++11 at all, at least until GCC changes their default and some of the larger distros have started using that version of GCC. So C++11 is at least a few years away for me, it seems :-( /Lars On Wed, Jan 22, 2014 at 9:22 AM, Andrey Semashev wrote:

On Wed, Jan 22, 2014 at 12:16 PM, Lars Hagström wrote:

...

On Mon, May 20, 2013 at 2:15 PM, Andrey Semashev wrote:

...

On Mon, May 20, 2013 at 3:44 PM, Petr Machata wrote:

...

I maintain Boost in Fedora, and C++03/11 incompatibility has been on my list of things to look into for some time now.

...

2. Compile different versions of Boost libraries

I'm not sure how this fares with respect to autotools (by any name). We might need to update some automation to adapt to the changes in soname mangling, and to take any C++11-enabling switches into account. But I didn't look closely. Covering autotools and cmake would take us a long way towards the goal, which seems doable, so maybe #2 is the way to go.

Great, nice to hear from package maintainers. I got the same impression from the discussion, so maybe I'll try to implement a Boost.Build property to select C++ flavor.

However, I don't know much about autotools or cmake internals, so I can't tell how it will affect them.

Did you ever get anywhere with this? This issue has bitten me now, and I would really like to avoid having to build custom boost versions on Linux. The ease of installation when using the distro repos is *so* nice.

No, not really. I had a few quick attempts that failed because of my incompetence with Boost.Build and then I got distracted.

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