#63164 closed defect (fixed)
cctools @949: lipo make FAT libraries on i386 Mac OS X Tiger with wrong offset: fail to load
| Reported by: | bradleyCPA (B. Holder) | Owned by: | kencu (Ken) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | Cc: | ryandesign (Ryan Carsten Schmidt), jmroot (Joshua Root) | |
| Port: | cctools libgcc7 |
Description
Relevant mailing list correspondence: https://lists.macports.org/pipermail/macports-users/2021-June/050134.html
Relevant error for my particular case would be:
barf@tiger:~/Documents$ ktrace python3
Python 3.9.5 (default, Jun 13 2021, 23:36:56)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16+boot on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import libxml2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/libxml2.py", line 1, in <module>
import libxml2mod
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/libxml2mod.cpython-39-darwin.so, 2): Symbol not found: ___divmoddi4
Referenced from: /opt/local/lib/libicui18n.67.dylib
Expected in: /usr/lib/libgcc_s.1.dylib
>>> ^D
Relevant ktrace snippet is:
18814 Python CALL open(0x3cb3758,0,0)
18814 Python NAMI "/opt/local/lib/libgcc/libgcc_s.1.dylib"
18814 Python RET open 4
18814 Python CALL fstat(0x4,0xbfffb408)
18814 Python RET fstat 0
18814 Python CALL pread(0x4,0xbfffa008,0x1000,0)
18814 Python GIO fd 4 read 4096 bytes
"\M-J\M-~\M-:\M->\0\0\0\^A\0\0\0\a\0\0\0\^C\0\0\b\0\0\^A\M^E\M-x\0\0\0\v\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\M-N\M-z\M-m\M-~\a\0\0\0\^C\0\0\0\^F\0\0\0 \0\0\0\^D\^E\0\0\M^E\0\^P\0\^A\0\0\0\M-P\^A\0\0__TEXT\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0P\^A\0\0\0\0\0\0P\^A\0\a\0\0\0\^E\0\0\0\^F\0\0\0\0\0\0\0__text\0\0\0\0\0\0\0\0\0\0__TEXT\0\0\0\0\0\0\0\0\0\0P\^F\0\0\
\M-E+\^A\0P\^F\0\0\^D\0\0\0\0\0\0\0\0\0\0\0\0\^D\0\M^@\0\0\0\0\0\0\0\0__const\0\0\0\0\0\0\0\0\0__TEXT\0\0\0\0\0\0\0\0\0\0 2\^A\0\f\^C\
\0\0 2\^A\0\^E\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0__text_startup\0\0__TEXT\0\0\0\0\0\0\0\0\0\00005\^A\09\a\0\00005\^A\0\^D\
\0\0\0\0\0\0\0\0\0\0\0\0\^D\0\M^@\0\0\0\0\0\0\0\0__cstring\0\0\0\0\0\0\0__TEXT\0\0\0\0\0\0\0\0\0\0i<\^A\0\^R\0\0\0i<\^A\0\0\0\0\0\0\0\
\0\0\0\0\0\0\^B\0\0\0\0\0\0\0\0\0\0\0__unwind_info\0\0\0__TEXT\0\0\0\0\0\0\0\0\0\0\M^@<\^A\0\^T\^A\0\0\M^@<\^A\0\^D\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0__eh_frame\0\0\0\0\0\0__TEXT\0\0\0\0\0\0\0\0\0\0\M^T=\^A\0T\^R\0\0\M^T=\^A\0\^B\0\0\0\0\0\0\0\0\0\0\0\v\0\
\0`\0\0\0\0\0\0\0\0\^A\0\0\0\M^L\^A\0\0__DATA\0\0\0\0\0\0\0\0\0\0\0P\^A\0\0\^P\0\0\0P\^A\0\0\^P\0\0\a\0\0\0\^C\0\0\0\^E\0\0\0\0\0\0\0\
__dyld\0\0\0\0\0\0\0\0\0\0__DATA\0\0\0\0\0\0\0\0\0\0\0P\^A\0\b\0\0\0\0P\^A\0\^B\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0__mod_in\
it_func\0__DATA\0\0\0\0\0\0\0\0\0\0\bP\^A\0\^D\0\0\0\bP\^A\0\^B\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0\0__data\0\0\0\0\0\0\0\0\
\0\0__DATA\0\0\0\0\0\0\0\0\0\0 P\^A\0l\0\0\0 P\^A\0\^E\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0__pu_bss2\0\0\0\0\0\0\0__DATA\0\0\
\0\0\0\0\0\0\0\0\M^LP\^A\0\^P\0\0\0\0\0\0\0\^B\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0__bss2\0\0\0\0\0\0\0\0\0\0__DATA\0\0\0\0\
\0\0\0\0\0\0\M^\P\^A\08\0\0\0\0\0\0\0\^B\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0|\0\0\0__IMPORT\0\0\0\0\0\0\0\0\0`\^A\
\0\0\^P\0\0\0`\^A\0\0\^P\0\0\a\0\0\0\a\0\0\0\^A\0\0\0\0\0\0\0__jump_table\0\0\0\0__IMPORT\0\0\0\0\0\0\0\0\0`\^A\0i\0\0\0\0`\^A\0\^F\0\
\0\0\0\0\0\0\0\0\0\0\b\0\0\^D\0\0\0\0\^E\0\0\0\^A\0\0\08\0\0\0__LINKEDIT\0\0\0\0\0\0\0p\^A\0\M-x\^U\0\0\0p\^A\0\M-x\^U\0\0\a\0\0\0\^A\
\0\0\0\0\0\0\0\0\0\0\0\r\0\0\0@\0\0\0\^X\0\0\0\^A\0\0\0\0\0\^A\0\0\0\^A\0/opt/local/lib/libgcc/libgcc_s.1.dylib\0\0\^[\0\0\0\^X\0\0\0\
\^?fS\M-@@\240E\M^Z\^Q\M-0@i\M-g\M^Y"
\^B\0\0\0\^X\0\0\0\^Pp\^A\0\M^P\0\0\0l}\^A\0\M^L\b\0\0\v\0\0\0P\0\0\0\0\0\0\0\^A\0\0\0\^A\0\0\0{\0\0\0|\0\0\0\^T\0\0\0$w\^A\0{\0\0\0\
\M-|z\^A\0\^A\0\0\0000{\^A\0\M^O\0\0\0\M-Pv\^A\0\^U\0\0\0\0\0\0\0\0\0\0\0\0p\^A\0\^B\0\0\0\f\0\0\0004\0\0\0\^X\0\0\0\^B\0\0\0\^C\^CX\
\0\0\0\^A\0/usr/lib/libSystem.B.dylib\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M^K<$\M-C\
\M-h\0\0\0\0X\M^?\M-0\M-GI\^A\0\M^K\M^@\M-'I\^A\0\M^?\M-`\M-h\0\0\0\0X\M^K\M^@\M^WI\^A\0\M^?\M-`\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\
\M^PS\M^KL$\b\M^K\\$\^P\M^I\M-H\^O\M-/L$\^T\M-w\M-c\^O\M-/\\$\f\^A\M-J\^A\M-Z[\M-C\M^P\M^P\M^P\M^KL$\^D\M^KT$\b\M^I\M-H\M-w\M-X\M-w\
\M-Z\M^E\M-I\^O\M^U\M-A\^O\M-6\M-I)\M-J\M-C\M^P\M^P\M^P\M^P\M^P\M^P\M^PVS\M^K\\$\^P\M^KL$\^T\M^KD$\f\M^I\M-Z\M^E\M-It\^U\M-> \0\0\0)\
\M-N\M^E\M-v~\^Q\M-S\M-h\M-S\M-j\M^I\M-q\M-S\M-c \M-X[^\M-C\^O\^_@\0\M-w\M-^\M^I\M-X1\M-R[\M^I\M-q^\M-S\M-h\M-C\M^P\M^P\M^PVS\
\M^Kt$\f\M^KL$\^T\M^KT$\^P\M^I\M-p\M^E\M-It\^U\M-; \0\0\0)\M-K\M^E\M-[~\^Q\M-S\M-b\M-S\M-`\M^I\M-Y\M-S\M-n \M-r[^\M-C\^O\^_@\0\
\M-w\M-[1\M-@\M^I\M-Y[\M-S\M-f\M^I\M-r^\M-C\M^P\M^P\M^PVS\M^K\\$\^P\M^KL$\^T\M^KD$\f\M^I\M-Z\M^E\M-It\^U\M-> \0\0\0)\M-N\M^E\M-v~\^Q\
\M-S\M-h\M-S\M-z\M^I\M-q\M-S\M-c \M-X[^\M-C\^O\^_@\0\M-w\M-^\M^I\M-X\M-A\M-z\^_[\M^I\M-q^\M-S\M-x\M-C\M^P\M^PS1\M-@\M^K\\$\^T9\
\\$\f\M^KL$\b\M^KT$\^P|\^V\M-8\^B\0\0\0\^?\^O1\M-@9\M-Qr \^O\M^W\M-@\^O\M-6\M-@\M^C\M-@\^A[\M-C\M^P\M^P\M^PS1\M-@\M^KL$\b\M^KT\
$\^P\M^K\\$\^T9\\$\fr\^V\M-8\^B\0\0\0w\^O1\M-@9\M-Qr \^O\M^W\M-@\^O\M-6\M-@\M^C\M-@\^A[\M-C\M^P\M^P\M^P\M-C\M^P\M^P\M^P\M^P\M^P\
\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M-C\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P"
18814 Python RET pread 4096/0x1000
18814 Python CALL pread(0x4,0xbfffa008,0x1000,0x800)
18814 Python GIO fd 4 read 4096 bytes
"\M-N\M-z\M-m\M-~\a\0\0\0\^C\0\0\0\^F\0\0\0 \0\0\0\^D\^E\0\0\M^E\0\^P\0\^A\0\0\0\M-P\^A\0\0__TEXT\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0P\
\^A\0\0\0\0\0\0P\^A\0\a\0\0\0\^E\0\0\0\^F\0\0\0\0\0\0\0__text\0\0\0\0\0\0\0\0\0\0__TEXT\0\0\0\0\0\0\0\0\0\0P\^F\0\0\M-E+\^A\0P\^F\0\0\
\^D\0\0\0\0\0\0\0\0\0\0\0\0\^D\0\M^@\0\0\0\0\0\0\0\0__const\0\0\0\0\0\0\0\0\0__TEXT\0\0\0\0\0\0\0\0\0\0 2\^A\0\f\^C\0\0 2\^A\0\^E\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0__text_startup\0\0__TEXT\0\0\0\0\0\0\0\0\0\00005\^A\09\a\0\00005\^A\0\^D\0\0\0\0\0\0\0\0\0\
\0\0\0\^D\0\M^@\0\0\0\0\0\0\0\0__cstring\0\0\0\0\0\0\0__TEXT\0\0\0\0\0\0\0\0\0\0i<\^A\0\^R\0\0\0i<\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\^B\0\
\0\0\0\0\0\0\0\0\0\0__unwind_info\0\0\0__TEXT\0\0\0\0\0\0\0\0\0\0\M^@<\^A\0\^T\^A\0\0\M^@<\^A\0\^D\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0__eh_frame\0\0\0\0\0\0__TEXT\0\0\0\0\0\0\0\0\0\0\M^T=\^A\0T\^R\0\0\M^T=\^A\0\^B\0\0\0\0\0\0\0\0\0\0\0\v\0\0`\0\0\0\0\0\0\
\0\0\^A\0\0\0\M^L\^A\0\0__DATA\0\0\0\0\0\0\0\0\0\0\0P\^A\0\0\^P\0\0\0P\^A\0\0\^P\0\0\a\0\0\0\^C\0\0\0\^E\0\0\0\0\0\0\0__dyld\0\0\0\0\
\0\0\0\0\0\0__DATA\0\0\0\0\0\0\0\0\0\0\0P\^A\0\b\0\0\0\0P\^A\0\^B\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0__mod_init_func\0__DAT\
A\0\0\0\0\0\0\0\0\0\0\bP\^A\0\^D\0\0\0\bP\^A\0\^B\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0\0__data\0\0\0\0\0\0\0\0\0\0__DATA\0\0\0\
\0\0\0\0\0\0\0 P\^A\0l\0\0\0 P\^A\0\^E\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0__pu_bss2\0\0\0\0\0\0\0__DATA\0\0\0\0\0\0\0\0\0\0\
\M^LP\^A\0\^P\0\0\0\0\0\0\0\^B\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0__bss2\0\0\0\0\0\0\0\0\0\0__DATA\0\0\0\0\0\0\0\0\0\0\M^\\
P\^A\08\0\0\0\0\0\0\0\^B\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0|\0\0\0__IMPORT\0\0\0\0\0\0\0\0\0`\^A\0\0\^P\0\0\0`\
\^A\0\0\^P\0\0\a\0\0\0\a\0\0\0\^A\0\0\0\0\0\0\0__jump_table\0\0\0\0__IMPORT\0\0\0\0\0\0\0\0\0`\^A\0i\0\0\0\0`\^A\0\^F\0\0\0\0\0\0\0\0\
\0\0\0\b\0\0\^D\0\0\0\0\^E\0\0\0\^A\0\0\08\0\0\0__LINKEDIT\0\0\0\0\0\0\0p\^A\0\M-x\^U\0\0\0p\^A\0\M-x\^U\0\0\a\0\0\0\^A\0\0\0\0\0\0\0\
\0\0\0\0\r\0\0\0@\0\0\0\^X\0\0\0\^A\0\0\0\0\0\^A\0\0\0\^A\0/opt/local/lib/libgcc/libgcc_s.1.dylib\0\0\^[\0\0\0\^X\0\0\0\^?fS\M-@@\240\
E\M^Z\^Q\M-0@i\M-g\M^Y"
\^B\0\0\0\^X\0\0\0\^Pp\^A\0\M^P\0\0\0l}\^A\0\M^L\b\0\0\v\0\0\0P\0\0\0\0\0\0\0\^A\0\0\0\^A\0\0\0{\0\0\0|\0\0\0\^T\0\0\0$w\^A\0{\0\0\0\
\M-|z\^A\0\^A\0\0\0000{\^A\0\M^O\0\0\0\M-Pv\^A\0\^U\0\0\0\0\0\0\0\0\0\0\0\0p\^A\0\^B\0\0\0\f\0\0\0004\0\0\0\^X\0\0\0\^B\0\0\0\^C\^CX\
\0\0\0\^A\0/usr/lib/libSystem.B.dylib\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M^K<$\M-C\
\M-h\0\0\0\0X\M^?\M-0\M-GI\^A\0\M^K\M^@\M-'I\^A\0\M^?\M-`\M-h\0\0\0\0X\M^K\M^@\M^WI\^A\0\M^?\M-`\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\
\M^PS\M^KL$\b\M^K\\$\^P\M^I\M-H\^O\M-/L$\^T\M-w\M-c\^O\M-/\\$\f\^A\M-J\^A\M-Z[\M-C\M^P\M^P\M^P\M^KL$\^D\M^KT$\b\M^I\M-H\M-w\M-X\M-w\
\M-Z\M^E\M-I\^O\M^U\M-A\^O\M-6\M-I)\M-J\M-C\M^P\M^P\M^P\M^P\M^P\M^P\M^PVS\M^K\\$\^P\M^KL$\^T\M^KD$\f\M^I\M-Z\M^E\M-It\^U\M-> \0\0\0)\
\M-N\M^E\M-v~\^Q\M-S\M-h\M-S\M-j\M^I\M-q\M-S\M-c \M-X[^\M-C\^O\^_@\0\M-w\M-^\M^I\M-X1\M-R[\M^I\M-q^\M-S\M-h\M-C\M^P\M^P\M^PVS\
\M^Kt$\f\M^KL$\^T\M^KT$\^P\M^I\M-p\M^E\M-It\^U\M-; \0\0\0)\M-K\M^E\M-[~\^Q\M-S\M-b\M-S\M-`\M^I\M-Y\M-S\M-n \M-r[^\M-C\^O\^_@\0\
\M-w\M-[1\M-@\M^I\M-Y[\M-S\M-f\M^I\M-r^\M-C\M^P\M^P\M^PVS\M^K\\$\^P\M^KL$\^T\M^KD$\f\M^I\M-Z\M^E\M-It\^U\M-> \0\0\0)\M-N\M^E\M-v~\^Q\
\M-S\M-h\M-S\M-z\M^I\M-q\M-S\M-c \M-X[^\M-C\^O\^_@\0\M-w\M-^\M^I\M-X\M-A\M-z\^_[\M^I\M-q^\M-S\M-x\M-C\M^P\M^PS1\M-@\M^K\\$\^T9\
\\$\f\M^KL$\b\M^KT$\^P|\^V\M-8\^B\0\0\0\^?\^O1\M-@9\M-Qr \^O\M^W\M-@\^O\M-6\M-@\M^C\M-@\^A[\M-C\M^P\M^P\M^PS1\M-@\M^KL$\b\M^KT\
$\^P\M^K\\$\^T9\\$\fr\^V\M-8\^B\0\0\0w\^O1\M-@9\M-Qr \^O\M^W\M-@\^O\M-6\M-@\M^C\M-@\^A[\M-C\M^P\M^P\M^P\M-C\M^P\M^P\M^P\M^P\M^P\
\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M-C\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^C\M-l\f\M^KD$\^P\M^E\M-@x\
\^E\M^C\M-D\f\M-C\M^P\M-w\M-X\M^E\M-@y\M-u\M-h\M-tW\^A\0\M^P\M^P\M^P\M^P\M^P\M^C\M-l\f\M^KT$\^T\M^KD$\^P\M^E\M-Rx\^D\M^C\M-D\f\M-C\
\M-w\M-X\M^C\M-R\0\M-w\M-Z\M^E\M-Ry\M-q\M-h\M-LW\^A\0\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^C\M-l\f\M^KL$\^T\M^KT$\^P\
\M^E\M-I\M^M\^D
x\^N9\M-B\^O\M^_\M-B\M^D\M-Ru\f\M^C\M-D\f\M-C\M^P9\M-B\^O\M^\\M-B\M-k\M-p\M-h\M^SW\^A\0\M^P\M^P\M^P\M^PS\M^C\M-l\b\M^KL$\^P\M^K\\$\^T\
\M^I\M-H\^CD$\^X\M^I\M-Z\^ST$\^\\M^C|$\^\\0x\^Q9\M-S\^?\^F|\^U9\M-Av\^Q\M-haW\^A\0f\M^P9\M-S|\M-u\^?\^D9\M-Ar\M-o\M^C\M-D\b[\M-C\M^P\
\M^C\M-l\f\M^KT$\^P\M^KL$\^T\M^I\M-P)\M-H\M^E\M-Ix\r9\M-B\^O\M^\\M-B\M^D\M-Ru\v\M^C\M-D\f\M-C9\M-B\^O\M^_\M-B\M-k\M-q\M-h#W\^A\0\M^P\
\M^P\M^P\M^PWVS\M^KL$\^P\M^K\\$\^T\M^Kt$\^X\M^K|$\^\\M^I\M-H\M^I\M-Z)\M-p\^Y\M-z\M^E\M^?x\^Q9\M-S|\^F\^?\^U9\M-As\^Q\M-h\M-qV\^A\0f\
\M^P9\M-S\^?\M-u|\^D9\M-Aw\M-o[^_\M-C\M^P\M^PS\M^C\M-l\b\M^KD$\^T\M-wl$\^P\M^I\M-A\M-A\M-y\^_9\M-Qu\^E\M^C\M-D\b[\M-C\M-h\M-@V\^A\0\
\M^PUWVS\M^C\M-l,\M^KD$H\M^KT$L\M^K|$@\M^Kl$D\M^ID$\b\M^I\M-C\M^IT$\f\M^I\M-B\M-A\M-z\^_\M^I\M-y\M^I\M-P\M^KT$\f\M^IT$\^P\M^I\M-z\M-A\
\M-z\^_9\M-ju\^U;D$\^Pu`\M^I\M-x\M-w\M-k\M^C\M-D,[^_]\M-C\^O\^_\0\M^I\M-n;D$\^P\^O\M^E\M-9\0\0\0\M^KD$\b\M-w\M-g\M^ID$\^P\M^ID$\^X\
\M^KD$\b\M^IT$\^T\M-w\M-e\M^E\M-my\^F\M^I\M-V)\M-^\M^I\M-r\M^E\M-[y\^D)\M-x\^Y\M-j\M^KL$\^T1\M-[\^A\M-A\M^I\M-H\^Q\M-S\M-A\M-x\^_9\
\M-Xuw\M^KD$\^X\M^I\M-J\M-k\M-$\M^KD$\b\M-w\M-g\M^ID$\^X\M^I\M-F\M^I\M-x\M^K|$\^P\M^IT$\^\\M-w\M-g\M^E\M^?y\^F\M^I\M-W)\M-O\M^I\M-z\
\M^E\M-Iy\b+D$\b\^[T$\f\M^KL$\^\1\M-[\^A\M-A\M^I\M-H\^Q\M-S\M-A\M-x\^_9\M-Xu.\M^I\M-p\M^I\M-J\M-iZ\M^?\M^?\M^?\M^KD$\^P\M^E\M-@x_u\^[\
\M^C\M-}\M^?u\^V\M^KD$\b\M-w\M-g\M^I\M-Q\M^I\M-F)\M-Yx\M-Z\^O\^_\M^D\0\0\0\0\0\M-h\M-*U\^A\0\M^E\M-mx\M-R\M^KD$\^P\M^E\M-@x\^T \M-hu\
\M-k\M^KD$\b\M-w\M-g\M^E\M-R\^O\M^I\^R\M^?\M^?\M^?\M-k\M-[\M^C|$\^P\M^?u\M-T\M^E\M-mu\M-P\M^KD$\b\M-w\M-g\M^I\M-F\M^I\M-P)\M-H\M^I\
\M-Ax\M^R\M-k\M->#t$\^P\M^C\M-~\M^?u\M-5\M^I\M-X \M-xt\M-/\M^KD$\b\M-w\M-g\M^I\M-F\M^I\M-P)\M-H)\M-X\M^I\M-A\^O\M^Ik\M^?\M^?\
\M^?\M-k\M^W\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^C\M-l\f\M^KT$\^P\M^I\M-P\M-w\M-X\M^I\M-A\M-A\M-i\^_\M^E\M-Rx\^E\M^E\M-@\^O\M^_\M-A\M^D\M-I\
u\^D\M^C\M-D\f\M-C\M-h\^YU\^A\0\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^PS\M^C\M-l\b\M^KL$\^P\M^K\\$\^T\M^I\M-H\M-w\M-X\M^I\M-Z\M^C\M-R\
\0\M-w\M-Z\M^E\M-[x\^Y\M^I\M-S\M-A\M-{\^_\M^I\M-Y)\M-A\^Y\M-S\M-A\M-k\^_\M^I\M-Y\M^D\M-Iu\^N\M^C\M-D\b[\M-C\M^I\M-S\M-A\M-k\^_\M^I\
\M-Y\M-k\M-n\M-h\M-MT\^A\0\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^KT$\^D\^O\M-<\M-B\M^C\M-@\^A\M^E\M-R\M-:\0\0\0\0\
\^OD\M-B\M-C\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^KD$\^D\M^KT$\b\M^E\M-@t\^T\M-:\^A\0\0\0\^O\M-<\M-@\^A\M-P\M-Cf\^O\^_\M^D\0\
\0\0\0\0001\M-@\M^E\M-Rt\M-p\M^I\M-P\M-:!\0\0\0\M-k\M-b\M^P\^O\M-=D$\^D\M^C\M-p\^_\M-C\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^KT$\b\M^KD$\^D\
\M^E\M-Ru\^T\^O\M-=\M-@\M-: \0\0\0\M^C\M-p\^_\^A\M-P\M-Cf\^O\^_D\0\0\M^I\M-P1\M-R\^O\M-=\M-@\M^C\M-p\^_\^A\M-P\M-C\M^P\M^P\M^P\^O\M-<\
D$\^D\M-C\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^KT$\^D\M^KD$\b\M^E\M-Ru\^T\M-: \0\0\0\^O\M-<\M-@\^A\M-P\M-Cf\^O\^_\M^D\0\0\0\0\0\
\M^I\M-P1\M-R\^O\M-<\M-@\^A\M-P\M-C\M^P\M^P\M^P\M^P\M^P\M^P\M^KT$\^D\M^I\M-P\M-Q\M-h%UUUU)\M-B\M^I\M-P\M-A\M-j\^B%3333\M^A\M-b3333\^A\
\M-B\M^I\M-P\M-A\M-h\^D\^A\M-P%\^O\^O\^O\^Oi\M-@\^A\^A\^A\^A\M-A\M-h\^X\M-C\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^PS\M^KL$\b\M^KT$\f\M^I\
\M-H\M-Q\M-h%UUUU)\M-A\M^I\M-P\M-Q\M-h%UUUU)\M-B\M^I\M-H\M-A\M-i\^B%3333\M^A\M-a3333\M^M\^\\b\M^I\M-P\M-A\M-j\^B\M^I\M-Y%3333\M^A\M-b\
3333\M-A\M-i\^D\^A\M-B\M^M\^D\^Y[%\^O\^O\^O\^O\M^I\M-A\M^I\M-P\M-A\M-h\^D\^A\M-P%\^O\^O\^O\^O\^A\M-Hi\M-@\^A\^A\^A\^A\M-A\M-h\^X\M-C\
\M^P\M^P\M^P\M^P\M^KL$\^D\M^I\M-H\M-A\M-h\^P1\M-H\M^I\M-A\M-A\M-i\b1\M-H\M^I\M-A\M-A\M-i\^D1\M-A\M-8\M^Vi\0\0\M^C\M-a\^O\M-S\M-x\M^C\
\M-`\^A\M-C\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^KD$\b3D$\^D\M^I\M-A\M-A\M-h\^P1\M-H\M^I\M-A\M-A\M-i\b1\M-H\M^I\M-A\M-A\M-i\^D1\M-A\
\M-8\M^Vi\0\0\M^C\M-a\^O\M-S\M-x\M^C\M-`\^A\M-C\M^P\M^P\M^P\M^P\M^PS\M^KT$\f\M-hN\0\0\0\M-YD$\b\M-Y\M-h\M^I\M-Q\M-A\M-y\^_\M^I\M-H1\
\M-P)\M-H\M-(\^A\M-[\M-I\M-k\^B\M-Y\M-I\M-Q\M-ht\^Y\M-Y\M-I\M-X\M-H\M-(\^At\M-r\M-Q\M-h\M-\\M-Iu\M-t\M-]\M-X\M-k \^O\^_\M^@\0\
\0\0\0\M-]\M-Y\M^E\M-Rx
[\M-C\^O\^_\M^D\0\0\0\0\0\M-X\M-;\M-f&\^A\0[\M-C\M^K\^\$\M-C\M^P\M^P\M^P\M^PS\M^KT$\^P\M-h\M-n\M^?\M^?\M^?\M-]D$\b\M-Y\M-@\M^I\M-Q\
\M-A\M-y\^_\M^I\M-H1\M-P)\M-H\M-(\^Au\b\M-]\M-X\M-Y\M-h\M-k\^B\M-Y\M-I\M-Q\M-ht\^U\M-Y\M-I\M-X\M-H\M-(\^At\M-r\M-Q\M-h\M-\\M-Iu\M-t\
\M-]\M-X\M-k\^E\^O\^_\0\M-]\M-Y\M^E\M-Rx
[\M-C\^O\^_\M^D\0\0\0\0\0\M-X\M-;\M^J&\^A\0[\M-C\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^PS\M^KT$\^X\M-[l$\b\M-h\M^J\M^?\M^?\M^?\M-Y\M-@\M^I\
\M-Q\M-A\M-y\^_\M^I\M-H1\M-P)\M-H\M-(\^Au\b\M-]\M-X\M-Y\M-h\M-k\^B\M-Y\M-I\M-Q\M-ht\^U\M-Y\M-I\M-X\M-H\M-(\^At\M-r\M-Q\M-h\M-\\M-Iu\
\M-t\M-]\M-X\M-k\^E\^O\^_\0\M-]\M-Y\M^E\M-Rx
[\M-C\^O\^_\M^D\0\0\0\0\0\M-X\M-;*&\^A\0[\M-C\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M^PU\M-h\M-_\0\0\0WVS\M^C\M-l<\M^Kt$pf\^OoD$`\^O)\^D$\M^I\
\M-r\M-A\M-z\^_\M^I\M-W1\M-w)\M-W\M-w\M-G\^A\0\0\0u\ff\^Oo\M-%\M-Z%\^A\0\^O)$$\M^M\\$ \M-Q\M-otY\M^C\M-l,\^O\^QD$\^\\^O\^QD$\fS\M-h\
\M-<~\0\0\M^C\M-D,f\^OoD$ \M-w\M-G\^A\0\0\0t\M-X\M^C\M-l,f\^OoL$,\^O\^QD$\^\\^O)D$<\^O\^QL$\fS\M-h\M^M~\0\0\M^C\M-D,f\^OoT$ \M-Q\M-of\
\^OoD$\^P\^O)\^T$u\M-'\M^E\M-vy1f\^Oo,$\M^MD$ \M^C\M-l,f\^Oo\M-5\M-Z%\^A\0\^O\^Ql$\^\\^O\^Qt$\fP\M-h\M-~a\0\0\M^C\M-D,f\^Oo|$ \^O)<$\
\M^KD$Pf\^Oo\^\$\^O)\^X\M^C\M-D<[^_]\M-B\^D\0\M^K,$\M-C\M^P\M^P\M^P\M^P\M^P\M^P\M^P\M-h\M^?\^C\0\0S\M^C\M-l \M-YD$(\M-YD$,\M-YD$0\M-Y\
D$4\M-Y\M-C\M-X\M-J\M-Y\\$\^P\M-Y\M-B\M-X\M-I\M-Y\\$\^T\M-Y\M-C\M-X\M-I\M-Y\\$\^X\M-Y\M-A\M-X\M-K\M-Y\\$\^\\M-YD$\^P\M-YD$\^T\M-Y\^T$\
\M-Y\M-A\M-^\M-a\M-YD$\^X\M-YT$\^D\M-YD$\^\\M-YT$\b\M-^\M-A\M-[\M-h\M-Y\M-I\^O\M^Z\M-B\M-[\M-h\^O\M^Z\M-@ \M-Bu1\M-]\M-]\M-]\M-]\M-]\
\M-X\M-]\M-X\M-]\M-X\M-k\^T\M-]\M-X\M-]\M-]\M-]\M-X\M-]\M-X\M-]\M-X\M-k\b\M-]\M-]\M-]\M-X\M-]\M-X\M-]\M-X\M-Y\^\$\M^K\^D$\M-Y\^\$\M^K\
\^T$\M^C\M-D [\M-C\M-Y\M-F\M-X\M-g\M-Y\\$\f\M-Y\M-M\M-[\M-h\M-Y\M-@\^O\M^[\M-C\M-X\M-a\M-_\M-h\M-Y\M-N\^O\M^Z\M-@!\M-C\M-[\M-hz\f\M-Y\
D$\f\M-_"
18814 Python RET pread 4096/0x1000
18814 Python CALL mmap(0x17c3000,0x15000,0x5,0x12,0x4,0x800)
18814 Python RET mmap -1 errno 22 Invalid argument
18814 Python CALL close(0x4)
18814 Python RET close 0
Example program that reproduces the issue outside of this particular instance is attached. It appears that for whatever reason Mac OS Tiger lipo produces FAT libraries that will load but the lipo provided by cctools port produces FAT libraries that will not load.
sw_vers:
barf@tiger:~/Documents/lipo_work/python_library_test/boom$ sw_vers ProductName: Mac OS X Server ProductVersion: 10.4.11 BuildVersion: 8S2169
port version:
barf@tiger:~/Documents/lipo_work/python_library_test/boom$ port version Version: 2.7.1
Attachments (1)
Change History (45)
Changed 3 years ago by bradleyCPA (B. Holder)
| Attachment: | lipo_tiger_example_failure.zip added |
|---|
comment:1 Changed 3 years ago by kencu (Ken)
It is certainly possible that there could be a bug found in the current cctools lipo command when running on Tiger.
I worked my way through as much of the Tiger fixes as I could when I updated cctools some months ago (the i386 assembler was quite broken, for example, and I patched that back to a working condition) -- but I did not extensively test lipo...
comment:2 Changed 3 years ago by kencu (Ken)
By the way, for a rather good description of libgcc.s.1.dylib etc with respect to newer open-source gcc versions, you can see this commit message and details:
https://github.com/iains/gcc-10-branch/commit/e06d4dd911d3937e869bd4d4b5c0ca1680cc56f6
comment:3 Changed 3 years ago by kencu (Ken)
I don't actually see where a fat library is breaking something here at the moment, that is fixed by using some other lipo...I'll look at your example file you uploaded.
In Iain's commit message he points out that gcc's newer libgcc.s.1.dylib trickery relies on the two-level namespace being active, and that can be disabled, potentially breaking the symbol finding, by setting a flat namespace during linking I suppose, or by using DYLD_LIBRARY_PATH.
Also the python 3.9 C bindings caused some troubles to build on Tiger. Do you see issues with python 3.7 as well?
comment:4 Changed 3 years ago by kencu (Ken)
On my Tiger Intel system, where nothing is built FAT (because none of the c++11 compilers available on Tiger are capable of building FAT binaries that are i386/ppc code):
$ python3.9 Python 3.9.5 (default, May 23 2021, 14:27:46) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import libxml2 >>>
comment:5 Changed 3 years ago by bradleyCPA (B. Holder)
Consider:
#include <math.h>
#include <stdio.h>
int main() {
unsigned int pagesize = 4096;
fprintf(stdout, "%u %f %u %u\n", pagesize, log2(pagesize), (unsigned int) log2(pagesize), lround(log2(pagesize)));
}
which on my mac os x tiger system gives:
4096 12.000000 11 12
as it pertains to the get_default_align() function misc/lipo.c in cctools archive
/*
* get_default_align() returns the default segment alignment for the specified
* cputype and cpusubtype, as an exponent of a power of 2; e.g., a segment
* alignment of 0x4000 will be described as 14. If the default alignment is not
* known it will return 0.
*/
static
uint32_t
get_default_align(
cpu_type_t cputype,
cpu_subtype_t cpusubtype)
{
const char* arch_name = get_arch_name_from_types(cputype, cpusubtype);
if (arch_name != NULL) {
struct arch_flag arch_flag;
if (get_arch_from_flag((char*)arch_name, &arch_flag)) {
uint32_t pagesize = get_segalign_from_flag(&arch_flag);
return (uint32_t)(log2(pagesize));
}
}
return 0;
}
This explains to me why the alignment is being chosen as 2048. Seems bug.
comment:6 Changed 3 years ago by kencu (Ken)
I am not following you. Can you explain more clearly why you feel there is a bug?
comment:7 Changed 3 years ago by bradleyCPA (B. Holder)
The default alignment should be 12 (2^12 is 4096) not 11 (2^11 is 2048). This is why artifacts on my system such as:
otool -f /opt/local/lib/libgcc/libgcc_s.1.dylib
Fat headers
fat_magic 0xcafebabe
nfat_arch 1
architecture 0
cputype 7
cpusubtype 3
capabilities 0x0
offset 2048
size 99832
align 2^11 (2048)
are aligned as they are. Fat libraries aligned at 2048 do not load properly in tests on my system.
comment:8 Changed 3 years ago by kencu (Ken)
I get the same:
$ otool -f /opt/local/lib/libgcc/libgcc_s.1.dylib
Fat headers
fat_magic 0xcafebabe
nfat_arch 1
architecture 0
cputype 7
cpusubtype 3
capabilities 0x0
offset 2048
size 103928
align 2^11 (2048)
although the library is not actually FAT, as there is only one architecture.
$ file /opt/local/lib/libgcc/libgcc_s.1.dylib /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
It works fine, I have no errors:
$ /opt/local/bin/python3.9 Python 3.9.5 (default, May 23 2021, 14:27:46) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import libxml2
comment:9 follow-up: 24 Changed 3 years ago by kencu (Ken)
I can see you have an error when you import that libxml2 python library when you are using python3.
I still do not have a ready explanation for you as to why you see that, but it works fine for me, and we have been using these things on MacPorts for many many years, so it is not likely that the error is in these tools. Not impossible, just extremely unlikely.
I understand you have been hacking into library headers with hexedit, etc. I have no idea where you are just now with regards to a virgin build of things, to be honest.
If you want to start clean, we can probably get you going.
comment:10 Changed 3 years ago by bradleyCPA (B. Holder)
On a proper system, the output of my test program
#include <math.h>
#include <stdio.h>
int main() {
unsigned int pagesize = 4096;
fprintf(stdout, "%u %f %u %u\n", pagesize, log2(pagesize), (unsigned int) log2(pagesize), lround(log2(pagesize)));
}
should be
~/Downloads/macports_cctools_test$ gcc -o test test.c ~/Downloads/macports_cctools_test$ ./test 4096 12.000000 12 12
However, it is not proper on tiger. The cast results in a value of 11 instead of 12. This is almost certainly a bug. Whether or not it is ultimately the cause of the behavior I am seeing is debatable, it seems.
comment:11 Changed 3 years ago by kencu (Ken)
Ok, I see some more details. It does look like that gcc library we installed has a different alignment that the one that comes with the system:
$ lipo -detailed_info /opt/local/lib/libgcc/libgcc_s.1.dylib
Fat header in: /opt/local/lib/libgcc/libgcc_s.1.dylib
fat_magic 0xcafebabe
nfat_arch 1
architecture i386
cputype CPU_TYPE_I386
cpusubtype CPU_SUBTYPE_I386_ALL
offset 2048
size 103928
align 2^11 (2048)
$ lipo -detailed_info /usr/lib/libgcc_s.1.dylib
Fat header in: /usr/lib/libgcc_s.1.dylib
fat_magic 0xcafebabe
nfat_arch 4
architecture i386
cputype CPU_TYPE_I386
cpusubtype CPU_SUBTYPE_I386_ALL
offset 4096
size 53648
align 2^12 (4096)
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
offset 61440
size 54268
align 2^12 (4096)
architecture ppc
cputype CPU_TYPE_POWERPC
cpusubtype CPU_SUBTYPE_POWERPC_ALL
offset 118784
size 66380
align 2^12 (4096)
architecture ppc64
cputype CPU_TYPE_POWERPC64
cpusubtype CPU_SUBTYPE_POWERPC_ALL
offset 188416
size 62904
align 2^12 (4096)
I am not at this moment thinking that is an error. I believe that is just the way it is built by gcc. But it is a question we can ask.
Before we get into why you think the build tools are broken, lets go back to your error, which I don't see. Perhaps that is a more useful place to start, as everything on my Tiger system works normally?
comment:12 Changed 3 years ago by bradleyCPA (B. Holder)
Is /opt/local/lib/libgcc/libgcc_s.1.dylib really being used on your system when testing? Ktrace on mine shows that the /opt/local/lib/libgcc/libgcc_s.1.dylib library fails to load in mmap as shown way up above. If the needed symbols are resolving elsewhere then that failure won't be fatal. You asked about different python versions, 2.7 and 3.8 also fail similarly:
barf@tiger:/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/icu$ python2.7
Python 2.7.18 (default, Jun 13 2021, 23:29:59)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16+boot on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> barf = ctypes.cdll.LoadLibrary("/opt/local/lib/libicui18n.67.1.dylib")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 444, in LoadLibrary
return self._dlltype(name)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 366, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlopen(/opt/local/lib/libicui18n.67.1.dylib, 6): Symbol not found: ___divmoddi4
Referenced from: /opt/local/lib/libicui18n.67.1.dylib
Expected in: /usr/lib/libgcc_s.1.dylib
>>> import libxml2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/libxml2.py", line 1, in <module>
import libxml2mod
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/libxml2mod.so, 2): Symbol not found: ___divmoddi4
Referenced from: /opt/local/lib/libicui18n.67.1.dylib
Expected in: /usr/lib/libgcc_s.1.dylib
>>> ^D
barf@tiger:/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/icu$ python3.8
Python 3.8.10 (default, Jun 16 2021, 06:34:01)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> barf = ctypes.cdll.LoadLibrary("/opt/local/lib/libicui18n.67.1.dylib")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/ctypes/__init__.py", line 451, in LoadLibrary
return self._dlltype(name)
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/ctypes/__init__.py", line 373, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlopen(/opt/local/lib/libicui18n.67.1.dylib, 6): Symbol not found: ___divmoddi4
Referenced from: /opt/local/lib/libicui18n.67.1.dylib
Expected in: /usr/lib/libgcc_s.1.dylib
>>> import libxml2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'libxml2'
>>> ^D
comment:14 follow-up: 20 Changed 3 years ago by bradleyCPA (B. Holder)
Just "sudo port install icu".
comment:15 Changed 3 years ago by kencu (Ken)
I'm still getting this:
$ python3.8 Python 3.8.10 (default, May 23 2021, 18:42:31) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import libxml2 >>>
So I guess until I can reproduce what is happening to you, I'm not going to be too helpful.
My tools are all built with the current cctools and ld64 however, so they are not showing as broken to me, although indeed I don't at the moment have an explanation for you why gcc on Tiger (I tried all of them I had, including the ones installed by the system originally) seems to give the proper answer for log2(4096) when cast to a float but not when cast to an int or a long int. That is a puzzle for me too.
comment:16 Changed 3 years ago by kencu (Ken)
whatever is causing that log2 thing, it also happens with clang, by the way, using a totally different set of headers and libraries. The libgcc.s.1.dylib you are worried about is not even in the mix here:
$ cat kentest.c
#include <math.h>
#include <stdio.h>
#include <stdint.h>
int main() {
unsigned int pagesize = 4096;
printf("%u %d \n", pagesize, (uint32_t)log2(pagesize));
}
$ clang-mp-3.4 -o kentest1 kentest.c
$ ./kentest1
4096 11
$ clang-mp-3.4 -v -Wl,-v -Wall -o kentest1 kentest.c clang version 3.4.2 (tags/RELEASE_34/dot2-final) Target: i386-apple-darwin8.11.1 Thread model: posix "/opt/local/libexec/llvm-3.4/bin/clang" -cc1 -triple i386-apple-macosx10.4.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name kentest.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -target-cpu yonah -target-linker-version 97.17 -v -resource-dir /opt/local/libexec/llvm-3.4/bin/../lib/clang/3.4.2 -Wall -fdebug-compilation-dir /Users/cunningh -ferror-limit 19 -fmessage-length 211 -mstackrealign -fobjc-runtime=macosx-fragile-10.4.0 -fencode-extended-block-signature -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /var/tmp/kentest-d9d8ed.o -x c kentest.c clang -cc1 version 3.4.2 based upon LLVM 3.4.2 default target i386-apple-darwin8.11.1 ignoring nonexistent directory "/usr/local/include" #include "..." search starts here: #include <...> search starts here: /opt/local/libexec/llvm-3.4/bin/../lib/clang/3.4.2/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. "/opt/local/libexec/llvm-3.4/bin/ld" -dynamic -arch i386 -macosx_version_min 10.4.0 -o kentest1 -lcrt1.o -v /var/tmp/kentest-d9d8ed.o -lSystem -lgcc_s.10.4 /opt/local/libexec/llvm-3.4/bin/../lib/clang/3.4.2/lib/darwin/libclang_rt.10.4.a @(#)PROGRAM:ld PROJECT:ld64-97.17 configured to support archs: i386 x86_64 ppc ppc64 armv6 armv7 Library search paths: /usr/lib /usr/local/lib Framework search paths: /Library/Frameworks/ /System/Library/Frameworks/
h$ otool -L kentest1 kentest1: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.11) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
comment:17 Changed 3 years ago by bradleyCPA (B. Holder)
I'd be curious how your system compares to this from my system
barf@tiger:/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/icu$ nm /opt/local/lib/libicui18n.67.1.dylib | grep "___divmoddi4"
U ___divmoddi4
barf@tiger:/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/icu$ nm /opt/local/lib/libgcc/libgcc_s.1.dylib | grep "___divmoddi4"
00004480 T ___divmoddi4
barf@tiger:/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/icu$ nm /usr/lib/libgcc_s.1.dylib | grep "___divmoddi4"
barf@tiger:/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/icu$
comment:18 Changed 3 years ago by bradleyCPA (B. Holder)
Isolate
#include <stdio.h>
int
main() {
fprintf(stdout, "starting proggy\n");
long long dividend = 123456;
long long divisor = 43;
long long remainder;
__divmoddi4(dividend, divisor, remainder);
}
Compile
gcc-mp-7 -L/opt/local/lib/libgcc -o test.dylib -dynamiclib -current_version 1.0 -compatibility_version 1.0 -O3 test.c
Evaluate
barf@tiger:~/Documents/lipo_work/divmoddi$ otool -L test.dylib
test.dylib:
test.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.11)
Run
barf@tiger:~/Documents/lipo_work/divmoddi$ python3.9
Python 3.9.5 (default, Jun 13 2021, 23:36:56)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16+boot on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> barf = ctypes.cdll.LoadLibrary("./test.dylib")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ctypes/__init__.py", line 452, in LoadLibrary
return self._dlltype(name)
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ctypes/__init__.py", line 374, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlopen(./test.dylib, 6): Symbol not found: ___divmoddi4
Referenced from: ./test.dylib
Expected in: /usr/lib/libgcc_s.1.dylib
>>> ^D
Seems to be most direct way to show the problem outside of specific ports.
comment:19 Changed 3 years ago by kencu (Ken)
Let's make a small program that calls that library, using gcc7, and I think you will see it works normally. I don't believe there is anything wrong with gcc7, cctools, lipo, or libgcc.s.1.dylib.
I think we will find out the issue is with the way python loads libraries, but we can cross that bridge once we prove the rest works normally and we don't need to blow up the entire MacPorts toolchain infrastructure.
comment:20 Changed 3 years ago by kencu (Ken)
Replying to bradleyCPA:
Just "sudo port install icu".
The reason I asked this was because when I tried to build icu I see this:
/opt/local/bin/g++-mp-7 -DU_ATTRIBUTE_DEPRECATED= -DU_I18N_IMPLEMENTATION -DU_HAVE_STRTOD_L=1 -DU_HAVE_XLOCALE_H=1 -I. -I../common -pipe -Os -D_GLIBCXX_USE_CXX11_ABI=0 -arch i386 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++11 -fvisibility=hidden -fno-common -c -MMD -MT "number_patternstring.d number_patternstring.o number_patternstring.ao" -o number_patternstring.ao number_patternstring.cpp
{standard input}:1540:junk `L_&L__ZN6icu_676number4impl22MutablePatternModifierD1Ev$stub$stub"$stub"' after expression
{standard input}:3878:invalid character '_' in mnemonic
gnumake[1]: *** [number_patternmodifier.ao] Error 1
so I had to build it with another c++11 compiler instead (a clang version that supports libstdc++). And indeed my clang version statically links in the runtime library, so the external call to __divmoddi4 does not exist in my icu library (and that would be why I don't see the loading problem you see).
Let me see if I can get icu to build with gcc7 to match what you have built.
comment:21 Changed 3 years ago by bradleyCPA (B. Holder)
Changed func name to foobar
barf@tiger:~/Documents/lipo_work/divmoddi$ cat main.c
#include <stdio.h>
int
main() {
fprintf(stdout, "marshmellows\n");
foobar();
}
barf@tiger:~/Documents/lipo_work/divmoddi$ cat test.c
#include <stdio.h>
int
foobar() {
fprintf(stdout, "starting proggy\n");
long long dividend = 123456;
long long divisor = 43;
long long remainder;
__divmoddi4(dividend, divisor, remainder);
}
barf@tiger:~/Documents/lipo_work/divmoddi$ gcc-mp-7 test.dylib -L/Users/brad/Documents/lipo_work/divmoddi/ -o main main.c
main.c: In function 'main':
main.c:6:2: warning: implicit declaration of function 'foobar' [-Wimplicit-function-declaration]
foobar();
^~~~~~
barf@tiger:~/Documents/lipo_work/divmoddi$ otool -L main
main:
test.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.11)
barf@tiger:~/Documents/lipo_work/divmoddi$ ./main
marshmellows
starting proggy
dyld: lazy symbol binding failed: Symbol not found: ___divmoddi4
Referenced from: test.dylib
Expected in: /usr/lib/libgcc_s.1.dylib
dyld: Symbol not found: ___divmoddi4
Referenced from: test.dylib
Expected in: /usr/lib/libgcc_s.1.dylib
Trace/BPT trap
So yeah, not a python thing.
comment:22 Changed 3 years ago by bradleyCPA (B. Holder)
I don't remember having that number_patternmodifier issue using any of the ports I've tried.
comment:23 Changed 3 years ago by bradleyCPA (B. Holder)
That's not to say there isn't an issue that I've forgotten. For instance, I remember that when building gnutls that I had to add
configure.ldflags-append -lgcc_eh configure.args-append --disable-hardware-acceleration
it hasn't been easy to install at least a few things on tiger that I've tried.
comment:24 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
| Cc: | ryandesign added |
|---|
Replying to kencu:
I can see you have an error when you import that libxml2 python library when you are using python3.
I still do not have a ready explanation for you as to why you see that, but it works fine for me, and we have been using these things on MacPorts for many many years, so it is not likely that the error is in these tools. Not impossible, just extremely unlikely.
I see the problem as well. See #60776.
comment:25 Changed 3 years ago by kencu (Ken)
I'll see if I can reproduce your library issue.
I'll take a look at Ryan's ticket later.
One thing to note is that gcc7/libgcc7 is no longer maintained or updated upstream, for some time now, which is why I'm working on bringing these libraries up to current versions.
comment:26 Changed 3 years ago by bradleyCPA (B. Holder)
barf@tiger:~/Documents/lipo_work/divmoddi$ /usr/bin/ld -v Apple Computer, Inc. version cctools-622.9~2
crossreferenced with https://opensource.apple.com/source/cctools/cctools-622.9/misc/lipo.c.auto.html yields following gem
/* * Special case ppc, ppc64, i386 and x86_64 architectures and return 12. * We know that with those architectures that the kernel and mmap only * need file offsets to be page (4096 byte) aligned. */ if(mhp->cputype == CPU_TYPE_POWERPC || mhp->cputype == CPU_TYPE_POWERPC64 || mhp->cputype == CPU_TYPE_I386 || mhp->cputype == CPU_TYPE_X86_64) return(12);
This continues to fuel my suspicion that lipo is broken on tiger and is the cause of my entire problem.
comment:27 Changed 3 years ago by kencu (Ken)
Here is an interesting thread from the ancient python bug list showing the the system log2 function on MacOSX Tiger i386 (but apparently not ppc) was felt to be too buggy to use:
https://bugs.python.org/issue11888
I wonder if this issue also happens on ppc then?
I am starting to be convinced that the offset should be fixed, indeed. That is looking like a good pickup to me, excellent work.
In the cctools source it indicates that proper code offsets should be page aligned, which makes sense, and that means 4096. So so so many complicated ports pass their test suites, though, that I have a hard time believing that there is widespread wreckage. But then again, pretty much nobody is actually using lipo on Tiger any longer because we can't build most things universal anyway, so we would not likely have noticed if lipo stopped working....esp if it is just lipo on i386 Tiger...
By the way, the lipo command invocation comes from our Portfile, not from gcc7 itself:
so outside of MacPorts, nobody would ever see or test this exact issue.
You could rebuild libgcc7 and specify /usr/bin/lipo in the Portfile to use the system one. Presumably that generates libgcc7 libraries with the 4096 offsets? I would hope.
comment:29 Changed 3 years ago by kencu (Ken)
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.
- 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.
- 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.
- 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.
comment:30 Changed 3 years ago by kencu (Ken)
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.
comment:31 Changed 3 years ago by kencu (Ken)
| Port: | cctools libgcc7 added |
|---|---|
| Summary: | py-libxml2 icu cctools - FAT libraries built on i386 Mac OS X Tiger fail to run → cctools @949: lipo make FAT libraries on i386 Mac OS X Tiger with wrong offset: fail to load |
Luckily there are likely few libraries built as FAT any longer, as cross-arch FAT building has been impossible since the c++11 era. Only rare libraries, unfortunately some of them in libgcc7, are built FAT.
comment:32 Changed 3 years ago by kencu (Ken)
| Cc: | jmroot added |
|---|
Josh, looping you in here for any insights.
Looks like the fix here is to roll back to a "known good" cctools for Tiger, eg. 921, and then rebuild libgcc7. I haven't looked to see if PPC is affected.
The lipo issue stems from some kind of a bug in log2(x) on (at least) i386 Tiger. That could easily enough be worked around using workarounds that were removed > 921, but it is quite possible there could be other subtle issues in cctools > 921 that we don't know about yet, so rolling back seems safest.
comment:33 Changed 3 years ago by kencu (Ken)
| Summary: | cctools @949: lipo make FAT libraries on i386 Mac OS X Tiger with wrong offset: fail to load → cctools @949: lipo generates FAT libraries on i386 Mac OS X Tiger with wrong offset: fail to load |
|---|
comment:34 Changed 3 years ago by kencu (Ken)
Aha.
Tiger has log2l(x):
$ cat kentest.c
#include <math.h>
#include <stdio.h>
#include <stdint.h>
int main() {
uint32_t pagesize = 4096;
printf("%u %d %f \n", pagesize, (uint32_t)log2(pagesize), log2(pagesize));
printf("%u %d %f \n", pagesize, (uint32_t)log2l(pagesize), log2l(pagesize));
return 0;
}
then:
$ ./kentest2 4096 11 12.000000 4096 12 -2.000000
So that appears to be at least part of the answer to the log2 mystery. On 32 bit systems, uint32_t apparently overflows the log2 function, and you need to use log2l
(Although why the -2.00000 for the float cast? )
comment:35 Changed 3 years ago by kencu (Ken)
because it also has log2f of course:
$ cat kentest.c
#include <math.h>
#include <stdio.h>
#include <stdint.h>
int main() {
uint32_t pagesize = 4096;
printf("%u %d %f \n", pagesize, (uint32_t)log2(pagesize), log2(pagesize));
printf("%u %d %f \n", pagesize, (uint32_t)log2l(pagesize), log2f(pagesize));
return 0;
}
and then you get the right answers:
$ gcc-mp-7 -o kentest2 kentest.c $ ./kentest2 4096 11 12.000000 4096 12 12.000000
comment:36 Changed 3 years ago by jmroot (Joshua Root)
It's rare that you want to just cast from a floating point type to an integer, as that will truncate (so 11.999 becomes 11). You usually want to use lrintf() or similar.
comment:37 Changed 3 years ago by bradleyCPA (B. Holder)
| Summary: | cctools @949: lipo generates FAT libraries on i386 Mac OS X Tiger with wrong offset: fail to load → cctools @949: lipo make FAT libraries on i386 Mac OS X Tiger with wrong offset: fail to load |
|---|
Cool. I took the long way of patching lipo in cctools and installing ports on another i386 Tiger system. (Sadly, compiling everything takes quite a bit of time for me.) icu and libxml2 in python are fine in that environment now using this.
--- misc/lipo.c.orig 2021-07-10 09:45:23.000000000 -0400
+++ misc/lipo.c 2021-07-10 09:43:39.000000000 -0400
@@ -1935,7 +1935,7 @@
struct arch_flag arch_flag;
if (get_arch_from_flag((char*)arch_name, &arch_flag)) {
uint32_t pagesize = get_segalign_from_flag(&arch_flag);
- return (uint32_t)(log2(pagesize));
+ return (uint32_t)(lround(log2(pagesize)));
}
}
comment:38 Changed 3 years ago by kencu (Ken)
once I can test on i386 10.6.8, 10.5, and 10.4 PPC, we'll probably go with something like this:
--- misc/lipo.c.orig
+++ misc/lipo.c
@@ -1935,7 +1935,11 @@
struct arch_flag arch_flag;
if (get_arch_from_flag((char*)arch_name, &arch_flag)) {
uint32_t pagesize = get_segalign_from_flag(&arch_flag);
#if __LP64__
return (uint32_t)(log2(pagesize));
#else
return (uint32_t)(log2l(pagesize));
#endif
}
}
although who knows how many other 32bit issues might be hiding?
comment:39 Changed 3 years ago by jmroot (Joshua Root)
Switching to log2l is not the correct fix, Ken. The issue is the lack of rounding, not any bug in the function. It happens to work with a truncating conversion sometimes because of minor variations in FPU behaviour, giving a result a tiny bit larger than 12 instead of a tiny bit smaller.
comment:40 Changed 3 years ago by kencu (Ken)
log2(double x) on Tiger is supposed to return a double, but perhaps it uses a float internally and then does a poor internal conversion to a double.
double
log2(double x);
long double
log2l(long double x);
float
log2f(float x);
I tried a bunch of different log2(4096) versions and it always seems to be wrong, so I guess it is just that bad :>
BTW, on PPC Tiger, log2 works properly, and there is no such issue. It's only an i386 thing, it appears:
$ ./kentest1 4096 12 12.000000 4096 12 12.000000
comment:41 Changed 3 years ago by jmroot (Joshua Root)
All floating point calculations are inherently inexact. There is no "right" and "wrong" behaviour you're demonstrating here, just (very slightly) different.
To put it another way, there is a roughly 50% chance when casting any floating point number to an integer type that you will get a result that is not the integer that is closest to the original value, but one less than that. That's just how truncation works, and is why you don't want to do it, on any platform.
comment:42 Changed 3 years ago by kencu (Ken)
I gotcha now. I briefly forgot that double was a floating point type and was taken down a int vs long int vs long long int thought pattern.
Will fix, and thanks.
comment:43 Changed 3 years ago by kencu (Ken)
| Owner: | set to kencu |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Example program illustrating problem