Bjam in 1.34.1 missing g++ compile option for address-model=32
I am trying to build Boost for G++ 32-bit applications on an Opteron system running Linux Fedora Core 3. This is my command: bjam --user-config=user-config.LINUX_AMD32 threading=multi instruction-set=opteron address-model=32 variant=release,debug,profile --stagedir=stageA32 stage and this is in my user-config file: using gcc : 3.4.4 : /opt/gcc344/bin/g++344 : <compileflags>-fPIC <linkflags>-fPIC ; The first evidence I had is that the .so libraries want to link to 64-bit shared libraries: 12% ldd libboostrgx.so librt.so.1 => /lib64/tls/librt.so.1 (0x00002aaaaac65000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002aaaaad7f000) libm.so.6 => /lib64/tls/libm.so.6 (0x00002aaaaaf71000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aaaab0f8000) libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00002aaaab203000) libc.so.6 => /lib64/tls/libc.so.6 (0x00002aaaab318000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) Then I ran the same bjam command with the option that shows the commands executed. This is typical: "/opt/gcc344/bin/g++344" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -pthread -march=opteron -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/test/build/gcc-3.4.4/release/address-model-32/instruction-set-opteron/link-static/threading-multi/test_tools.o" "libs/test/src/test_tools.cpp" It recognized the other options I requested, but not 'address-model=32'. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
I am trying to build Boost for G++ 32-bit applications on an Opteron system running Linux Fedora Core 3. This is my command:
bjam --user-config=user-config.LINUX_AMD32 threading=multi instruction-set=opteron address-model=32 variant=release,debug,profile --stagedir=stageA32 stage
...
It recognized the other options I requested, but not 'address-model=32'.
No reply? I realize that I can add '-m32' to the flags in my user-config file, but I was hoping that someone will fix the build system. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Richard Hadsell wrote:
I am trying to build Boost for G++ 32-bit applications on an Opteron system running Linux Fedora Core 3. This is my command:
bjam --user-config=user-config.LINUX_AMD32 threading=multi instruction-set=opteron address-model=32 variant=release,debug,profile --stagedir=stageA32 stage
...
It recognized the other options I requested, but not 'address-model=32'.
No reply? I realize that I can add '-m32' to the flags in my user-config file, but I was hoping that someone will fix the build system.
I presume you have already checked SVN HEAD, or 1.35, and the problem is still here? For the record, SVN HEAD version of tools/build/v2/tools/gcc.jam has this: flags gcc OPTIONS <architecture>x86/<address-model>32 : -m32 ; flags gcc OPTIONS <architecture>x86/<address-model>64 : -m64 ; I suspect you version might not have the first line, so if the compiler default is 64-bit, you'd always get 64-bit binary; you might want to add the first line to your gcc.jam - Volodya
Vladimir Prus wrote:
I presume you have already checked SVN HEAD, or 1.35, and the problem is still here?
For the record, SVN HEAD version of tools/build/v2/tools/gcc.jam has this:
flags gcc OPTIONS <architecture>x86/<address-model>32 : -m32 ; flags gcc OPTIONS <architecture>x86/<address-model>64 : -m64 ;
I suspect you version might not have the first line, so if the compiler default is 64-bit, you'd always get 64-bit binary; you might want to add the first line to your gcc.jam
No, I haven't tried 1.35. I'm waiting for 1.35.1, because I like to let the bug detection fall to others, when possible. My 1.34.1 does have both those lines. I suspect that some other line is overriding it. Perhaps it is my user-config option '<compileflags>-fPIC <linkflags>-fPIC' that wipes out the others. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Vladimir Prus wrote:
I presume you have already checked SVN HEAD, or 1.35, and the problem is still here?
For the record, SVN HEAD version of tools/build/v2/tools/gcc.jam has this:
flags gcc OPTIONS <architecture>x86/<address-model>32 : -m32 ; flags gcc OPTIONS <architecture>x86/<address-model>64 : -m64 ;
I suspect you version might not have the first line, so if the compiler default is 64-bit, you'd always get 64-bit binary; you might want to add the first line to your gcc.jam
No, I haven't tried 1.35. I'm waiting for 1.35.1, because I like to let the bug detection fall to others, when possible.
Good idea; unfortunately it might mean that fixes also fall to others.
My 1.34.1 does have both those lines. I suspect that some other line is overriding it. Perhaps it is my user-config option '<compileflags>-fPIC <linkflags>-fPIC' that wipes out the others.
Try adding architecture=x86 to the command line. - Volodya
Vladimir Prus wrote:
Try adding architecture=x86 to the command line.
That works. Thank you for the suggestion. I think bjam ought to do the equivalent by default on x86 or x86_64 systems, but it's fine with me to explicitly set the architecture. Perhaps the architecture-dependent lines in gcc.jam could be replaced by just one that sets the flag for all, since they are all '-m32' or '-m64'. That is, replace flags gcc OPTIONS <architecture>x86/<address-model>32 : -m32 ; flags gcc OPTIONS <architecture>x86/<address-model>64 : -m64 ; flags gcc OPTIONS <architecture>sparc/<address-model>32 : -m32 ; flags gcc OPTIONS <architecture>sparc/<address-model>64 : -m64 ; flags gcc OPTIONS <architecture>power/<address-model>32 : -m32 ; flags gcc OPTIONS <architecture>power/<address-model>64 : -m64 ; by flags gcc OPTIONS <address-model>32 : -m32 ; flags gcc OPTIONS <address-model>64 : -m64 ; If I have some time, I'll try it out. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Vladimir Prus wrote:
Try adding architecture=x86 to the command line.
That works. Thank you for the suggestion.
I think bjam ought to do the equivalent by default on x86 or x86_64 systems, but it's fine with me to explicitly set the architecture.
Perhaps the architecture-dependent lines in gcc.jam could be replaced by just one that sets the flag for all, since they are all '-m32' or '-m64'. ... If I have some time, I'll try it out.
Yes, that works, too. With this change in gcc.jam, you don't need to include the architecture option on the command line. If someone is willing to check the current gcc.jam, here is the diff from the version in 1.34.1 to my fix: --- tools/build/v2/tools/gcc.jam 25 Jul 2007 22:22:24 -0000 1.1.1.1 +++ tools/build/v2/tools/gcc.jam 16 May 2008 18:58:59 -0000 @@ -699,9 +699,10 @@ # Set architecture/instruction-set options. # +flags gcc OPTIONS <address-model>32 : -m32 ; +flags gcc OPTIONS <address-model>64 : -m64 ; +# # x86 and compatible -flags gcc OPTIONS <architecture>x86/<address-model>32 : -m32 ; -flags gcc OPTIONS <architecture>x86/<address-model>64 : -m64 ; cpu-flags gcc OPTIONS : x86 : i386 : -march=i386 : default ; cpu-flags gcc OPTIONS : x86 : i486 : -march=i486 ; cpu-flags gcc OPTIONS : x86 : i586 : -march=i586 ; @@ -735,8 +736,6 @@ cpu-flags gcc OPTIONS : x86 : c3 : -march=c3 ; cpu-flags gcc OPTIONS : x86 : c3-2 : -march=c3-2 ; # Sparc -flags gcc OPTIONS <architecture>sparc/<address-model>32 : -m32 ; -flags gcc OPTIONS <architecture>sparc/<address-model>64 : -m64 ; cpu-flags gcc OPTIONS : sparc : c3 : -mcpu=c3 : default ; cpu-flags gcc OPTIONS : sparc : v7 : -mcpu=v7 ; cpu-flags gcc OPTIONS : sparc : cypress : -mcpu=cypress ; @@ -753,8 +752,6 @@ cpu-flags gcc OPTIONS : sparc : ultrasparc : -mcpu=ultrasparc ; cpu-flags gcc OPTIONS : sparc : ultrasparc3 : -mcpu=ultrasparc3 ; # RS/6000 & PowerPC -flags gcc OPTIONS <architecture>power/<address-model>32 : -m32 ; -flags gcc OPTIONS <architecture>power/<address-model>64 : -m64 ; flags gcc OPTIONS <architecture>power/<address-model>/<instruction-set> : -mcpu=common ; cpu-flags gcc OPTIONS : power : 403 : -mcpu=403 ; cpu-flags gcc OPTIONS : power : 505 : -mcpu=505 ; -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Richard Hadsell wrote:
Vladimir Prus wrote:
Try adding architecture=x86 to the command line.
That works. Thank you for the suggestion.
I think bjam ought to do the equivalent by default on x86 or x86_64 systems, but it's fine with me to explicitly set the architecture.
Perhaps the architecture-dependent lines in gcc.jam could be replaced by just one that sets the flag for all, since they are all '-m32' or '-m64'. ... If I have some time, I'll try it out.
Yes, that works, too. With this change in gcc.jam, you don't need to include the architecture option on the command line.
If someone is willing to check the current gcc.jam, here is the diff from the version in 1.34.1 to my fix:
--- tools/build/v2/tools/gcc.jam 25 Jul 2007 22:22:24 -0000 1.1.1.1 +++ tools/build/v2/tools/gcc.jam 16 May 2008 18:58:59 -0000 @@ -699,9 +699,10 @@
# Set architecture/instruction-set options. # +flags gcc OPTIONS <address-model>32 : -m32 ; +flags gcc OPTIONS <address-model>64 : -m64 ;
But that will then cause problems for architectures that don't use those options. The two "correct" solutions to this are either: * Have BBv2 autodetect the host architecture and set that as the default instead of dealing with an empty architecture value. * Have users specify in the user-config.jam which architecture the compiler defaults to: toolset.add-requirements <toolset>gcc:<architecture>x86 ; (Adjusting the toolset name to be as specific as needed) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
But that will then cause problems for architectures that don't use those options. The two "correct" solutions to this are either:
* Have BBv2 autodetect the host architecture and set that as the default instead of dealing with an empty architecture value.
* Have users specify in the user-config.jam which architecture the compiler defaults to:
toolset.add-requirements <toolset>gcc:<architecture>x86 ;
(Adjusting the toolset name to be as specific as needed)
You are welcome to fix it in whatever way makes sense to you. I assumed that BBv2 already implemented your first option (detecting the host architecture), and that's the fix I would favor. Since all 3 architectures mentioned in gcc.jam use the same gcc options for 32-bit vs. 64-bit code, it seems reasonable that gcc would use the same options for any future architectures. So my suggestion shouldn't break any builds currently supported, and it works now, not waiting for a BBv2 fix. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Rene Rivera wrote:
Richard Hadsell wrote:
Richard Hadsell wrote:
Vladimir Prus wrote:
Try adding architecture=x86 to the command line.
That works. Thank you for the suggestion.
I think bjam ought to do the equivalent by default on x86 or x86_64 systems, but it's fine with me to explicitly set the architecture.
Perhaps the architecture-dependent lines in gcc.jam could be replaced by just one that sets the flag for all, since they are all '-m32' or '-m64'. ... If I have some time, I'll try it out.
Yes, that works, too. With this change in gcc.jam, you don't need to include the architecture option on the command line.
If someone is willing to check the current gcc.jam, here is the diff from the version in 1.34.1 to my fix:
--- tools/build/v2/tools/gcc.jam 25 Jul 2007 22:22:24 -0000 1.1.1.1 +++ tools/build/v2/tools/gcc.jam 16 May 2008 18:58:59 -0000 @@ -699,9 +699,10 @@
# Set architecture/instruction-set options. # +flags gcc OPTIONS <address-model>32 : -m32 ; +flags gcc OPTIONS <address-model>64 : -m64 ;
But that will then cause problems for architectures that don't use those options.
Will it? 'address-model' is an optional feature so nothing will break unless user asks for it explicitly.
The two "correct" solutions to this are either:
* Have BBv2 autodetect the host architecture and set that as the default instead of dealing with an empty architecture value.
It's doable, but maybe over-engineering. - Volodya
participants (3)
-
Rene Rivera -
Richard Hadsell -
Vladimir Prus