[MacPorts] #63164: py-libxml2 icu cctools - FAT libraries built on i386 Mac OS X Tiger fail to run
MacPorts
noreply at macports.org
Sat Jul 10 06:34:29 UTC 2021
#63164: py-libxml2 icu cctools - FAT libraries built on i386 Mac OS X Tiger fail to
run
-------------------------+--------------------
Reporter: bradleyCPA | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: | Keywords:
Port: |
-------------------------+--------------------
Comment (by kencu):
cctools-921 still has the various i386 and powerpc workarounds in it.
After that, things start to diverge. cctools-927 needed modest work to
compile back to 10.4, cctools-949 needed actual patching and had clear
errors in the i386 assembler that needed fixing, and now it turns out,
other places tool.
1. There is a reasonable argument to be made to roll back to cctools-921
on 10.4 Intel and PPC and probably peg them there forever.
1. For Leopard i386 and PowerPC the same argument could be made... the
i386 code is not being well tested, and probably not tested at all,
really. PPC code -- never.
1. I hate to peg SnowLeopard as it is doing so well -- the 64bit stuff
should be fine. The 32bit stuff -- I'm not sure. It seems to be working
well, but the same concerns arise. Not trivial to run the test suite
(there is a way, of course). No testing upstream.
I can picture a day where we peg all the systems that can manipulate i386
code (ie 10.13 and less) back to a reasonably tested cctools version,
maybe even cctools-921. That does put a lifespan on those systems, unless
we can start to use the llvm version of those tools, which are well
maintained (eg llvm-nm, etc).
I have been a bit slow to update cctools in MacPorts to the latest
cctools-973 in part because of these issues, and that is not right. We do
the same pegging on ld64 so there is certainly precedent for it in the
toolchain.
----
I'm not yet sure that the lipo 2048 alignment is causing the
libgcc.s.1.dylib to misload -- but it is possible. Only some of the
libraries have had lipo work done on them (not sure exactly why only some
of them just now):
{{{
$ port contents libgcc7 | grep dylib | xargs file
/opt/local/lib/libgcc/libatomic.1.dylib: Mach-O dynamically linked
shared library i386
/opt/local/lib/libgcc/libcilkrts.5.dylib: Mach-O dynamically linked
shared library i386
/opt/local/lib/libgcc/libgcc_ext.10.4.dylib: Mach-O universal binary with
1 architecture
/opt/local/lib/libgcc/libgcc_ext.10.4.dylib (for architecture i386):
Mach-O dynamically linked shared library stub i386
/opt/local/lib/libgcc/libgcc_ext.10.5.dylib: Mach-O universal binary with
1 architecture
/opt/local/lib/libgcc/libgcc_ext.10.5.dylib (for architecture i386):
Mach-O dynamically linked shared library stub i386
/opt/local/lib/libgcc/libgcc_s.1.dylib: Mach-O universal binary with
1 architecture
/opt/local/lib/libgcc/libgcc_s.1.dylib (for architecture i386): Mach-O
dynamically linked shared library i386
/opt/local/lib/libgcc/libgfortran.4.dylib: Mach-O dynamically linked
shared library i386
/opt/local/lib/libgcc/libgomp.1.dylib: Mach-O dynamically linked
shared library i386
/opt/local/lib/libgcc/libitm.1.dylib: Mach-O dynamically linked
shared library i386
/opt/local/lib/libgcc/libobjc-gnu.4.dylib: Mach-O dynamically linked
shared library i386
/opt/local/lib/libgcc/libquadmath.0.dylib: Mach-O dynamically linked
shared library i386
/opt/local/lib/libgcc/libssp.0.dylib: Mach-O dynamically linked
shared library i386
/opt/local/lib/libgcc/libstdc++.6.dylib: Mach-O dynamically linked
shared library i386
/opt/local/lib/libstdc++.6.dylib: symbolic link to
`libgcc/libstdc++.6.dylib'
}}}
It should be possible to just pull the i386 arch out of those fat files
(with only 1 arch in them) and replace them with the raw dylibs.
--
Ticket URL: <https://trac.macports.org/ticket/63164#comment:29>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list