I'm having a hard time getting bjam --v2 to function properly on my system; it's probably just something stupid, but here's the problem : download latest CVS-HEAD snapshot and install ./configure --with-libraries=regex,serialization,mpi copy bjam to /usr/local/bin cd $BOOST_ROOT/libs/date_time/test bjam --v2 resulting in a slew of errors like the following sample : "g++" -o "../../../bin.v2/libs/date_time/test/ testgreg_day.test/gcc-4.0.1/debug/testgreg_day" -Wl,--start-group "../../../bin.v2/libs/date_time/test/testgreg_day.test/gcc-4.0.1/ debug/testgreg_day.o" "../../../bin.v2/libs/date_time/build/gcc-4.0.1/ debug/link-static/libboost_date_time-gcc40-d-1_35.a" -Wl,--end- group -g ...failed gcc.link ../../../bin.v2/libs/date_time/test/ testgreg_day.test/gcc-4.0.1/debug/testgreg_day... ...skipped <p../../../bin.v2/libs/date_time/test/testgreg_day.test/ gcc-4.0.1/debug>testgreg_day.run for lack of <p../../../bin.v2/libs/ date_time/test/testgreg_day.test/gcc-4.0.1/debug>testgreg_day... gcc.link ../../../bin.v2/libs/date_time/test/testgreg_month.test/ gcc-4.0.1/debug/testgreg_month /usr/bin/ld: unknown flag: --start-group collect2: ld returned 1 exit status "g++" -o "../../../bin.v2/libs/date_time/test/ testgreg_month.test/gcc-4.0.1/debug/testgreg_month" -Wl,--start-group "../../../bin.v2/libs/date_time/test/testgreg_month.test/gcc-4.0.1/ debug/testgreg_month.o" "../../../bin.v2/libs/date_time/build/ gcc-4.0.1/debug/link-static/libboost_date_time-gcc40-d-1_35.a" - Wl,--end-group -g ...failed gcc.link ../../../bin.v2/libs/date_time/test/ testgreg_month.test/gcc-4.0.1/debug/testgreg_month... ...skipped <p../../../bin.v2/libs/date_time/test/testgreg_month.test/ gcc-4.0.1/debug>testgreg_month.run for lack of <p../../../bin.v2/libs/ date_time/test/testgreg_month.test/gcc-4.0.1/debug>testgreg_month... gcc.link ../../../bin.v2/libs/date_time/test/testgreg_year.test/ gcc-4.0.1/debug/testgreg_year /usr/bin/ld: unknown flag: --start-group collect2: ld returned 1 exit status "g++" -o "../../../bin.v2/libs/date_time/test/ testgreg_year.test/gcc-4.0.1/debug/testgreg_year" -Wl,--start-group "../../../bin.v2/libs/date_time/test/testgreg_year.test/gcc-4.0.1/ debug/testgreg_year.o" "../../../bin.v2/libs/date_time/build/ gcc-4.0.1/debug/link-static/libboost_date_time-gcc40-d-1_35.a" - Wl,--end-group -g ...failed gcc.link ../../../bin.v2/libs/date_time/test/ testgreg_year.test/gcc-4.0.1/debug/testgreg_year... ...skipped <p../../../bin.v2/libs/date_time/test/testgreg_year.test/ gcc-4.0.1/debug>testgreg_year.run for lack of <p../../../bin.v2/libs/ date_time/test/testgreg_year.test/gcc-4.0.1/debug>testgreg_year... ...skipped <p../../../bin.v2/libs/date_time/test/testdate_dll.test/ gcc-4.0.1/debug>testdate_dll for lack of <p../../../bin.v2/libs/ date_time/build/gcc-4.0.1/debug>libboost_date_time-gcc40-d-1_35.dylib... ...skipped <p../../../bin.v2/libs/date_time/test/testdate_dll.test/ gcc-4.0.1/debug>testdate_dll.run for lack of <p../../../bin.v2/libs/ date_time/test/testdate_dll.test/gcc-4.0.1/debug>testdate_dll... ...skipped <p../../../bin.v2/libs/date_time/test/ testdate_duration_dll.test/gcc-4.0.1/debug>testdate_duration_dll for lack of <p../../../bin.v2/libs/date_time/build/gcc-4.0.1/ debug>libboost_date_time-gcc40-d-1_35.dylib... ...skipped <p../../../bin.v2/libs/date_time/test/ testdate_duration_dll.test/gcc-4.0.1/debug>testdate_duration_dll.run for lack of <p../../../bin.v2/libs/date_time/test/ testdate_duration_dll.test/gcc-4.0.1/debug>testdate_duration_dll... ...failed updating 53 targets... ...skipped 173 targets... The use of date_time is not the problem - I get similar errors for other Boost libraries... I'm running on a G5 Mac OSX system 10.4.8 using stock gcc provided with Xcode (gcc 4.0.1) : gcc --version : powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363) BTW, simply doing make after configuring works fine... Any ideas? Matthias
Matthias Schabel wrote:
I'm having a hard time getting bjam --v2 to function properly on my system; it's probably just something stupid, but here's the problem :
download latest CVS-HEAD snapshot and install ./configure --with-libraries=regex,serialization,mpi
copy bjam to /usr/local/bin
cd $BOOST_ROOT/libs/date_time/test bjam --v2
resulting in a slew of errors like the following sample :
"g++" -o "../../../bin.v2/libs/date_time/test/ testgreg_day.test/gcc-4.0.1/debug/testgreg_day" -Wl,--start-group
I would suggest trying invoke bjam as follows: bjam toolset=darwin On OSX, gcc is seriously different so it deserves its own toolset name. - Volodya
on Tue Mar 13 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
Matthias Schabel wrote:
I'm having a hard time getting bjam --v2 to function properly on my system; it's probably just something stupid, but here's the problem :
download latest CVS-HEAD snapshot and install ./configure --with-libraries=regex,serialization,mpi
copy bjam to /usr/local/bin
cd $BOOST_ROOT/libs/date_time/test bjam --v2
resulting in a slew of errors like the following sample :
"g++" -o "../../../bin.v2/libs/date_time/test/ testgreg_day.test/gcc-4.0.1/debug/testgreg_day" -Wl,--start-group
I would suggest trying invoke bjam as follows:
bjam toolset=darwin
On OSX, gcc is seriously different so it deserves its own toolset name.
I disagree with both assertions. It's not very different (darwin.jam contains only a small amount of additional code), and even if it were, the differences should not result in a different toolset name. Configuring python on windows and unix is very different, but you wouldn't call the windows python toolset "win32" instead of "python," would you? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
on Tue Mar 13 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
Matthias Schabel wrote:
I'm having a hard time getting bjam --v2 to function properly on my system; it's probably just something stupid, but here's the problem :
download latest CVS-HEAD snapshot and install ./configure --with-libraries=regex,serialization,mpi
copy bjam to /usr/local/bin
cd $BOOST_ROOT/libs/date_time/test bjam --v2
resulting in a slew of errors like the following sample :
"g++" -o "../../../bin.v2/libs/date_time/test/ testgreg_day.test/gcc-4.0.1/debug/testgreg_day" -Wl,--start-group
I would suggest trying invoke bjam as follows:
bjam toolset=darwin
On OSX, gcc is seriously different so it deserves its own toolset name.
I disagree with both assertions. It's not very different (darwin.jam contains only a small amount of additional code), and even if it were, the differences should not result in a different toolset name.
Configuring python on windows and unix is very different, but you wouldn't call the windows python toolset "win32" instead of "python," would you?
I don't think I see much of an analogy here. Anyway, there's FSF gcc and there's Apple gcc, both can run on OSX. Do distinguish between them, you need either different toolset name, or some extra feature. The only practical difference I know, is that with different toolset name, if you have a condition that applies to both gcc version, you'd have to write: <toolset>gcc:whatever <toolset>darwin:whatever Such conditions are mostly needed to workaround platform differences, and I have no idea if having to write two lines instead of one is big enough annoyance. - Volodya
on Thu Mar 15 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
David Abrahams wrote:
on Tue Mar 13 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
Matthias Schabel wrote:
I disagree with both assertions. It's not very different (darwin.jam contains only a small amount of additional code), and even if it were, the differences should not result in a different toolset name.
Configuring python on windows and unix is very different, but you wouldn't call the windows python toolset "win32" instead of "python," would you?
I don't think I see much of an analogy here.
Really? AFAIK nobody but us refers to Apple's gcc as "darwin" -- that's actually the name of the plaform. What happens when Apple comes out with its own version of some other tool like python or xsltproc? Are we going to call it "darwin2?"
Anyway, there's FSF gcc and there's Apple gcc, both can run on OSX. Do distinguish between them, you need either different toolset name, or some extra feature.
Or a subfeature of the toolset. I think this is related to the agreement I summarize at the bottom of http://news.gmane.org/find-root.php?message_id=%3c87abz776o6.fsf%40valverde....
The only practical difference I know, is that with different toolset name, if you have a condition that applies to both gcc version, you'd have to write:
<toolset>gcc:whatever <toolset>darwin:whatever
Such conditions are mostly needed to workaround platform differences, and I have no idea if having to write two lines instead of one is big enough annoyance.
The problem isn't that it's a big annoyance. The problems are: a. it's error-prone. People who don't use MacOS every day will forget to include a case for "darwin" in a great many GCC-specific build descriptions. The two toolsets have a lot more in common than they have different, so most of the time, that will result in wrong builds. b. It's a terrible name. "Darwin" is the name of the platform, and is not a good description of the toolset. c. Most new BB users will not think of using a toolset named darwin when compiling with gcc on MacOS X. I've already seen several posts where you had to tell a user, "use the darwin toolset, not gcc." When configuring gcc to target MacOS, the default assumption of the build system ought to be that it's Apple GCC. "Nobody" uses FSF gcc on MacOS. -- Dave Abrahams Boost Consulting www.boost-consulting.com
The problem isn't that it's a big annoyance. The problems are:
a. it's error-prone. People who don't use MacOS every day will forget to include a case for "darwin" in a great many GCC-specific build descriptions. The two toolsets have a lot more in common than they have different, so most of the time, that will result in wrong builds.
b. It's a terrible name. "Darwin" is the name of the platform, and is not a good description of the toolset.
c. Most new BB users will not think of using a toolset named darwin when compiling with gcc on MacOS X. I've already seen several posts where you had to tell a user, "use the darwin toolset, not gcc."
When configuring gcc to target MacOS, the default assumption of the build system ought to be that it's Apple GCC. "Nobody" uses FSF gcc on MacOS.
I am completely in agreement. If you're going to have a build system, it should do the most reasonable thing on the platform in question by default. The vast majority of OSX users will have installed the free XCode IDE and associated developer tools provided by Apple. Boost should build correctly by simply issuing "bjam --v2" on this platform as elsewhere. Matthias
participants (3)
-
David Abrahams -
Matthias Schabel -
Vladimir Prus