Skip to content

Python 3.13a5 fails to build on AIX #117088

Closed

Description

@kadler

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

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    on Mar 20, 2024
  2. ned-deily commented on Mar 20, 2024

    @ned-deily
    Member
  3. mhsmith commented on Mar 20, 2024

    @mhsmith
    Member

    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.

  4. Ganeshkumhar1 commented on Apr 7, 2025

    @Ganeshkumhar1

    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

  5. kadler commented on Apr 7, 2025

    @kadler
    ContributorAuthor

    @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.

  6. mhsmith commented on Apr 8, 2025

    @mhsmith
    Member

    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.

  7. encukou commented on Apr 16, 2025

    @encukou
    Member
  8. ayappanec commented on Apr 16, 2025

    @ayappanec
    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.

  9. added a commit that references this issue on Apr 16, 2025
  10. serhiy-storchaka commented on Apr 16, 2025

    @serhiy-storchaka
    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?

  11. mhsmith commented on Apr 16, 2025

    @mhsmith
    Member

    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.

  12. added a commit that references this issue on May 10, 2025
  13. added a commit that references this issue on May 10, 2025
  14. added a commit that references this issue on May 10, 2025
  15. added 2 commits that reference this issue on May 10, 2025
  16. added a commit that references this issue on Jul 12, 2025
  17. added a commit that references this issue on Aug 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.13only security fixesOS-unsupportedbuildThe build process and cross-buildtype-bugAn unexpected behavior, bug, or error

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions