Boost C++ Libraries: Ticket #10767: Regression of #10296 when address-model=32 in mingw https://svn.boost.org/trac10/ticket/10767 <p> I have some upstream libraries that will not work in 64-bit build so I had to build boost as a 32-bit target (project-config.jam set to using gcc and build command from the cmd shell is: b2 address-model=32 install). </p> <p> This all works fine and dandy, except that it causes a regression of the whole <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/10296" title="#10296: Bugs: Boost.Thread 1.56 rc1 does not compile on Mingw (closed: fixed)">#10296</a> _InterlockedCompareExchange and friends related issues. </p> <p> You guessed it, it hits the #ifdef(<span class="underline">MINGW64_VERSION_MAJOR) defines, finds them defined (we are in address-model=32 remember) and happily creates the underscored forms of the calls in the implementations and the linker happily complains (AGAIN ARGHHHH!) that they are not defined. </span></p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/10767 Trac 1.4.3 Brian Jack <gau_veldt@…> Fri, 07 Nov 2014 07:21:52 GMT <link>https://svn.boost.org/trac10/ticket/10767#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:1</guid> <description> <p> I have some upstream libraries that will not work in 64-bit build so I had to build boost as a 32-bit target (project-config.jam set to using gcc and build command from the cmd shell is: b2 address-model=32 install). </p> <p> This all works fine and dandy, except that it causes a regression of the whole <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/10296" title="#10296: Bugs: Boost.Thread 1.56 rc1 does not compile on Mingw (closed: fixed)">#10296</a> _InterlockedCompareExchange and friends related issues. </p> <p> You guessed it, it hits the ifdef(MINGW64_VERSION_MAJOR) defines, finds them defined (we are in address-model=32 remember) and happily creates the underscored forms of the calls in the implementation blobs and the linker happily complains (AGAIN ARGHHHH!) that they are not defined. </p> </description> <category>Ticket</category> </item> <item> <author>Brian Jack <gau_veldt@…></author> <pubDate>Fri, 07 Nov 2014 07:25:23 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:2 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:2</guid> <description> <p> Is there a top level temporary kludge I can use to eliminate this define down the entire build so it'll do the right thing (alias the _Interlocked* forms to the ones without the _)? </p> </description> <category>Ticket</category> </item> <item> <author>Brian Jack <gau_veldt@…></author> <pubDate>Fri, 07 Nov 2014 16:07:34 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:3 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:3</guid> <description> <p> as a result of above problem I am unable to use boost.thread in applications using the library without those link errors... </p> <p> btw my (mingw) gcc is as follows (and being used by my projects in Code::Blocks): </p> <pre class="wiki">C:\&gt;gcc --version gcc (tdm64-1) 4.7.1 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. C:\&gt; </pre><p> the linker has these boost libs being added: </p> <pre class="wiki">&lt;Add library="libboost_system-mgw47-mt-d-1_57" /&gt; &lt;Add library="libboost_chrono-mgw47-mt-d-1_57" /&gt; &lt;Add library="libboost_date_time-mgw47-mt-d-1_57" /&gt; &lt;Add library="libboost_atomic-mgw47-mt-d-1_57" /&gt; &lt;Add library="libboost_thread-mgw47-mt-d-1_57" /&gt; </pre> </description> <category>Ticket</category> </item> <item> <dc:creator>viboes</dc:creator> <pubDate>Sun, 09 Nov 2014 18:28:57 GMT</pubDate> <title>owner changed https://svn.boost.org/trac10/ticket/10767#comment:4 https://svn.boost.org/trac10/ticket/10767#comment:4 <ul> <li><strong>owner</strong> changed from <span class="trac-author">Anthony Williams</span> to <span class="trac-author">Niall Douglas</span> </li> </ul> <p> Niall? </p> Ticket viboes Sun, 09 Nov 2014 23:47:56 GMT <link>https://svn.boost.org/trac10/ticket/10767#comment:5 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:5</guid> <description> <p> Have you tried to build the whole Boost libraries with </p> <p> b2 address-model=32 install? </p> <p> If this is the case and MINGW64_VERSION_MAJOR is defined I don't see what we can do. </p> </description> <category>Ticket</category> </item> <item> <author>Brian Jack <gau_veldt@…></author> <pubDate>Mon, 10 Nov 2014 05:46:24 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:6 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:6</guid> <description> <p> yes just to confirm I built the library with: b2 --address-model=32 install </p> <p> Furthermore the toolchain is set to gcc via project-config.jam </p> <p> as for workarounds </p> <p> what about adding a check for this condition (#ifdef MINGW64_VERSION when address-model=32) in the configuration script and define a project-global macro if it is? </p> <p> Maybe instead of the check itself testing for specific compilers directly in source it tests for a configure script macro that says "don't use intrinsics" instead. then the configuration script and set the build flag appropriately toplevel either in a config header or compilation commandline. In the future the configuration can be changed at one point to set the macro as needed rather than individual source files. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>viboes</dc:creator> <pubDate>Mon, 10 Nov 2014 08:26:39 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:7 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:7</guid> <description> <p> Do you know the macro gcc that states that the we are compiling for address-model=32? </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Niall Douglas</dc:creator> <pubDate>Mon, 10 Nov 2014 11:45:02 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:8 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:8</guid> <description> <p> I have this Saturday coming available. I will look into it. Note Vicente it is my last available Saturday until after the US Thanksgiving, so I can't look into issues until early December after this weekend. </p> </description> <category>Ticket</category> </item> <item> <author>Brian Jack <gau_veldt@…></author> <pubDate>Mon, 10 Nov 2014 12:49:49 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:9 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:9</guid> <description> <p> Alternatively the configurator could also try to build a small intrinsic test program (if boost jam uses test program configure tests) and set a "do not use intrinsics" macro if the link error occurs. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Niall Douglas</dc:creator> <pubDate>Sun, 16 Nov 2014 22:42:29 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:10 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:10</guid> <description> <p> I have been unable to replicate this issue on latest Mingw-w64 (4.9.1) and Boost 1.57: </p> <p> C:\Users\ned\Documents\boost-release&gt;b2 toolset=gcc address-model=32 --with-thread install -j 4 </p> <p> .... </p> <blockquote> <p> 1 file(s) copied. </p> </blockquote> <p> gcc.compile.c++ bin.v2\libs\thread\build\gcc-mingw-4.9.1\release\address-model-32\link-static\threading-multi\win32\thread.o gcc.archive bin.v2\libs\thread\build\gcc-mingw-4.9.1\release\address-model-32\link-static\threading-multi\libboost_thread-mgw49-mt-1_57.a common.copy C:\Boost\lib\libboost_thread-mgw49-mt-1_57.a bin.v2\libs\thread\build\gcc-mingw-4.9.1\release\address-model-32\link-static\threading-multi\libboost_thread-mgw49-mt-1_57.a </p> <blockquote> <p> 1 file(s) copied. </p> </blockquote> <p> ...updated 3691 targets... </p> <p> No errors, everything compiled and installed without issue. This was on Win8.1 x86. </p> <p> Niall </p> </description> <category>Ticket</category> </item> <item> <author>Brian Jack <gau_veldt@…></author> <pubDate>Sun, 16 Nov 2014 23:37:14 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:11 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:11</guid> <description> <p> the problem does not happen on build it happens when attempting to link any program using boost.thread </p> </description> <category>Ticket</category> </item> <item> <author>Brian Jack <gau_veldt@…></author> <pubDate>Mon, 17 Nov 2014 00:15:48 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:12 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:12</guid> <description> <p> If I comment out test_main and test_thread definitions the project builds and runs. With the two uncommented the errors resulting are posted after the example code. </p> <p> Test: </p> <pre class="wiki">#include &lt;windows.h&gt; #include &lt;iostream&gt; #include "protocol.hpp" #include &lt;boost/thread.hpp&gt; /* This part is included for reference. My project builds sucessfully with this part included via protocol.cpp/protocol.hpp if test_main and test_thread definitions are commented out. Obviously I'm paring this down to the specific problem. define in protocol.cpp: boost::mutex cout_mutex; defined like this protocol.hpp: class scoped_cout_lock { std::ios state; public: scoped_cout_lock() : state(NULL) { cout_mutex.lock(); state.copyfmt(std::cout); } virtual ~scoped_cout_lock() { std::cout.flush(); std::cout.copyfmt(state); cout_mutex.unlock(); } }; #define LOCK_COUT {scoped_cout_lock __scl; #define UNLOCK_COUT } */ void test_thread() { LOCK_COUT std::cout &lt;&lt; "Thread 2 says, \"Hello, World!\"" &lt;&lt; std::endl; UNLOCK_COUT } int test_main(int argc,char **argv) { boost::thread test(test_thread); LOCK_COUT std::cout &lt;&lt; "Thread 1 says, \"Hello, World!\"" &lt;&lt; std::endl; UNLOCK_COUT test.join(); return 0; } </pre><p> Result: </p> <p> mingw32-g++.exe -LC:\Minetest-Blockiverse\Minetest-Blockiverse\irrlicht-1.8.1\lib\Win32-gcc -LC:\Boost\lib -L..\zlib125dll\dll32 -L..\OpenAL\libs\Win32 -L..\libvorbis-1.3.4\win32 -L..\libogg-1.3.2\win32\VS2010 -o bin\blockiverse.exe obj\Debug\blockiverse\client.o obj\Debug\blockiverse\main.o obj\Debug\blockiverse\protocol.o obj\Debug\blockiverse\rsa\<a class="missing wiki">BigInt</a>.o obj\Debug\blockiverse\rsa\Key.o obj\Debug\blockiverse\rsa\<a class="missing wiki">KeyPair</a>.o obj\Debug\blockiverse\rsa\<a class="missing wiki">PrimeGenerator</a>.o obj\Debug\blockiverse\rsa\RSA.o obj\Debug\blockiverse\server.o obj\Debug\blockiverse\settings.o obj\Debug\blockiverse\sha1.o -lwsock32 -lws2_32 -lIrrlicht -lopengl32 -lglu32 -lgdi32 -lzlibwapi ..\OpenAL\libs\Win32\OpenAL32.lib -lvorbis -lvorbisfile -logg -lboost_system-mgw47-mt-d-1_57 -lboost_chrono-mgw47-mt-d-1_57 -lboost_date_time-mgw47-mt-d-1_57 -lboost_atomic-mgw47-mt-d-1_57 -lboost_random-mgw47-mt-d-1_57 -lboost_thread-mgw47-mt-d-1_57 C:\Boost\lib/libboost_thread-mgw47-mt-d-1_57.a(thread.o): In function `ZN5boost6detail5win3223GetTickCount64emulationEv@0': C:\Minetest-Blockiverse\Minetest-Blockiverse\boost_1_57_0/./boost/thread/win32/thread_primitives.hpp:247: undefined reference to `_InterlockedCompareExchange' C:\Minetest-Blockiverse\Minetest-Blockiverse\boost_1_57_0/./boost/thread/win32/thread_primitives.hpp:255: undefined reference to `_InterlockedCompareExchange' C:\Minetest-Blockiverse\Minetest-Blockiverse\boost_1_57_0/./boost/thread/win32/thread_primitives.hpp:278: undefined reference to `_InterlockedCompareExchange' C:\Boost\lib/libboost_thread-mgw47-mt-d-1_57.a(thread.o): In function `ZN5boost6detail24interlocked_read_acquireEPVl': C:\Minetest-Blockiverse\Minetest-Blockiverse\boost_1_57_0/./boost/thread/win32/interlocked_read.hpp:56: undefined reference to `_InterlockedCompareExchange' C:\Boost\lib/libboost_thread-mgw47-mt-d-1_57.a(thread.o): In function `ZN5boost6detail25interlocked_write_releaseEPVll': C:\Minetest-Blockiverse\Minetest-Blockiverse\boost_1_57_0/./boost/thread/win32/interlocked_read.hpp:64: undefined reference to `_InterlockedExchange' C:\Boost\lib/libboost_thread-mgw47-mt-d-1_57.a(thread.o): In function `ZN5boost6detail21intrusive_ptr_releaseEPNS0_19basic_cv_list_entryE': C:\Minetest-Blockiverse\Minetest-Blockiverse\boost_1_57_0/./boost/thread/win32/condition_variable.hpp:115: undefined reference to `_InterlockedDecrement' C:\Boost\lib/libboost_thread-mgw47-mt-d-1_57.a(thread.o): In function `ZN5boost6detail17enter_once_regionERNS_9once_flagERNS0_12once_contextE': C:\Minetest-Blockiverse\Minetest-Blockiverse\boost_1_57_0/./boost/thread/win32/once.hpp:180: undefined reference to `_InterlockedCompareExchange' C:\Boost\lib/libboost_thread-mgw47-mt-d-1_57.a(thread.o): In function `ZN5boost6detail18commit_once_regionERNS_9once_flagERNS0_12once_contextE': C:\Minetest-Blockiverse\Minetest-Blockiverse\boost_1_57_0/./boost/thread/win32/once.hpp:199: undefined reference to `_InterlockedIncrement' C:\Minetest-Blockiverse\Minetest-Blockiverse\boost_1_57_0/./boost/thread/win32/once.hpp:202: undefined reference to `_InterlockedExchange' C:\Boost\lib/libboost_thread-mgw47-mt-d-1_57.a(thread.o): In function `ZN5boost6detail20rollback_once_regionERNS_9once_flagERNS0_12once_contextE': C:\Minetest-Blockiverse\Minetest-Blockiverse\boost_1_57_0/./boost/thread/win32/once.hpp:215: undefined reference to `_InterlockedExchange' C:\Boost\lib/libboost_thread-mgw47-mt-d-1_57.a(thread.o): In function `ZN5boost9call_onceERNS_9once_flagEPFvvE': C:\Minetest-Blockiverse\Minetest-Blockiverse\boost_1_57_0/./boost/thread/win32/once.hpp:738: undefined reference to `_InterlockedIncrement' collect2.exe: error: ld returned 1 exit status Process terminated with status 1 (0 minute(s), 30 second(s)) 11 error(s), 0 warning(s) (0 minute(s), 30 second(s)) </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Niall Douglas</dc:creator> <pubDate>Mon, 17 Nov 2014 01:04:35 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:13 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:13</guid> <description> <p> Replying to <a class="ticket" href="https://svn.boost.org/trac10/ticket/10767#comment:11" title="Comment 11">Brian Jack &lt;gau_veldt@…&gt;</a>: </p> <blockquote class="citation"> <p> the problem does not happen on build it happens when attempting to link any program using boost.thread </p> </blockquote> <p> I also compiled and linked and executed a full unit test suite using 32 bit mingw-w64, all of which is dynamically linked to boost.thread. If there were any unresolved symbols, they surely would have appeared then. </p> <p> Can you provide a small example piece of code which demonstrates this problem please? Posting copy and pastes from a large project we don't have isn't useful. For all we know, this is a bug in GCC 4.7 Mingw's and has since been fixed. This stackoverflow post in fact (<a class="ext-link" href="https://stackoverflow.com/questions/18134148/undefined-reference-to-interlockedcompareexchange-with-boost-thread-on-mingw64"><span class="icon">​</span>https://stackoverflow.com/questions/18134148/undefined-reference-to-interlockedcompareexchange-with-boost-thread-on-mingw64</a>) says this is exactly the problem, and a newer mingw-w64 doesn't have this problem. </p> <p> Niall </p> </description> <category>Ticket</category> </item> <item> <author>Brian Jack <gau_veldt@…></author> <pubDate>Mon, 17 Nov 2014 22:28:40 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:14 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:14</guid> <description> <p> just above your post is a thread-using hello world that does NOT link on my end in GCC 4.7.1 - the commented parts include the code needed to use it without the entire project. failing this I'll jsut stick to <a class="missing wiki">CreateThread</a> (sucks as it is makes my code windows-only) as I have been doing since boost::thread right now is the only thing not working in the project as a whole and it's beyond me to fix this on my installation (a newer MINGW is A LOT of work on 64-bit Windows system to install particualrly over an older mingw). </p> </description> <category>Ticket</category> </item> <item> <author>Brian Jack <gau_veldt@…></author> <pubDate>Mon, 17 Nov 2014 22:34:59 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:15 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:15</guid> <description> <p> I should point out the stack overflow question refers to a cross-compiling situation also. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>viboes</dc:creator> <pubDate>Sat, 06 Dec 2014 09:57:10 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:16 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:16</guid> <description> <p> Any news on this issue? </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Niall Douglas</dc:creator> <pubDate>Sat, 06 Dec 2014 14:52:48 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:17 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:17</guid> <description> <p> The hello world example he posted appears to still rely on external files. I reduced that to: </p> <pre class="wiki">#include &lt;windows.h&gt; #include &lt;iostream&gt; #include &lt;boost/thread.hpp&gt; boost::mutex cout_mutex; class scoped_cout_lock { std::ios state; public: scoped_cout_lock() : state(NULL) { cout_mutex.lock(); state.copyfmt(std::cout); } virtual ~scoped_cout_lock() { std::cout.flush(); std::cout.copyfmt(state); cout_mutex.unlock(); } }; #define LOCK_COUT {scoped_cout_lock __scl; #define UNLOCK_COUT } void test_thread() { LOCK_COUT std::cout &lt;&lt; "Thread 2 says, \"Hello, World!\"" &lt;&lt; std::endl; UNLOCK_COUT } int main(int argc,char **argv) { boost::thread test(test_thread); LOCK_COUT std::cout &lt;&lt; "Thread 1 says, \"Hello, World!\"" &lt;&lt; std::endl; UNLOCK_COUT test.join(); return 0; } </pre><p> I ran: </p> <pre class="wiki">C:\Users\ned\Documents\boost-release&gt;b2 toolset=gcc libs/thread/test//test_10767 Performing configuration checks - symlinks supported : no - junctions supported : yes - hardlinks supported : yes ...patience... ...patience... ...found 1424 targets... ...updating 23 targets... common.mkdir bin.v2\libs\thread\test\test_10767.test common.mkdir bin.v2\libs\thread\test\test_10767.test\gcc-mingw-4.8.1 common.mkdir bin.v2\libs\thread\test\test_10767.test\gcc-mingw-4.8.1\debug common.mkdir bin.v2\libs\thread\test\test_10767.test\gcc-mingw-4.8.1\debug\threa ding-multi gcc.compile.c++ bin.v2\libs\thread\test\test_10767.test\gcc-mingw-4.8.1\debug\th reading-multi\test_10767.o libs\thread\test\test_10767.cpp:29:5: warning: unused parameter 'argc' [-Wunused -parameter] int main(int argc,char **argv) { ^ libs\thread\test\test_10767.cpp:29:5: warning: unused parameter 'argv' [-Wunused -parameter] gcc.compile.c++ bin.v2\libs\thread\test\test_10767.test\gcc-mingw-4.8.1\debug\th reading-multi\winrt_init.o gcc.compile.c++ bin.v2\libs\thread\build\gcc-mingw-4.8.1\debug\threading-multi\w in32\thread.o gcc.compile.c++ bin.v2\libs\thread\build\gcc-mingw-4.8.1\debug\threading-multi\w in32\tss_dll.o gcc.compile.c++ bin.v2\libs\thread\build\gcc-mingw-4.8.1\debug\threading-multi\w in32\tss_pe.o gcc.compile.c++ bin.v2\libs\thread\build\gcc-mingw-4.8.1\debug\threading-multi\f uture.o gcc.compile.c++ bin.v2\libs\chrono\build\gcc-mingw-4.8.1\debug\threading-multi\c hrono.o gcc.compile.c++ bin.v2\libs\chrono\build\gcc-mingw-4.8.1\debug\threading-multi\t hread_clock.o gcc.compile.c++ bin.v2\libs\chrono\build\gcc-mingw-4.8.1\debug\threading-multi\p rocess_cpu_clocks.o gcc.compile.c++ bin.v2\libs\system\build\gcc-mingw-4.8.1\debug\threading-multi\e rror_code.o gcc.link.dll bin.v2\libs\system\build\gcc-mingw-4.8.1\debug\threading-multi\libb oost_system-mgw48-mt-d-1_57.dll.a gcc.link.dll bin.v2\libs\chrono\build\gcc-mingw-4.8.1\debug\threading-multi\libb oost_chrono-mgw48-mt-d-1_57.dll.a gcc.link.dll bin.v2\libs\thread\build\gcc-mingw-4.8.1\debug\threading-multi\libb oost_thread-mgw48-mt-d-1_57.dll.a gcc.link bin.v2\libs\thread\test\test_10767.test\gcc-mingw-4.8.1\debug\threading -multi\test_10767.exe testing.capture-output bin.v2\libs\thread\test\test_10767.test\gcc-mingw-4.8.1\d ebug\threading-multi\test_10767.run 1 file(s) copied. **passed** bin.v2\libs\thread\test\test_10767.test\gcc-mingw-4.8.1\debug\threadi ng-multi\test_10767.test ...updated 23 targets... </pre><p> Still looks fine to me. </p> <p> Niall </p> </description> <category>Ticket</category> </item> <item> <author>Brian Jack <gau_veldt@…></author> <pubDate>Sat, 06 Dec 2014 16:54:01 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:18 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:18</guid> <description> <p> I've since moved to the bleeding edge (worded as the "convenience version" on C::B site) Code::Blocks (that uses gcc 4.8.1) and this problem no longer occurs. The Code::Block and gcc version changed when I had to switch to on a different machine to continue work on my project. </p> <p> It would appear thus that this was indeed a gcc 4.7.1 issue. </p> <p> Same project moved to gcc 4.8.1 now builds properly with boost threads. I've since taken out the windows-only <a class="missing wiki">CreateThread</a> workaround (project now uses boost threads) and I regained the platform independence ground I had lost due to the workaround. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>viboes</dc:creator> <pubDate>Sat, 06 Dec 2014 17:44:02 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:19 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:19</guid> <description> <p> So, could we close this issue as worksforme? </p> </description> <category>Ticket</category> </item> <item> <dc:creator>viboes</dc:creator> <pubDate>Sat, 06 Dec 2014 17:46:03 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10767#comment:20 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10767#comment:20</guid> <description> <p> Replying to <a class="ticket" href="https://svn.boost.org/trac10/ticket/10767#comment:17" title="Comment 17">ned14</a>: </p> <blockquote class="citation"> <p> The hello world example he posted appears to still rely on external files. I reduced that to: ... </p> <p> I ran: ... </p> <p> Still looks fine to me. </p> <p> Niall </p> </blockquote> <p> Thanks Niall for this follow up. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>viboes</dc:creator> <pubDate>Tue, 09 Dec 2014 06:43:22 GMT</pubDate> <title>status changed; resolution set; milestone deleted https://svn.boost.org/trac10/ticket/10767#comment:21 https://svn.boost.org/trac10/ticket/10767#comment:21 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">worksforme</span> </li> <li><strong>milestone</strong> <span class="trac-field-deleted">To Be Determined</span> </li> </ul> Ticket