Re: [boost] Release 1_35_0_RC2: Boost Python hello tutorial
Beman Dawes wrote:
In the meantime, have you tried a more modern version of VC++? The free download of VC++ 2008 Express Edition, for example. Ok, I just tried the same procedure with the VC++ 2005 (i.e. 8.0) compiler with the same result. It does not generate the .pyd files, neither in release mode nor in debug mode.
Thanks, for adding it to the issus list Best, Johannes
Johannes Brunen wrote:
Beman Dawes wrote:
In the meantime, have you tried a more modern version of VC++? The free download of VC++ 2008 Express Edition, for example. Ok, I just tried the same procedure with the VC++ 2005 (i.e. 8.0) compiler with the same result. It does not generate the .pyd files, neither in release mode nor in debug mode.
Johannes, Starting from Boost 1.35, bjam erases the generated executables (e.g. pyd file) after the test has concluded to conserve disk space. To keep bjam from doing that, pass --preserve-test-targets to bjam. HTH, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Johannes, Starting from Boost 1.35, bjam erases the generated executables (e.g. pyd file) after the test has concluded to conserve disk space. To keep bjam from doing that, pass --preserve-test-targets to bjam.
Joel has updated the documentation on this, too. --Beman
Hi Beman, A couple of comments on RC2. It builds fine with the darwin toolset (gcc 4.0.1) on an Intel core2 running Tiger. All the documentation links I checked worked okay. There're a couple of issues building with the Intel compilers under Tiger (the intel-darwin toolset). (1) The configure script doesn't recognize the intel-darwin toolset. I've attached patches to both tools/jam/src/build.sh and tools/jam/ src/build.jam so the intel-darwin toolset is recognized. With these patches, users with intel compilers on the Mac should be able to: ./configure --with-toolset=intel-darwin ; make (2) Python fails to compile when the intel compilers generate 64 bit code, the fix is to build 32 bit if you need python. (3) The address-model property in intel-darwin.jam isn't properly configured. I've attached a patch to fix tools/build/v2/tools/intel- darwin.jam to make this work with address-model=32,64. (4) The regex library (built shared as a dylib), doesn't link due to, apparently, missing symbols in the runtime. __ZNSt15basic_streambufIwSt11char_traitsIwEE8overflowEj __ZNSt15basic_streambufIwSt11char_traitsIwEE9pbackfailEj (5) The filesystem library (built shared) fails to link building 32 bit for an internal link error. ld: internal error: output_local_symbols() inconsistent local symbol count -- Noel
K. Noel Belcourt wrote:
Hi Beman,
A couple of comments on RC2. It builds fine with the darwin toolset (gcc 4.0.1) on an Intel core2 running Tiger. All the documentation links I checked worked okay. There're a couple of issues building with the Intel compilers under Tiger (the intel-darwin toolset).
(1) The configure script doesn't recognize the intel-darwin toolset. I've attached patches to both tools/jam/src/build.sh and tools/jam/ src/build.jam so the intel-darwin toolset is recognized. With these patches, users with intel compilers on the Mac should be able to:
./configure --with-toolset=intel-darwin ; make
(2) Python fails to compile when the intel compilers generate 64 bit code, the fix is to build 32 bit if you need python.
(3) The address-model property in intel-darwin.jam isn't properly configured. I've attached a patch to fix tools/build/v2/tools/intel- darwin.jam to make this work with address-model=32,64.
Why you've left -mcmodel=small commented out? Does this option actually exist, and if so, is it good for anything? Or -m32/-m64 make this option unnecessary. - Volodya
Hi Volodya, On Mar 24, 2008, at 11:49 PM, Vladimir Prus wrote:
K. Noel Belcourt wrote:
(3) The address-model property in intel-darwin.jam isn't properly configured. I've attached a patch to fix tools/build/v2/tools/intel- darwin.jam to make this work with address-model=32,64.
Why you've left -mcmodel=small commented out? Does this option actually exist, and if so, is it good for anything? Or -m32/-m64 make this option unnecessary.
When I first added the intel-darwin toolset, the -m32/-m64 options were not documented and the only option I could find that dealt with the address model was the -mcmodel option. I've since discovered that, though undocumented in the older intel compilers, the intel compilers do support -m32/-m64. I think that address-model=32,64 maps most closely to -m32/-m64 so that's why I removed the mcmodel option. -- Noel [ Documentation of the -mcmodel option in intel-10.0 ] -mcmodel=<mem_model> (i64em) Tells the compiler to use a specific memory model to generate code and store data. Default is - mcmodel=small. Possible <mem_model> values are: small -- Restrict code and data to the first 2GB of address space. Use relative addressing. medium -- Restrict code to the first 2GB. Code access uses IP-relative addressing, but data accesses require absolute addressing. large -- Places no memory restriction on code or data. All accesses of code and data must be done with absolute address- ing.
K. Noel Belcourt wrote:
Hi Volodya,
On Mar 24, 2008, at 11:49 PM, Vladimir Prus wrote:
K. Noel Belcourt wrote:
(3) The address-model property in intel-darwin.jam isn't properly configured. I've attached a patch to fix tools/build/v2/tools/intel- darwin.jam to make this work with address-model=32,64.
Why you've left -mcmodel=small commented out? Does this option actually exist, and if so, is it good for anything? Or -m32/-m64 make this option unnecessary.
When I first added the intel-darwin toolset, the -m32/-m64 options were not documented and the only option I could find that dealt with the address model was the -mcmodel option. I've since discovered that, though undocumented in the older intel compilers, the intel compilers do support -m32/-m64.
I think that address-model=32,64 maps most closely to -m32/-m64 so that's why I removed the mcmodel option.
-- Noel
[ Documentation of the -mcmodel option in intel-10.0 ]
-mcmodel=<mem_model> (i64em) Tells the compiler to use a specific memory model to generate code and store data. Default is - mcmodel=small. Possible <mem_model> values are:
small -- Restrict code and data to the first 2GB of address space. Use relative addressing.
medium -- Restrict code to the first 2GB. Code access uses IP-relative addressing, but data accesses require absolute addressing.
large -- Places no memory restriction on code or data. All accesses of code and data must be done with absolute address- ing.
I wonder if -m64 without any additional options limits code and data to 2GB? That would be not very logical, but I'm not sure. - Volodya Hmm. Presumably, -m64
On Mar 26, 2008, at 10:32 AM, Vladimir Prus wrote:
K. Noel Belcourt wrote:
On Mar 24, 2008, at 11:49 PM, Vladimir Prus wrote:
K. Noel Belcourt wrote:
(3) The address-model property in intel-darwin.jam isn't properly configured. I've attached a patch to fix tools/build/v2/tools/ intel- darwin.jam to make this work with address-model=32,64.
Why you've left -mcmodel=small commented out? Does this option actually exist, and if so, is it good for anything? Or -m32/-m64 make this option unnecessary.
When I first added the intel-darwin toolset, the -m32/-m64 options were not documented and the only option I could find that dealt with the address model was the -mcmodel option. I've since discovered that, though undocumented in the older intel compilers, the intel compilers do support -m32/-m64.
I think that address-model=32,64 maps most closely to -m32/-m64 so that's why I removed the mcmodel option.
-- Noel
[ Documentation of the -mcmodel option in intel-10.0 ]
-mcmodel=<mem_model> (i64em) Tells the compiler to use a specific memory model to generate code and store data. Default is - mcmodel=small. Possible <mem_model> values are:
small -- Restrict code and data to the first 2GB of address space. Use relative addressing.
medium -- Restrict code to the first 2GB. Code access uses IP-relative addressing, but data accesses require absolute addressing.
large -- Places no memory restriction on code or data. All accesses of code and data must be done with absolute address- ing.
I wonder if -m64 without any additional options limits code and data to 2GB? That would be not very logical, but I'm not sure.
- Volodya
Hmm. Presumably, -m64
Committed to trunk revision 43900. -- Noel
K. Noel Belcourt wrote:
Hi Beman,
A couple of comments on RC2. It builds fine with the darwin toolset (gcc 4.0.1) on an Intel core2 running Tiger. All the documentation links I checked worked okay. There're a couple of issues building with the Intel compilers under Tiger (the intel-darwin toolset).
(1) The configure script doesn't recognize the intel-darwin toolset. I've attached patches to both tools/jam/src/build.sh and tools/jam/src/build.jam so the intel-darwin toolset is recognized.
Please go ahead and apply these to both trunk and release.
With these patches, users with intel compilers on the Mac should be able to:
./configure --with-toolset=intel-darwin ; make
Is that mentioned in the Getting Started docs? If not please update those docs.
(2) Python fails to compile when the intel compilers generate 64 bit code, the fix is to build 32 bit if you need python.
(3) The address-model property in intel-darwin.jam isn't properly configured. I've attached a patch to fix tools/build/v2/tools/intel-darwin.jam to make this work with address-model=32,64.
Please go ahead and apply to both trunk and release. I'm a bit worried about these patches introducing unexpected glitches. It would be reassuring if you could retest once they appear in a snapshot.
(4) The regex library (built shared as a dylib), doesn't link due to, apparently, missing symbols in the runtime.
__ZNSt15basic_streambufIwSt11char_traitsIwEE8overflowEj __ZNSt15basic_streambufIwSt11char_traitsIwEE9pbackfailEj
(5) The filesystem library (built shared) fails to link building 32 bit for an internal link error.
ld: internal error: output_local_symbols() inconsistent local symbol count
Aren't those both Apple problems? I'm not sure we can do anything about them. Thanks, --Beman
Beman Dawes wrote:
K. Noel Belcourt wrote:
Hi Beman,
A couple of comments on RC2. It builds fine with the darwin toolset (gcc 4.0.1) on an Intel core2 running Tiger. All the documentation links I checked worked okay. There're a couple of issues building with the Intel compilers under Tiger (the intel-darwin toolset).
(1) The configure script doesn't recognize the intel-darwin toolset. I've attached patches to both tools/jam/src/build.sh and tools/jam/src/build.jam so the intel-darwin toolset is recognized.
Please go ahead and apply these to both trunk and release.
Hm, applying those to release wont work. The bjam on release is tagged to be the 3.1.16 bjam release. I'd have to do another bjam release, wih ensuing testing on the release branch to make sure it doesn't cause other problems.
I'm a bit worried about these patches introducing unexpected glitches. It would be reassuring if you could retest once they appear in a snapshot.
:-) -- -- 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
On Mar 25, 2008, at 8:18 AM, Rene Rivera wrote:
Beman Dawes wrote:
K. Noel Belcourt wrote:
There're a couple of issues building with the Intel compilers under Tiger (the intel-darwin toolset).
(1) The configure script doesn't recognize the intel-darwin toolset. I've attached patches to both tools/jam/src/build.sh and tools/jam/src/build.jam so the intel-darwin toolset is recognized.
Please go ahead and apply these to both trunk and release.
Hm, applying those to release wont work. The bjam on release is tagged to be the 3.1.16 bjam release. I'd have to do another bjam release, wih ensuing testing on the release branch to make sure it doesn't cause other problems.
Okay, no problem. I'll work with Volodya and Rene to get these into the trunk instead. -- Noel
K. Noel Belcourt wrote:
On Mar 25, 2008, at 8:18 AM, Rene Rivera wrote:
Beman Dawes wrote:
K. Noel Belcourt wrote:
There're a couple of issues building with the Intel compilers under Tiger (the intel-darwin toolset).
(1) The configure script doesn't recognize the intel-darwin toolset. I've attached patches to both tools/jam/src/build.sh and tools/jam/src/build.jam so the intel-darwin toolset is recognized. Please go ahead and apply these to both trunk and release. Hm, applying those to release wont work. The bjam on release is tagged to be the 3.1.16 bjam release. I'd have to do another bjam release, wih ensuing testing on the release branch to make sure it doesn't cause other problems.
Okay, no problem. I'll work with Volodya and Rene to get these into the trunk instead.
OK, thanks! --Beman
Joel de Guzman wrote:
Johannes Brunen wrote:
Beman Dawes wrote:
In the meantime, have you tried a more modern version of VC++? The free download of VC++ 2008 Express Edition, for example. Ok, I just tried the same procedure with the VC++ 2005 (i.e. 8.0) compiler with the same result. It does not generate the .pyd files, neither in release mode nor in debug mode.
Johannes, Starting from Boost 1.35, bjam erases the generated executables (e.g. pyd file) after the test has concluded to conserve disk space. To keep bjam from doing that, pass --preserve-test-targets to bjam.
Err, does Boost.Python tutorial uses test targets? If yes, why? If no, why would any targets get removed? - Volodya
Vladimir Prus wrote:
Joel de Guzman wrote:
Johannes Brunen wrote:
Beman Dawes wrote:
In the meantime, have you tried a more modern version of VC++? The free download of VC++ 2008 Express Edition, for example. Ok, I just tried the same procedure with the VC++ 2005 (i.e. 8.0) compiler with the same result. It does not generate the .pyd files, neither in release mode nor in debug mode. Johannes, Starting from Boost 1.35, bjam erases the generated executables (e.g. pyd file) after the test has concluded to conserve disk space. To keep bjam from doing that, pass --preserve-test-targets to bjam.
Err, does Boost.Python tutorial uses test targets? If yes, why?
Err, I needed something to: 1) build the hello world 2) run it 3) show the user the result is what's expected If there's a better way of doing this, I'm all ears. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
on Mon Mar 24 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
Johannes Brunen wrote:
Beman Dawes wrote:
In the meantime, have you tried a more modern version of VC++? The free download of VC++ 2008 Express Edition, for example. Ok, I just tried the same procedure with the VC++ 2005 (i.e. 8.0) compiler with the same result. It does not generate the .pyd files, neither in release mode nor in debug mode.
Johannes, Starting from Boost 1.35, bjam erases the generated executables (e.g. pyd file) after the test has concluded to conserve disk space. To keep bjam from doing that, pass --preserve-test-targets to bjam.
This probably ought not be the default for Boost.Build anymore. It would be easy enough to pass --erase-test-targets to the driver script for testers. Thoughts? -- Dave Abrahams Boost Consulting http://boost-consulting.com
David Abrahams wrote:
on Mon Mar 24 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
Johannes Brunen wrote:
Beman Dawes wrote:
In the meantime, have you tried a more modern version of VC++? The free download of VC++ 2008 Express Edition, for example. Ok, I just tried the same procedure with the VC++ 2005 (i.e. 8.0) compiler with the same result. It does not generate the .pyd files, neither in release mode nor in debug mode.
Johannes, Starting from Boost 1.35, bjam erases the generated executables (e.g. pyd file) after the test has concluded to conserve disk space. To keep bjam from doing that, pass --preserve-test-targets to bjam.
This probably ought not be the default for Boost.Build anymore. It would be easy enough to pass --erase-test-targets to the driver script for testers. Thoughts?
I think you are right. - Volodya
participants (8)
-
Beman Dawes -
David Abrahams -
Joel de Guzman -
Johannes Brunen -
K. Noel Belcourt -
Rene Rivera -
Vladimir Prus -
Vladimir Prus