We started to override the extension names of Mach-O bundle to ".bundle"[1] in 2009. While the ".bundle" had been recommended by Apple, now Apple is being vague on this issue by removing the relevant documentations[3]. The Mach-O bundles distributed by Apple itself are inconsistent in naming. In my macOS Majove, the Apple-customized Python modules have ".so" but the Ruby ones have ".bundle". Many "application bundles" of completely different types also have the ".bundle" naming[4], adding more confusion. The Fink project[2] documented that .bundle was used to respect Apple (in the old days) and .so was for compatibility of ported software. Considering we are providing a complete GNU environment ported to macOS, .so makes more sense now. How do you think? 1. https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=ca34434d1590d94e02d9595951b47185cbf5b053 2. https://www.finkproject.org/doc/porting/shared.php 3. https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=10c8fb27f64119535f5efe6d1f216ca91e368e0d 4. https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html Reproducible: Always
My main "problem" is with changing this for existing installs. I think the patch I maintained over the years for Python to use .bundle also made sure .so was accepted in later versions. So this should be OK when we'd change it, as both would be accepted. What exactly is the proposal? - if multiple packages (Python, Ruby) use different namings, are we going to patch them from .bundle to .so, as we patch from .so to .bundle now? - how are we going to change get_modname so as not to break anything? - is it worth it? I don't quite get the "GNU env" though, we still use Mach-O, and the linker isn't GNU, but Apple or LLVM. Do we know how much packages see changes if we undo the libtool change?
I am debating with myself which should be better, and don't have a plan or proposal. Your questions are enlightening, I need to reflect and experiment before getting an answer. I think it worthwhile to document the discussion. With Prefix, we are offering users a unified look and feel of GNU/Linux on many platforms, even if the tools building it is from BSD-derivatives.
Well, USERLAND=GNU, but ELIBC=Darwin and KERNEL=Darwin. So, that said, we don't have to do ELF on macOS. I mean if we could, who knows it would help, but the host isn't using ELF, and some libs you can't replace, or upstreams who don't expect this. So why persue this in the current status-quo. Only a very few don't know macOS is using dylibs. (Notable example being bzip2.) I think for the .bundle, you have a good point that nowadays it seems to have converged into .so. The migration path, I'm not sure is going to be painless, though. And in a way, what does it make a difference for the end-user? We setup the entire ecosystem to deal with it this way. Besides, bundles, really shouldn't be produced any more these days. dlopen() can handle dylibs nowadays, and that's what is happening on ELF too. So it would probably better to start yanking out bundle support from buildsystems (teach them to create a dynamic lib instead). One subtle difference between a bundle and a dylib is the symbol resolution. bundles expect stuff to be unresolved, as in, resolved by the symbols present in the process calling dlopen(). dylibs expect symbols to be resolved at link time (when the lib is created). However, there are ways to suppress that (-undefined suppress or something like that), and libtool knows about it. Libtool actually knows the different purpose for a library, to be dlopen()ed or a proper shared library. This really is the crux here. Apple in the past believed that usecase should be handled differently, thus named differently. ELF never really cared, it was just that the producer had to be sure all symbols would be resolvable eventually.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f4e9370d76817e46724cfbd5f1aaa9212e11dc25 commit f4e9370d76817e46724cfbd5f1aaa9212e11dc25 Author: Benda Xu <heroxbd@gentoo.org> AuthorDate: 2023-07-17 00:05:11 +0000 Commit: Benda Xu <heroxbd@gentoo.org> CommitDate: 2023-07-17 01:17:37 +0000 dev-python/meson-python: recognize python modules on Prefix/macOS keyword 0.13.2 for ~arm64-macos, ~x64-macos. At Prefix/macOS we conventionally name the python modules as .bundle. Bug: https://bugs.gentoo.org/910401 Signed-off-by: Benda Xu <heroxbd@gentoo.org> .../files/meson-python-0.13.2_Mach-O_bundle.patch | 21 +++++++++++++++++++++ dev-python/meson-python/meson-python-0.13.2.ebuild | 4 +++- 2 files changed, 24 insertions(+), 1 deletion(-)
Additional point of information: Perl's (5.38.0-r1) hints for Darwin contain: # Shared library extension is .dylib. # Bundle extension is .bundle. so='dylib'; dlext='bundle'; usedl='define';
