[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