[MacPorts] #63164: py-libxml2 icu cctools - FAT libraries built on i386 Mac OS X Tiger fail to run

[MacPorts]

#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):

 This morning I did pull the i386 archs out of the fat libraries using the
 lipo command:
 {{{
 mkdir ~/gcctest
 cd ~/gcctest
 /usr/bin/lipo -thin i386 -o libgcc_s.1.dylib
 /opt/local/lib/libgcc/libgcc_s.1.dylib
 /usr/bin/lipo -thin i386 -o libgcc_ext.10.4.dylib
 /opt/local/lib/libgcc/libgcc_ext.10.4.dylib
 /usr/bin/lipo -thin i386 -o libgcc_ext.10.5.dylib
 /opt/local/lib/libgcc/libgcc_ext.10.5.dylib

 cd /opt/local/lib/libgcc
 sudo mv libgcc_ext.10.4.dylib libgcc_ext.10.4.dylib.disabled
 sudo mv libgcc_ext.10.5.dylib libgcc_ext.10.5.dylib.disabled
 sudo mv libgcc_s.1.dylib libgcc_s.1.dylib.disabled

 sudo mv ~/gcctest/*.dylib ./
 }}}

 and now none of the libraries are fat universal libs with one arch any
 longer:
 {{{
 $ ls /opt/local/lib/libgcc/*.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 dynamically linked
 shared library stub i386
 /opt/local/lib/libgcc/libgcc_ext.10.5.dylib: Mach-O dynamically linked
 shared library stub i386
 /opt/local/lib/libgcc/libgcc_s.1.dylib:      Mach-O dynamically linked
 shared library i386
 /opt/local/lib/libgcc/libgfortran.3.dylib:   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
 }}}

 and you are 100% right, after that the symbols were found, and the link
 worked:
 {{{
 gcc-mp-7 -dynamiclib -o test.dylib test.c
 gcc-mp-7 -c main.c
 gcc-mp-7 -o kentest test.dylib main.o
 }}}
 the program ran without errors about not finding the needed symbols, but
 then segfaulted, for reasons I need to sort out.
 {{{
 $ ./kentest
 marshmellows
 starting proggy
 Segmentation fault

 }}}


 So yes, the FAT libraries made with the confirmed faulty lipo in the
 current cctools port (apparently due, at least in part, to some weird
 error where log2(x) cannot be cast to a uint32_t, to be further sorted) do
 not appear to work properly.

 I'm not sure why the segfault just yet.

 Great work -- took some convincing, but you were right about the offset
 all along.

 We'll come up with some kind of plan for this. Probably involving rolling
 back cctools on Tiger at least to 921. That is probably for the best
 anyway, in the end.

-- 
Ticket URL: <https://trac.macports.org/ticket/63164#comment:30>
MacPorts <https://www.macports.org/>
Ports system for macOS