| msg115875 - (view) |
Author: Sébastien Sablé (sable) |
Date: 2010-09-08 14:23 |
| I have the following error when compiling the last rev of branch py3k on an AIX 6 system: ./Modules/makexp_aix Modules/python.exp . libpython3.2.a; xlc_r -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/sgbd_product/oracle/10.2.0/lib32 -L/sgbd_product/oracle/10.2.0/lib32 -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/sgbd_product/oracle/10.2.0/lib32 -L/sgbd_product/oracle/10.2.0/lib32 -Wl,-bE:Modules/python.exp -lld -o python Modules/python.o libpython3.2.a -lintl -ldl -lm ld: 0711-596 SEVERE ERROR: Object libpython3.2.a[ceval.o] An RLD for section 2 (.data) refers to symbol 0, but the storage class of the symbol is not C_EXT or C_HIDEXT. Python 3.1.2 or Python 2.7 both compile fine. I also tried rev 73580 of this branch which compiled fine also. I will try to find the rev number where this problem started. |
|
|
| msg115878 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2010-09-08 14:58 |
| I would suggest trying r80723 and then r80724. |
|
|
| msg115881 - (view) |
Author: Sébastien Sablé (sable) |
Date: 2010-09-08 15:28 |
| For the moment I have: r73580 = OK r83318 = OK r83584 = OK r83800 = OK r84000 = ERR r84522 = ERR |
|
|
| msg115882 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-09-08 15:31 |
| Le mercredi 08 septembre 2010 à 15:28 +0000, Sébastien Sablé a écrit : > Sébastien Sablé <sable@users.sourceforge.net> added the comment: > > For the moment I have: > > r73580 = OK > r83318 = OK > r83584 = OK > r83800 = OK > > r84000 = ERR Then perhaps r83985 / r83986. |
|
|
| msg115883 - (view) |
Author: Sébastien Sablé (sable) |
Date: 2010-09-08 16:09 |
| Bingo, you got it. r73580 = OK r83318 = OK r83584 = OK r83800 = OK r83900 = OK r83950 = OK r83985 = OK r83986 = ERR r84000 = ERR r84522 = ERR It was commited by some guy named "antoine.pitrou" ;) The linker thinks that we have some symbol named "0" or something like that. I guess the xlc compiler is not happy with one of the uses of the USE_COMPUTED_GOTOS constant. |
|
|
| msg115884 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-09-08 16:33 |
| > Bingo, you got it. > > r73580 = OK > r83318 = OK > r83584 = OK > r83800 = OK > r83900 = OK > r83950 = OK > r83985 = OK > r83986 = ERR > r84000 = ERR > r84522 = ERR > > It was commited by some guy named "antoine.pitrou" ;) > > The linker thinks that we have some symbol named "0" or something like that. > I guess the xlc compiler is not happy with one of the uses of the USE_COMPUTED_GOTOS constant. So if you configure --without-computed-gotos, does it compile fine? |
|
|
| msg115885 - (view) |
Author: Sébastien Sablé (sable) |
Date: 2010-09-08 16:52 |
| Yes it works if I explicitly specify --without-computed-gotos |
|
|
| msg115887 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-09-08 17:04 |
| By the way, all traces of 0711-596 on the Web seem to point to IBM compiler errata. Apparently xlc tries to support computed gotos (which is originally a GCC-specific feature) but doesn't do it very well. The support for computed gotos is detected automatically by the configure script; --without-computed-gotos helps override the detection. I would close this issue as a compiler bug, especially given that there's a configure switch to circumvent it. |
|
|
| msg115936 - (view) |
Author: Sébastien Sablé (sable) |
Date: 2010-09-09 10:30 |
| OK for me to close it as a compiler bug since there is a workaround. It would be great if we could detect this compiler and deactivate this optimization automatically, but I am too lazy to search the xlc compiler documentation for a way to do that. I suppose that the people who will be confronted to this problem (the 4 of us in the world who compile Python on AIX with xlc) will find this issue and the correct flag to make it work. Also I am using xlc instead of gcc because it provides some better optimization for this architecture. If the computed gotos optimization only works with gcc, then it may be more interesting to use the gcc compiler instead (I will do some benchs). |
|
|
| msg116199 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2010-09-12 14:17 |
| I know this is closed, but traditionally, we have put stuff like this into README (not sure whether Sébastien read the README :-). So if anybody feel like adding some text, go ahead. In return, feel also free to take out some text that talks about very old problems. |
|
|
| msg116201 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-09-12 14:49 |
| Actually, there's a Misc/AIX-NOTES file which needs updating. Sébastien, do you want to do that? |
|
|
| msg116291 - (view) |
Author: Sébastien Sablé (sable) |
Date: 2010-09-13 08:33 |
| Yes, no problem; I will update the Misc/AIX-NOTES file with all the information I have been collecting recently on Python with AIX. I will do that when I will have solved some remaining issues I have on AIX, and also when I will have checked with AIX 5.3 as well (I am currently focused on 6.1). |
|
|