Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

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

lipo_tiger_example_failure.zip (797 bytes) - added by bradleyCPA (B. Holder) 3 years ago.
Example program illustrating problem

Download all attachments as: .zip

Change History (45)

Changed 3 years ago by bradleyCPA (B. Holder)

Example program illustrating problem

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...

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?

Version 0, edited 3 years ago by kencu (Ken) (next)

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.

Last edited 3 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

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

Last edited 3 years ago by kencu (Ken) (previous) (diff)

comment:9 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:13 Changed 3 years ago by kencu (Ken)

exactly how did you build icu on Tiger i386?

comment:14 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)
Last edited 3 years ago by kencu (Ken) (previous) (diff)

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 in reply to:  14 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 in reply to:  9 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:

https://github.com/macports/macports-ports/blob/6c6143dfd92000f40458ea15bda425cac1d490b6/lang/gcc7/Portfile#L304

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:28 Changed 3 years ago by kencu (Ken)

I will ask Jeremy and Iain what they think of this.

Last edited 3 years ago by kencu (Ken) (previous) (diff)

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.

  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.
  2. 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.
  3. 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 runcctools @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 loadcctools @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? )

Last edited 3 years ago by kencu (Ken) (previous) (diff)

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 loadcctools @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 
Last edited 3 years ago by kencu (Ken) (previous) (diff)

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: newclosed

In f1369be4de76379f0ed80509918c2e903e005133/macports-ports (master):

cctools: fix log2 rounding issue in lipo

lipo calls log2(x) and then casts that to a uint32_t
on some systems, this casts away from the correct value
fix that by rounding the value to the nearest int first,
then casting.

closes: #63164

thanks to @bradleyCPA (B. Holder) for sorting this out!

comment:44 Changed 3 years ago by kencu (Ken)

In 7939db59831e0079ec97a25ce1f6cd02372c5813/macports-ports (master):

libgcc7: revbump to pick up cctools lipo fix

the version of lipo in cctools-949 generated a few incorrectly-laid-out
FAT libraries due to an alignment error related to log2 casting.

This lipo issue was fixed, and now we rebuild libgcc7 to generate
the new, correctly-made FAT libraries.

see: #63164
see: #60776

Note: See TracTickets for help on using tickets.