Re: [jamboost] Re: gcc-nocygwin toolset obsolete

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-17 01:06:33

David Abrahams said:
> "Raoul Gough" <raoulgough_at_[hidden]> writes:
>
>> "David Abrahams" <dave_at_[hidden]> wrote in message
>> news:ud6n1ruka.fsf_at_boost-consulting.com...
>>> "Raoul Gough" <raoulgough_at_[hidden]> writes:
>>>
>>> > I've had some correspondence with one of the cygwin maintainers,
>> and
>>> > it seems that gcc -mno-cygwin has changed for the better with
>> respect
>>> > to C++ support. The relevant points are
>>> >
>>> > o The Cygwin "gcc-mingw" package has a cygwin-free libstdc++
>>> > o Cygwin setup installs this package automatically with gcc
>>> > o g++ -mno-cygwin therefore *includes* C++ library support
>>> >
>>> > That means it should be possible simply to
>>> > use -sBUILD="<cxxflags>-mno-cygwin" with the regular gcc toolset,
>>> rendering gcc-nocygwin obsolete. In particular, installing
>> STLport, as
>>> > recommended in the gcc-nocygwin documenation, is probably *not*
>> good
>>> > advice anymore.

This reveals a problem in Boost.Build, I believe:

Script started on Thu Jan 16 09:51:04 2003
/home/wekempf/bin already exists...

mwekempf_at_WEKEMPFWS

$ cd ~/boost/libs/thread/build

~/boost/libs/thread/build

mwekempf_at_WEKEMPFWS ~/boost/libs/thread/build

$ bjam -sTOOLS=gcc -sBUILD="<cxxflags>-mno-cygwin"

....found 294 targets...

....updating 15 targets...

MkDir1 ..\..\..\libs\thread\build\bin\boost_thread.dll\gcc

MkDir1 ..\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug

MkDir1
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic

MkDir1
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi

gcc-C++-action
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\condition.obj

gcc-C++-action
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\mutex.obj

gcc-C++-action
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\recursive_mutex.obj

gcc-C++-action
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\thread.obj

gcc-C++-action
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\tss.obj

gcc-C++-action
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\xtime.obj

gcc-C++-action
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\once.obj

gcc-C++-action
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\exceptions.obj

gcc-C++-action
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\threadmon.obj

gcc-dllwrap actions too long (max 2047):

dllwrap --dllname
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\boost_thread.dll
-o foo.pyd
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\condition.obj
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\mutex.obj
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\recursive_mutex.obj
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\thread.obj
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\tss.obj
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\xtime.obj
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\once.obj
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\exceptions.obj
...\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\threadmon.obj
-s --entry _DllMain_at_12 --target=i386-mingw32 
"..\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\condition.obj"
"..\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\mutex.obj"
"..\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\recursive_mutex.obj"
"..\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\thread.obj"
"..\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\tss.obj"
"..\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\xtime.obj"
"..\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\once.obj"
"..\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\exceptions.obj"
"..\..\..\libs\thread\build\bin\boost_thread.dll\gcc\debug\runtime-link-dynamic\threading-multi\threadmon.obj"
-Wl,-rpath-link,. -g -shared

~/boost/libs/thread/build

mwekempf_at_WEKEMPFWS ~/boost/libs/thread/build

$ exit

Script done on Thu Jan 16 09:57:52 2003

>>> > I think it's time to remove the gcc-nocygwin toolset, and maybe
>>> include a note to the effect that -mno-cygwin should just work as
>> a
>>> > gcc compiler option. Any reason not to do this? Can someone advise
>> the
>>> > correct procedure for obsoleting a toolset?
>>>
>>> I guess it depends which version of GCC you have, no?
>>
>> I take it you wouldn't advocate removing it outright? What other
>> options would you suggest (without causing undue confusion to newer
>> users)?
>
> Document the new information. Maybe even label the toolset
> "deprecated" for the next release, and modify it so it prints a
> warning with a reference to the documentation page the first time it's
> used. At least we'll find out if anyone depends on it.

I think a toolset is still needed... though it can be greatly simplified. 
When regression testing it's at least inconvenient to have to supply the
-mno-cygwin option as instructed above. I'd much prefer a toolset that
did this automatically for me.

As for anyone depending on it... I certainly do, since this option impacts
whether or not POSIX threads or Win32 threads are used for the
implementation of Boost.Threads using the cygwin gcc.

William E. Kempf
wekempf_at_[hidden]