[Boost-users] Boost 1.56.0 has been released

1,593 views
Skip to first unread message

Marshall Clow

unread,
Aug 7, 2014, 1:54:15 PM8/7/14
to boost@lists.boost.org List, boost...@lists.boost.org, Boost announce list
Release 1.56.0 of the Boost C++ Libraries is now available.

These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. 
The Boost license encourages both commercial and non-commercial use.

This release contains one new library and numerous enhancements and bug fixes for existing libraries.

=== Modularization ===
Boost version control has migrated to a system using git submodules. This shouldn't make too much of a difference to users, although the directory structure is now a bit different.

Parts of some libraries have been moved into different modules, and several new modules have been extracted from existing code. All header paths should remain the same. The new modules are:

• Assert: Customizable assert macros. Maintained by Peter Dimov.
• Core:  Core utilities used by other libraries, with minimal dependencies. Maintained by Peter Dimov, Glen Fernandes and Andrey Semashev.
• Lexical_Cast: General literal text conversions, such as an int represented a string, or vice-versa, from Kevlin Henney.
• Throw_Exception: A common infrastructure for throwing exceptions from Boost libraries, from Emil Dotchevski.
• Winapi: Windows API declarations without <windows.h>, for internal Boost use.

=== New Libraries ===
• Align: Memory alignment functions, allocators, and adaptors, from Glen Fernandes.
• Type_Index: Runtime/Compile time copyable type info, from Antony Polukhin.


For details, including download links, see http://www.boost.org/users/news/version_1.56.0

You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.56.0/

To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html

Thanks,

--The Boost release team

  Vladimir Prus
  Rene Rivera
  Marshall Clow
  Eric Niebler
  Daniel James
  Beman Dawes

Tom Kent

unread,
Aug 7, 2014, 6:39:22 PM8/7/14
to Boost users list, boost@lists.boost.org List, Boost announce list
On Thu, Aug 7, 2014 at 12:54 PM, Marshall Clow <mclow...@gmail.com> wrote:
Release 1.56.0 of the Boost C++ Libraries is now available.

The corresponding windows binaries for msvc-8.0 (SP1), msvc-9.0 (SP1), msvc-10.0 (SP1), msvc-11.0 (Update 4) and msvc-12.0 (Update 2) in 32 & 64 bit versions are now also available from sourceforge.


Tom Kent 

Christoffer Green

unread,
Aug 8, 2014, 9:42:45 AM8/8/14
to boost...@lists.boost.org
Hello

I tried upgrading from 1.55 to 1.56 and got a linking error.

I am using mingw32-gcc-4.7.2 on windows 7. I compiled boost with "b2 toolset=gcc stage release -j8 --build-type=complete link=static threading=multi variant=release"

..\..\..\lib/libPrimeGameEngineRelease.a(GameEngine.o):GameEngine.cpp:(.text$_ZN5boost6detail5win3223GetTickCount64emulationEv+0x27): undefined reference to `_InterlockedCompareExchange' ..\..\..\lib/libPrimeGameEngineRelease.a(GameEngine.o):GameEngine.cpp:(.text$_ZN5boost6detail5win3223GetTickCount64emulationEv+0x87): undefined reference to `_InterlockedCompareExchange'

BR/Christoffer


_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Lars Viklund

unread,
Aug 8, 2014, 10:06:19 AM8/8/14
to boost...@lists.boost.org
On Fri, Aug 08, 2014 at 12:39:18PM +0200, Christoffer Green wrote:
> Hello
>
> I tried upgrading from 1.55 to 1.56 and got a linking error.
>
> I am using mingw32-gcc-4.7.2 on windows 7. I compiled boost with "b2
> toolset=gcc stage release -j8 --build-type=complete link=static
> threading=multi variant=release"
>
> ..\..\..\lib/libPrimeGameEngineRelease.a(GameEngine.o):GameEngine.cpp:(.text$_ZN5boost6detail5win3223GetTickCount64emulationEv+0x27):
> undefined reference to `_InterlockedCompareExchange'
> ..\..\..\lib/libPrimeGameEngineRelease.a(GameEngine.o):GameEngine.cpp:(.text$_ZN5boost6detail5win3223GetTickCount64emulationEv+0x87):
> undefined reference to `_InterlockedCompareExchange'

Static libraries cannot link anything. If you use a static library, in
the absence of autolink pragmas, the onus is on you to link whatever is
needed by the libraries.

In this case, you in your project appear to not be linking in the
library defining InterlockedCompareExchange, which IIRC is located in
Kernel32.lib.


--
Lars Viklund | z...@acc.umu.se

Richard Hadsell

unread,
Aug 8, 2014, 1:37:12 PM8/8/14
to boost...@lists.boost.org
(1) I downloaded and untarred from the Unix .bz2 download.  Many of the directories have 700 (user-only access) permissions, instead of the usual 755.  I can correct everything by hand, but this seems like a mistake.  It would be good to offer us a useful chmod command to fix this.

(2) I started to look at the getting_started docs, because I expected some advice with respect to the new library structure.  However, the docs all refer to 1.55.0, so I doubt that I will learn anything from them.  I can muddle on without help, but I was hoping to avoid unnecessary delays in installing 1.56.0.
-- 
Dick Hadsell			203-992-6320  Fax: 203-992-6001
Reply-to:			had...@blueskystudios.com
Blue Sky Studios                http://www.blueskystudios.com
1 American Lane, Greenwich, CT 06831-2560

Daniel James

unread,
Aug 9, 2014, 10:51:14 AM8/9/14
to boost...@lists.boost.org
On 8 August 2014 18:37, Richard Hadsell <had...@blueskystudios.com> wrote:
>
> (1) I downloaded and untarred from the Unix .bz2 download. Many of the
> directories have 700 (user-only access) permissions, instead of the usual
> 755. I can correct everything by hand, but this seems like a mistake. It
> would be good to offer us a useful chmod command to fix this.

find boost_1_56_0 -type d | xargs chmod 755

> (2) I started to look at the getting_started docs, because I expected some
> advice with respect to the new library structure. However, the docs all
> refer to 1.55.0, so I doubt that I will learn anything from them. I can
> muddle on without help, but I was hoping to avoid unnecessary delays in
> installing 1.56.0.

The instructions are the same for both versions, it's just that no one
remembered to rebuild the document for 1.56. I can fix that on the
website.

Gavin Lambert

unread,
Aug 10, 2014, 6:47:33 PM8/10/14
to boost...@lists.boost.org
On 9/08/2014 02:04, Lars Viklund wrote:
> On Fri, Aug 08, 2014 at 12:39:18PM +0200, Christoffer Green wrote:
>> ..\..\..\lib/libPrimeGameEngineRelease.a(GameEngine.o):GameEngine.cpp:(.text$_ZN5boost6detail5win3223GetTickCount64emulationEv+0x27):
>> undefined reference to `_InterlockedCompareExchange'
>> ..\..\..\lib/libPrimeGameEngineRelease.a(GameEngine.o):GameEngine.cpp:(.text$_ZN5boost6detail5win3223GetTickCount64emulationEv+0x87):
>> undefined reference to `_InterlockedCompareExchange'
[...]
> In this case, you in your project appear to not be linking in the
> library defining InterlockedCompareExchange, which IIRC is located in
> Kernel32.lib.

That should be a compiler intrinsic, though, not a library call. You
may need the /Oi compiler flag and/or some #defines to accomplish this.

Niall Douglas

unread,
Aug 10, 2014, 7:03:11 PM8/10/14
to boost...@lists.boost.org
On 8 Aug 2014 at 12:39, Christoffer Green wrote:

> I tried upgrading from 1.55 to 1.56 and got a linking error.
>
> I am using mingw32-gcc-4.7.2 on windows 7. I compiled boost with "b2
> toolset=gcc stage release -j8 --build-type=complete link=static
> threading=multi variant=release"
>
> ..\..\..\lib/libPrimeGameEngineRelease.a(GameEngine.o):GameEngine.cpp:(.text$_ZN5boost6detail5win3223GetTickCount64emulationEv+0x27):
> undefined reference to `_InterlockedCompareExchange'
> ..\..\..\lib/libPrimeGameEngineRelease.a(GameEngine.o):GameEngine.cpp:(.text$_ZN5boost6detail5win3223GetTickCount64emulationEv+0x87):
> undefined reference to `_InterlockedCompareExchange'

Boost.Thread in 1.56 is known to be broken on Mingw. It was
discovered late in the testing process. We did not consider it a
showstopper as Mingw-w64 is not broken. Boost.Thread trunk is already
fixed for Mingw, you can find the fix at
https://github.com/boostorg/thread/commit/26042ca26a9783c9055a40ada6b8
bb26d3dd65b6#diff-d41d8cd98f00b204e9800998ecf8427e

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/
http://ie.linkedin.com/in/nialldouglas/


Lars Viklund

unread,
Aug 11, 2014, 9:35:21 AM8/11/14
to boost...@lists.boost.org
On Mon, Aug 11, 2014 at 10:47:10AM +1200, Gavin Lambert wrote:
> On 9/08/2014 02:04, Lars Viklund wrote:
> >On Fri, Aug 08, 2014 at 12:39:18PM +0200, Christoffer Green wrote:
> >>..\..\..\lib/libPrimeGameEngineRelease.a(GameEngine.o):GameEngine.cpp:(.text$_ZN5boost6detail5win3223GetTickCount64emulationEv+0x27):
> >>undefined reference to `_InterlockedCompareExchange'
> >>..\..\..\lib/libPrimeGameEngineRelease.a(GameEngine.o):GameEngine.cpp:(.text$_ZN5boost6detail5win3223GetTickCount64emulationEv+0x87):
> >>undefined reference to `_InterlockedCompareExchange'
> [...]
> >In this case, you in your project appear to not be linking in the
> >library defining InterlockedCompareExchange, which IIRC is located in
> >Kernel32.lib.
>
> That should be a compiler intrinsic, though, not a library call. You may
> need the /Oi compiler flag and/or some #defines to accomplish this.

This isn't VC++, this is some form of mingw-like as gcc or clang.
Even on VC++, it's either an intrinsic or a library function in
Kernel32.lib, depending on the flag you mention. It's perfectly sane to
use the library call form if you or your implementation feel like it,
but you may have to link the library it exists in.

The leading underscore is either mangling for the C calling convention
on the platform or the actual spelling of the symbol given that it's a
name reserved for the vendor, I don't have my MS headers around.

--
Lars Viklund | z...@acc.umu.se

Lars Viklund

unread,
Aug 11, 2014, 9:37:21 AM8/11/14
to boost...@lists.boost.org
On Mon, Aug 11, 2014 at 03:35:13PM +0200, Lars Viklund wrote:
> On Mon, Aug 11, 2014 at 10:47:10AM +1200, Gavin Lambert wrote:
> > On 9/08/2014 02:04, Lars Viklund wrote:
> > >On Fri, Aug 08, 2014 at 12:39:18PM +0200, Christoffer Green wrote:
> > >>..\..\..\lib/libPrimeGameEngineRelease.a(GameEngine.o):GameEngine.cpp:(.text$_ZN5boost6detail5win3223GetTickCount64emulationEv+0x27):
> > >>undefined reference to `_InterlockedCompareExchange'
> > >>..\..\..\lib/libPrimeGameEngineRelease.a(GameEngine.o):GameEngine.cpp:(.text$_ZN5boost6detail5win3223GetTickCount64emulationEv+0x87):
> > >>undefined reference to `_InterlockedCompareExchange'
> > [...]
> > >In this case, you in your project appear to not be linking in the
> > >library defining InterlockedCompareExchange, which IIRC is located in
> > >Kernel32.lib.
> >
> > That should be a compiler intrinsic, though, not a library call. You may
> > need the /Oi compiler flag and/or some #defines to accomplish this.
>
> This isn't VC++, this is some form of mingw-like as gcc or clang.

I just saw the commit range mentioned by Niall in his post. It appears
that Boost.Thread explicitly invokes some sort of pragma and uses
internal names for the intrinsic/function instead of letting headers and
compilers do their thing. How nice and interoperable...

Niall Douglas

unread,
Aug 11, 2014, 1:46:35 PM8/11/14
to boost...@lists.boost.org
On 11 Aug 2014 at 15:37, Lars Viklund wrote:

> > This isn't VC++, this is some form of mingw-like as gcc or clang.
>
> I just saw the commit range mentioned by Niall in his post. It appears
> that Boost.Thread explicitly invokes some sort of pragma and uses
> internal names for the intrinsic/function instead of letting headers and
> compilers do their thing. How nice and interoperable...

Actually Boost.Thread gives you the option of whether it drags in
windows.h or not via a macro. By default it does not and therefore
must speak MSVC intrinsic.

The failure on mingw is because mingw appears to have suddenly
stopped implictly defining the MSVC intrinsics. As I mentioned,
mingw-w64 or older mingw's are fine. Boost.Thread in trunk is now
fixed and no longer attempts to use intrinsics on mingw.

Mingw, quite frankly, is very brittle and has lousy QA. Proposed
Boost.AFIO currently hangs on the latest Mingw due to yet another new
bug, this time they've broken directory enumeration somehow. I'm not
going to bother working around it, I'm simply telling people go use
Mingw-w64 which is far less buggy. Or use MSVC like sane people do on
Windows.
Reply all
Reply to author
Forward
0 new messages