gh-115737: Correct the install name for non-framework macOS libPython builds. #115750
Conversation
There was a problem hiding this comment.
Thanks for looking into this. I think we can greatly simplify the change to just reverting the original change to the libpython.dylib target in the Makefile. As far as I can see, that's the only problem here as that target is only made in the macOS --enable-shared case. Then there is no need to rename PYTHONFRAMEWORKINSTALLNAMEPREFIX as it will only be used for framework builds. And this shouldn't cause any problems for further iOS changes since only frameworks builds are supported there.
Makefile.pre.in
Outdated
| @@ -869,7 +869,7 @@ libpython3.so: libpython$(LDVERSION).so | |||
| $(BLDSHARED) $(NO_AS_NEEDED) -o $@ -Wl,-h$@ $^ | |||
|
|
|||
| libpython$(LDVERSION).dylib: $(LIBRARY_OBJS) | |||
| $(CC) -dynamiclib $(PY_CORE_LDFLAGS) -undefined dynamic_lookup -Wl,-install_name,$(PYTHONFRAMEWORKINSTALLNAMEPREFIX)/lib/libpython$(LDVERSION).dylib -Wl,-compatibility_version,$(VERSION) -Wl,-current_version,$(VERSION) -o $@ $(LIBRARY_OBJS) $(DTRACE_OBJS) $(SHLIBS) $(LIBC) $(LIBM); \ | |||
| $(CC) -dynamiclib $(PY_CORE_LDFLAGS) -undefined dynamic_lookup -Wl,-install_name,$(DYLIBINSTALLNAMEPREFIX)/lib/libpython$(LDVERSION).dylib -Wl,-compatibility_version,$(VERSION) -Wl,-current_version,$(VERSION) -o $@ $(LIBRARY_OBJS) $(DTRACE_OBJS) $(SHLIBS) $(LIBC) $(LIBM); \ | |||
There was a problem hiding this comment.
Since this target is only used for macOS --enable-shared builds (and not for framework or non-shared builds), I think the only change we really need is to revert the original change here, though still removing the obsolete -Wl,-single_module. Then there is no need to make any of the other rename changes. So:
$(CC) -dynamiclib $(PY_CORE_LDFLAGS) -undefined dynamic_lookup -Wl,-install_name,$(prefix)/lib/libpython$(LDVERSION).dylib -Wl,-compatibility_version,$(VERSION) -Wl,-current_version,$(VERSION) -o $@ $(LIBRARY_OBJS) $(DTRACE_OBJS) $(SHLIBS) $(LIBC) $(LIBM); \
There was a problem hiding this comment.
That's a good point - I'm not sure why I changed this one in the original patch. I can only assume I got a bit search-and-replace happy looking for install_name.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
|
I have made the requested changes; please review again |
…ed library builds. (pythongh-115750)
…ed library builds. (pythongh-115750)
…ed library builds. (pythongh-115750)
…d library builds. (pythongh-115750)
…ed library builds. (pythongh-115750)
…ed library builds. (pythongh-115750)
…ed library builds. (pythongh-115750)
…ed library builds. (pythongh-115750)
…d library builds. (pythongh-115750)
…ed library builds. (pythongh-115750)
…d library builds. (pythongh-115750)
…ed library builds. (pythongh-115750)
…ed library builds. (pythongh-115750)
…ed library builds. (pythongh-115750)
#115120 refactored the configure/Makefile targets in preparation for supporting iOS framework builds. However, this refactoring broke the
install_nameused for non-framework macOS builds installed into a non-default location (as is used by pyenv).This PR restores the old behaviour using
${prefix}as the prefix for the install_name for non-framework macOS builds. It also renames the configuration variable to reflect the fact that it is a generic dylib configuration prefix, not a framework-specific prefix.CC @native-api @ned-deily @ronaldoussoren
Refs pyenv/pyenv#2903