[Boost][Python] Fails for gcc-cygwin-3.4.4
Hello, (Please ignore this if these fails have been sorted out already.) All the fails for gcc 3.4.4 on cygwin seem to be down to __int64 not being defined properly. According to google, cygwin on Windows doesn't define __int64 (at least for gcc). Adding "-D__int64=long long" to the command line sounds (<cxxflags>?) like it should fix it, although I've no idea if making users do that themselves is frowned upon? Some links: http://tinyurl.com/2k5922 http://tinyurl.com/2txysc Regards, Darren
Darren Garvey wrote:
All the fails for gcc 3.4.4 on cygwin seem to be down to __int64 not being defined properly. According to google, cygwin on Windows doesn't define __int64 (at least for gcc). Adding "-D__int64=long long" to the command line sounds (<cxxflags>?) like it should fix it, although I've no idea if making users do that themselves is frowned upon?
Unfortunately this isn't the _real_ problem. It is simple enough to have the missing type (long long aka. _int64) defined. I adjusted pyconfig.h for testing, until I recognized what the problem really is: The g++ in its default configuration creates dll,s that depend on the cygwin1.dll. The used python executable depends on msvc.dll. I do not understand enough about the python wrapper lib, but my bets are, it will not work loading a plugin that depends on a different runtime dll. If I am correct, I think the only resolution is to mark this combination as n/a. The deeper problem: detecting the link compatibility will need more research, and has to be addressed within Boost.Build I guess. Roland
Roland Schwarz wrote:
The g++ in its default configuration creates dll,s that depend on the cygwin1.dll. The used python executable depends on msvc.dll.
I do not understand enough about the python wrapper lib, but my bets are, it will not work loading a plugin that depends on a different runtime dll.
If I am correct, I think the only resolution is to mark this combination as n/a.
The deeper problem: detecting the link compatibility will need more research, and has to be addressed within Boost.Build I guess.
AFAIU, you can compile your own C++ code with 'g++ -mno-cygnus' on cygwin, and are then able to link with a windows-native python runtime. That's the equivalent of using a mingw toolchain directly. I'm not sure this is the best time to experiment with toolchains, though, so marking this variant as not available may be the right thing to do. HTH, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld <seefeld@sympatico.ca> writes:
Roland Schwarz wrote:
The g++ in its default configuration creates dll,s that depend on the cygwin1.dll. The used python executable depends on msvc.dll.
I do not understand enough about the python wrapper lib, but my bets are, it will not work loading a plugin that depends on a different runtime dll.
If I am correct, I think the only resolution is to mark this combination as n/a.
The deeper problem: detecting the link compatibility will need more research, and has to be addressed within Boost.Build I guess.
AFAIU, you can compile your own C++ code with 'g++ -mno-cygnus' on
it's -mno-cygwin
cygwin, and are then able to link with a windows-native python runtime.
That's the equivalent of using a mingw toolchain directly.
I'm not sure this is the best time to experiment with toolchains, though, so marking this variant as not available may be the right thing to do.
Boost.Python has always worked with Cygwin GCC, but if you don't use -mno-cygwin, you have to use the cygwin version of Python (the one installed when you select it in the Cygwin installer). Currently the Python support in BBv2 on Windows and Cygwin is a total mess, which may explain why it isn't working for you. I'm trying to fix that up now. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Boost.Python has always worked with Cygwin GCC, but if you don't use -mno-cygwin, you have to use the cygwin version of Python (the one installed when you select it in the Cygwin installer). Currently the Python support in BBv2 on Windows and Cygwin is a total mess, which may explain why it isn't working for you. I'm trying to fix that up now.
IMHO -mno-cygwin _is_ _not_ cygwin, but mingw! Currently the cygwin/mingw support in bbv2 also is a mess. Python only builds on top of this. :-( Open questions: 1) should cygwin / mingw tag be a *) part of the toolset name like in intel-win intel-linux *) part of the version e.g. gcc-3.4.4-cygwin *) be an independant feature (like is now) 2) Shouldn't cygwin/mingw rather be modelled as a stdlib property? stdlib=native/cygwin/mingw 3) We will need canonical toolset names for use in Jamfile's. The current situation where users can invent arbitrary version-names defeats this. Regards, Roland
[ followups to the boost-build list, please ] Roland Schwarz <roland.schwarz@chello.at> writes:
David Abrahams wrote:
Boost.Python has always worked with Cygwin GCC, but if you don't use -mno-cygwin, you have to use the cygwin version of Python (the one installed when you select it in the Cygwin installer). Currently the Python support in BBv2 on Windows and Cygwin is a total mess, which may explain why it isn't working for you. I'm trying to fix that up now.
IMHO -mno-cygwin _is_ _not_ cygwin, but mingw!
Whatever; when I say "Cygwin GCC" I mean the build of GCC you get when you install Cygwin.
Currently the cygwin/mingw support in bbv2 also is a mess. Python
You mean Boost.Python?
only builds on top of this. :-(
On top of what?
Open questions:
1) should cygwin / mingw tag be a *) part of the toolset name like in intel-win intel-linux
No. win/linux is not really part of the toolset name; it's a subfeature of toolset=intel. However, that role should more properly be played by the "target-os" feature IMO.
*) part of the version e.g. gcc-3.4.4-cygwin *) be an independant feature (like is now)
2) Shouldn't cygwin/mingw rather be modelled as a stdlib property? stdlib=native/cygwin/mingw
No; it has almost nothing to do with the C++ standard library.
3) We will need canonical toolset names for use in Jamfile's. The current situation where users can invent arbitrary version-names defeats this.
Volodya and I discussed this just now. We agree with you about point 3. Here's what we came up with, to address this issue. * -mno-cygwin really should be controlled by target-os. Cygwin and Win32 are best viewed as different OSes, since Cygwin provides a POSIX API. When using a version of Cygwin GCC that supports -mno-cygwin, by default it should target the host OS. That is, when building from a cygwin bjam, the default would be not to pass -mno-cygwin, and when building from a Win32 bjam, the default would be to pass -mno-cygwin. In either case, the default would be overridable by passing target-os=... * If we drop the ability to arbitrarily choose a version string, we need a way to identify different configurations of a toolset that may have the same version number. For example: - You may have both Cygwin and MinGW gcc 3.4 installed - You may want to experiment with a special gcc build having C++0x features - You may need a convenient way to identify a special configuration of an existing toolset. The solution we came up with is to add an optional argument to "using" that allows you to create a special toolset subfeature on-the-fly, something like: using gcc : 3.4 : /usr/local/conceptgcc/bin/g++ : conceptgcc ; This feature could then also be used to identify the toolset on the command-line, something like: bjam toolset=conceptgcc -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
* If we drop the ability to arbitrarily choose a version string, we need a way to identify different configurations of a toolset that may have the same version number. For example:
- You may have both Cygwin and MinGW gcc 3.4 installed
- You may want to experiment with a special gcc build having C++0x features
- You may need a convenient way to identify a special configuration of an existing toolset.
The solution we came up with is to add an optional argument to "using" that allows you to create a special toolset subfeature on-the-fly, something like:
using gcc : 3.4 : /usr/local/conceptgcc/bin/g++ : conceptgcc ;
This feature could then also be used to identify the toolset on the command-line, something like:
bjam toolset=conceptgcc
I'm actually not sure if using "toolset=XXX" like this to alias to some other set of properties is good idea -- we might end up with lots of corner cases. I'd much rather have some "user-defined" subfeature, and then use: gcc-3.4-conceptgcc, or maybe gcc-3.4 flavour=conceptgcc or maybe gcc-3.4 <some-better-feature-name>=conceptgcc But otherwise I agree with that Dave said. - Volodya
[How did this message end up on the boost developers' list? I set the followup-to header so that it would go to boost-build, *and* I explicitly asked for followups to go there at the top of my previous message.] on Wed Feb 21 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
David Abrahams wrote:
* If we drop the ability to arbitrarily choose a version string, we need a way to identify different configurations of a toolset that may have the same version number. For example:
- You may have both Cygwin and MinGW gcc 3.4 installed
- You may want to experiment with a special gcc build having C++0x features
- You may need a convenient way to identify a special configuration of an existing toolset.
The solution we came up with is to add an optional argument to "using" that allows you to create a special toolset subfeature on-the-fly, something like:
using gcc : 3.4 : /usr/local/conceptgcc/bin/g++ : conceptgcc ;
This feature could then also be used to identify the toolset on the command-line, something like:
bjam toolset=conceptgcc
I'm actually not sure if using "toolset=XXX" like this to alias to some other set of properties is good idea -- we might end up with lots of corner cases.
What kind of corner cases?
I'd much rather have some "user-defined" subfeature,
Yeah, that's exactly what using gcc : 3.4 : /usr/local/conceptgcc/bin/g++ : conceptgcc ; is supposed to create. Or at least, a value of an implicit user-defined subfeature, e.g. <flavor>conceptgcc
and then use:
gcc-3.4-conceptgcc,
Fine.
or maybe
gcc-3.4 flavour=conceptgcc
I don't like that one, because, for example, you might want to build with plain gcc-3.4 as well as the conceptgcc flavor.
or maybe
gcc-3.4 <some-better-feature-name>=conceptgcc
The US English spelling of flavor is shorter. "spin?" "charm?" Just kidding; I think "flavor" is fine. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Stefan Seefeld <seefeld@sympatico.ca> writes:
The deeper problem: detecting the link compatibility will need more research, and has to be addressed within Boost.Build I guess. AFAIU, you can compile your own C++ code with 'g++ -mno-cygnus' on
it's
-mno-cygwin
Sorry for the lapsus. That's what I meant.
cygwin, and are then able to link with a windows-native python runtime.
That's the equivalent of using a mingw toolchain directly.
I'm not sure this is the best time to experiment with toolchains, though, so marking this variant as not available may be the right thing to do.
Boost.Python has always worked with Cygwin GCC, but if you don't use -mno-cygwin, you have to use the cygwin version of Python (the one installed when you select it in the Cygwin installer). Currently the Python support in BBv2 on Windows and Cygwin is a total mess, which may explain why it isn't working for you. I'm trying to fix that up now.
I wasn't talking about boost. I have been able to compile another project (Synopsis, to be specific) with 'g++ -mno-cygwin', and then linking it with the windows Python libs. That worked fine. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
participants (5)
-
Darren Garvey -
David Abrahams -
Roland Schwarz -
Stefan Seefeld -
Vladimir Prus