Skip to content

Python 3.13a5 fails to build on AIX #117088

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

Open
kadler opened this issue Mar 20, 2024 · 9 comments
Open

Python 3.13a5 fails to build on AIX #117088

kadler opened this issue Mar 20, 2024 · 9 comments
Labels
build The build process and cross-build OS-unsupported type-bug An unexpected behavior, bug, or error

Comments

@kadler
Copy link
Contributor

kadler commented Mar 20, 2024

Bug report

Bug description:

gcc -pthread -maix64 -bI:Modules/python.exp -Wl,-blibpath:/QOpenSys/pkgs/lib:/QOpenSys/usr/lib  -lutil  -Wl,-hlibpython3.13.so ...
ld: 0706-012 The -h flag is not recognized.
ld: 0706-006 Cannot find or open library file: -l ibpython3.13.so
	ld:open(): No such file or directory

-h is not a valid linker flag on AIX. This seems to be a regression introduced in fa1d675309c6a08b0833cf25cffe476c6166aba3 as previously on AIX it would have gone in to the else leg and not used this flag.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Other

Linked PRs

@kadler kadler added the type-bug An unexpected behavior, bug, or error label Mar 20, 2024
@ned-deily
Copy link
Member

@mhsmith

@mhsmith
Copy link
Member

mhsmith commented Mar 20, 2024

Apparently AIX doesn't use the ELF format, so this argument (which is the same as -soname) isn't applicable on that platform. If everything worked without it before, then the simplest solution would be to omit that argument on AIX.

@Ganeshkumhar1
Copy link

Is there any fix available for this issue. ? I am hitting same while building 3.13.2 on AIX @mhsmith @kadler
do we need to revert the changes in fa1d675309c6a08b0833cf25cffe476c6166aba3

@picnixz picnixz added build The build process and cross-build OS-unsupported labels Apr 7, 2025
@kadler
Copy link
Contributor Author

kadler commented Apr 7, 2025

@Ganeshkumhar1 For our local builds, we just patched it to remove the -soname option entirely. Obviously, not an upstreamable change, but for our platform-specific builds it works for us:

--- a/Makefile.pre.in
+++ b/Makefile.pre.in
@@ -910,10 +910,7 @@
 	$(AR) $(ARFLAGS) $@ $(LIBRARY_OBJS)
 
 libpython$(LDVERSION).so: $(LIBRARY_OBJS) $(DTRACE_OBJS)
-	$(BLDSHARED) -Wl,-h$(INSTSONAME) -o $(INSTSONAME) $(LIBRARY_OBJS) $(MODLIBS) $(SHLIBS) $(LIBC) $(LIBM)
-	if test $(INSTSONAME) != $@; then \
-		$(LN) -f $(INSTSONAME) $@; \
-	fi
+	$(BLDSHARED) -o $@ $(LIBRARY_OBJS) $(MODLIBS) $(SHLIBS) $(LIBC) $(LIBM);
 
 libpython3.so:	libpython$(LDVERSION).so
 	$(BLDSHARED) $(NO_AS_NEEDED) -o $@ -Wl,-h$@ $^

I don't understand enough about the reason for removing the if check as part of the Android support PR to know what the proper fix is to support everybody.

@mhsmith
Copy link
Member

mhsmith commented Apr 8, 2025

The if check was removed because on Android the SONAME is the same as the filename (libpython3.13.so), so the library was previously buit with no SONAME at all, which caused problems when linking things against it (i.e. extension modules).

If we need to omit this argument on AIX, then the proper fix would be to simply do that with a platform check.

@encukou
Copy link
Member

encukou commented Apr 16, 2025

cc AIX experts: @edelsohn, @ayappanec

@ayappanec
Copy link
Contributor

@encukou Thanks for notifying this.
Agree with @mhsmith , that the proper fix would be to do this under a platform check.
Let me work on a PR to fix this.

ayappanec added a commit to ayappanec/cpython that referenced this issue Apr 16, 2025
@serhiy-storchaka
Copy link
Member

I suppose that the following patch also should fix issue on AIX:

diff --git a/Makefile.pre.in b/Makefile.pre.in
index e41a26e469d..1f9d90ef385 100644
--- a/Makefile.pre.in
+++ b/Makefile.pre.in
@@ -999,9 +999,11 @@ $(LIBRARY): $(LIBRARY_OBJS)
        $(AR) $(ARFLAGS) $@ $(LIBRARY_OBJS)
 
 libpython$(LDVERSION).so: $(LIBRARY_OBJS) $(DTRACE_OBJS)
-       $(BLDSHARED) -Wl,-h$(INSTSONAME) -o $(INSTSONAME) $(LIBRARY_OBJS) $(MODLIBS) $(SHLIBS) $(LIBC) $(LIBM)
        if test $(INSTSONAME) != $@; then \
+               $(BLDSHARED) -Wl,-h$(INSTSONAME) -o $(INSTSONAME) $(LIBRARY_OBJS) $(MODLIBS) $(SHLIBS) $(LIBC) $(LIBM); \
                $(LN) -f $(INSTSONAME) $@; \
+       else \
+               $(BLDSHARED) -o $@ $(LIBRARY_OBJS) $(MODLIBS) $(SHLIBS) $(LIBC) $(LIBM); \
        fi
 
 libpython3.so: libpython$(LDVERSION).so

@mhsmith, does it break Android build?

@mhsmith
Copy link
Member

mhsmith commented Apr 16, 2025

Yes, it would break Android because it would take the else branch and build libpython without an SONAME. This means extension modules linked against it would have no NEEDED entry for libpython, and would be unable to resolve their libpython symbols at runtime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build The build process and cross-build OS-unsupported type-bug An unexpected behavior, bug, or error
Projects
Status: No status
Development

No branches or pull requests

8 participants