-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AIX shared library fix #40186
Comments
By default, the ld command only looks for *.a archives To recognize dynamic shared libaries (*.so), two flags Line 170 in the script should read: CCOPT="$CCOPT -Wl,-bM:SRE -Wl,-T512 -Wl,-H512 -brtl -brtl ... says you want to include libtk8.4.so -bnortllib ... says you do not want the semantics of This resolves a problem when Python is built with tk |
Logged In: YES I added a comment based on the above information. I don't Checked in as: |
Hi, I have modified a bit this patch to make it work with Python 2.5.2 (see It is a great enhancement for Python users on AIX to be able to use a We have various AIX 5.2 and 5.3 servers in the Sungard company where I What kind of access would you need in order to validate those patchs? thanks in advance |
Sébastien, what does your patch change exactly? Does it build a shared |
Hum, I tried to recompile Python without the --enable-shared option on I will do a bit of cleanup in my environment and try to make a version |
Shouldn't line 170 be CCOPT="$CCOPT -Wl,-bM:SRE -Wl,-T512 -Wl,-H512 -Wl,-brtl instead of CCOPT="$CCOPT -Wl,-bM:SRE -Wl,-T512 -Wl,-H512 -brtl -bnortllib -lm -o Otherwise the -brtl and -bnortllib flags are interpreted as compiler gcc: unrecognized option '-brtl' |
Addition to last message: More importantly, without "-Wl", the flags are not passed to the linker |
Hi, As reported in this issue and bpo-1756343 and bpo-1542544, Python does not produce a shared python library on AIX even with the --enable-shared flag. I had provided a patch to correct that, but it was breaking static compilation of Python on AIX. We are upgrading our AIX build environment to AIX 6.1 and Python 2.6.6, so I took the time to review this patch again and to clean it so that it works well when compiling Python statically and dynamically, with either gcc and xlc_r. I attach the resulting patch, and the build and unit test logs. You can notice that not only this patch allows to compile Python dynamically on AIX, but also that it improves the unit tests results when compiling Python statically. For example with the xlc_r compiler and Python compiled statically, the results without the patch are: A minor issue with this patch is that "libpython2.6.so" is hardcoded in the ld_so_aix file. That should be modified by moving ld_so_aix to ld_so_aix.in and using $LDLIBRARY, or by using an explicit flag when calling ld_so_aix to compile libpythonx.y.so. If you agree to the principle of this patch, I can make the extra work to clean ld_so_aix and test this patch on Python 2.7 and 3.1. regards |
In dynamic builds, there seem to be lots of messages such as: ld: 0711-224 WARNING: Duplicate symbol: .PyLong_FromString Are you sure this is normal? In any case, if you find a way to cleanup ld_so_aix, this should probably be checked in anyway. I doubt anybody else tests under AIX, so it's reasonable to trust you on this. Even better if you manage to diagnose and/or fix some of the test failures, by the way. (if not, you can still open separate issues for each of them) |
Le 01/09/2010 00:16, Antoine Pitrou a écrit :
This is not normal, but I always had this warning and this does not
Great! this is the kind of answer I was looking for. I will cleanup my I will also correct as many unitary tests as possible with this platform. |
Hi, I have updated the patch and adapted it for Python 3.1.2:
I will provide another patch for Python 2.7 (nearly the same, but without the modification needed by pep-3121). regards |
Thank you. For the record, here is the patch adapted for 3.2 development branch. It looks ok to me. |
Here is the patch for Python 2.7. The only difference compared to Python 3.1.2 is that we don't rename init<modulname> to PyInit_<modulename>. |
Could this affect building extensions with gcc under AIX? Or does gcc delegate to the AIX linker? |
Yes Antoine, gcc only handles compilation; the linker is explicitly called through the ld_so_aix script which handles calling the native ld with the right flags to import symbols. I will check with gcc and attach the log on Wednesday (not at work tomorrow) but there should be no problem. |
Hum, forget my previous note;I checked ld_so_aix and it actually calls $CC to handle linking not ld. I suppose gcc will call the native ld. Anyway, I will run the test with gcc on Wednesday and know for sure if that works. |
Thank you! If it works, it's good for commit. |
Here are the build logs for Python 3.1.2 modified with this patch and compiled with gcc. I also compiled an extension not directly provided in Python source (cx_Oracle) and it worked fine also. |
Antoine, I wanted to test this improvement (and others) on the branch py3k (I was using Python 2.7 and Python 3.1.2 for the moment). But I have some issues compiling this branch, even without any patch (see bpo-9799). So you may want to wait for the other issue to be resolved before to commit this patch on branch py3k. |
Antoine, I tested this patch on py3k with both gcc and xlc in static and shared mode and I did not notice any issue. I attach the build and test logs. I think you can safely commit it. |
I've committed the latest patch in r84680 (3.x), r84682 (3.1) and r84683 (2.7). Perhaps you want to check it's ok. Thank you anyway! |
Great! Thanks Antoine. I checked quickly and there is a small correction to do on the 2.7 branch: this branch is different because there has been a change between python 2.x and 3.x in pep-3121 concerning the name of the entry function in a module (init<modulname> to PyInit_<modulename>) So you need to change this line in Modules/ld_so_aix.in from: Except for that it looks fine. I will continue to try to make all unitary tests pass on AIX. And I would like to setup a buildbot that will compile and test the trunk every day and post the log on a public web site, in order to help keep this platform well supported. |
Hi Micheal, I don't remember why "-L\$(srcdir)" was added since it has been quite a long time. I tried to recompile everything after removing it and everything compiled just fine, so I guess it can be removed. regards |
Hum, I was incorrect in previous note: Index: configure.in --- configure.in (revision 88422)
+++ configure.in (working copy)
@@ -1642,7 +1655,7 @@
then
case $ac_sys_system/$ac_sys_release in
AIX*)
- BLDSHARED="\$(srcdir)/Modules/ld_so_aix \$(CC) -bI:Modules/python.exp -L\$(srcdir)"
+ BLDSHARED="\$(srcdir)/Modules/ld_so_aix \$(CC) -bI:\$(srcdir)/Modules/python.exp"
LDSHARED="\$(BINLIBDEST)/config/ld_so_aix \$(CC) -bI:\$(BINLIBDEST)/config/python.exp"
;;
IRIX/5*) LDSHARED="ld -shared";; Also, I think there are other issues with building Python 3.2 with shared libraries. I am currently investigating. |
OK, Python with shared libraries is broken in trunk since the library was renamed to libpython3.2m. Index: Modules/ld_so_aix.in --- Modules/ld_so_aix.in (revision 88422)
+++ Modules/ld_so_aix.in (working copy)
@@ -131,7 +131,7 @@
shift
done
-if test "$objfile" = "libpython@VERSION@.so"; then
+if test "$objfile" = "libpython@VERSION@@ABIFLAGS@.so"; then
ldsocoremode="true"
fi |
This looks like it should (and could) go into 3.2 final. Agreed? |
Agreed. |
OK. Sébastien, could you make and attach a complete patch? |
Here is the full patch. |
Looks good to me. |
Committed in r88426. |
Interesting, didn't experience this to be necessary with Python-2.7.1 here... Maybe because I do an in-source build, haven't tried an out-of-source build at all. |
Are you using --enable-shared when compiling python? |
By the way... thanks Georg! |
Also Michael, I am working on the 3.2 branch, it may be different with Python 2.7.1 but I haven't tested yet. |
Georg, the non-abiflags portion seems to need backporting. |
Backported to 3.1 in r88560, 2.7 in r88568. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: