<div dir="ltr"><div><div><div><div><div><div><div><div>I'm going to start by saying that I have great respect for your willingness to explore, and you clearly have some skills. Your contributions to supporting the older systems on Tiger will be much appreciated over time.<br><br></div>I'm not 100% sure how changing this information in that library has solved your issue, however.<br><br></div>The dyld in Tiger is usually able to handle jumps of up to 16MB in code -- I am not an expert, by any means, but you will see a patch in our ld64-97 port that fixed an issue where branch islands were not working properly. One of the Apple engineers was involved in looking that over. It was a simple typo.<br><br></div>I used the current libgcc7 / gcc7 / ld64-97 / dyld to build TenFourFox on PPC and Intel on Tiger, and it has huge libraries with large offsets. In that case, if you try to disable optimizations with a -O0, the branches can be too far apart and the code won't link.<br><br></div>I'm saying all this to point out that I am certain that (in the general sense) the dyld in Tiger can handle a 4K & 2K jump without trouble.<br><br></div>The library you changed the code on has been more or less the same for years, and passes the bulk of the libgcc test suite correctly.<br><br></div>You do seem to have been able to load libxml2 using python3 once you made that change in libgcc_s.1.dylib, I won't argue about that point.<br><br></div>Why that might have allowed the library to load, what it did to the function of libgcc_s.1.dylib in general, whether libgcc_s.1.dylib even works at all any longer, is an open question. Before we could make such a change in the build of libgcc7, we'd clearly need to dive way deeper here to see what is going on.<br><br></div><div>Once again, whatever is causing libxml2 to not be loadable in python3, I suspect it will be something else in the end. Perhaps we might get an independent verification from someone else on TIger PPC that they see the same issue.<br><br></div><div>Glad to have you around, please keep contributing.<br><br></div><div>Ken<br></div><div><br></div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Wed, Jun 30, 2021 at 12:21 AM brian <<a href="mailto:bholder%2Bmacports@gmail.com">bholder+macports@gmail.com</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr">In case someone else runs into this and whatever, another way that I found to fix this issue was to hexedit /opt/lib/libgcc/libgcc_s.1.dylib as per:<br><br>barf@tiger:~/lib/foo$ otool -f /opt/local/lib/libgcc/libgcc_s.1.dylib<br>Fat headers<br>fat_magic 0xcafebabe<br>nfat_arch 1<br>architecture 0<br> cputype 7<br> cpusubtype 3<br> capabilities 0x0<br> offset 4096<br> size 99832<br> align 2^12 (4096)<br>barf@tiger:~/lib/foo$ otool -f /opt/local/lib/libgcc/libgcc_s.1.dylib.bak<br>Fat headers<br>fat_magic 0xcafebabe<br>nfat_arch 1<br>architecture 0<br> cputype 7<br> cpusubtype 3<br> capabilities 0x0<br> offset 2048<br> size 99832<br> align 2^11 (2048)<br><div><br></div><div>and now the problem is solved</div><div><br></div><div>barf@tiger:~/Documents$ python3<br>Python 3.9.5 (default, Jun 13 2021, 23:36:56) <br>[GCC 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16+boot on darwin<br>Type "help", "copyright", "credits" or "license" for more information.<br>>>> import libxml2<br>>>> <br></div><div><br></div><div>without removing optimizations from icu. It appears that dyld in tiger doesn't like the offset and/or align value of 2048 (in the fat header) used when building libgcc_s.1.dylib from gcc7 port. 4096 makes it happier. So change the values and pad with zeros appropriately.</div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Mon, Jun 28, 2021 at 9:16 AM brian <<a target="_blank" href="mailto:bholder%2Bmacports@gmail.com">bholder+macports@gmail.com</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr">> So it is not likely going to be that the root problem is that icu is built with incorrect optimization settings. I'm actually quite surprised changing those fixed things for you, and have no idea why that would happen. <div><br></div><div>The idea was to adjust things so that for symbol lookup purposes it didn't matter if the application/system was looking /usr/lib/libgcc_s.1.dylib or /opt/local/lib/libgcc/libgcc_s.1.dylib since the symbols used would be in both (by explicitly not using ___divmoddi4 optimization during compilation).</div><div><br></div><div>I'll see about sorting out where Trac is and recreating the issue as time permits.</div><div><br></div><div>Thanks.</div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Sun, Jun 27, 2021 at 12:46 PM Ken Cunningham <<a target="_blank" href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr">Now here we have to make sure we are asking the right question. <div><br></div><div>If your build of icu doesn't work at all, and every time you try to use something that is built against icu it fails with this error, then the problem must be with icu and we have to look there.</div><div><br></div><div>If icu seems to work whenever you use it, passes the icu test suite (there is one), and it is only the build of whatever it is that you are trying to use it with that generates that python-related error, then you have to look at the python thing and see what is going on. The error could be with that, or with the build of python, or elsewhere.</div><div><br></div><div>Certain things set DYLD_LIBRARY_PATH and can totally hose you without you having any idea what is going on.</div><div><br></div><div>So it is not likely going to be that the root problem is that icu is built with incorrect optimization settings. I'm actually quite surprised changing those fixed things for you, and have no idea why that would happen. </div><div><br></div><div>It is much more likely that something else is at play.</div><div><br></div><div>At the moment, I don't know if you are on PPC or Intel, and what it was you were trying to build/run/install when the thing you were after failed.</div><div><br></div><div>So probably this is the point where you open a ticket in Trac about what you were actually doing when the error occurred, and post up the full log.</div><div><br></div><div>There are many smart people here who can at least try to sort you out. Almost none of them use Tiger, but that doesn't matter much, as they can spot errors and issues when they see them.</div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Sat, Jun 26, 2021 at 7:05 PM brian <<a target="_blank" href="mailto:bholder%2Bmacports@gmail.com">bholder+macports@gmail.com</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr">You assume correctly regarding the build but I'm not sure I grok your suggested alternative for making it run properly. I have:<br><br>barf@tiger:/opt/local/var/macports/sources/<a target="_blank" href="http://rsync.macports.org/macports/release/tarballs/ports$">rsync.macports.org/macports/release/tarballs/ports$</a> otool -L /opt/local/lib/libicui18n.67.1.dylib<br>/opt/local/lib/libicui18n.67.1.dylib:<br> /opt/local/lib/libicui18n.67.dylib (compatibility version 67.0.0, current version 67.1.0)<br> /opt/local/lib/libicuuc.67.dylib (compatibility version 67.0.0, current version 67.1.0)<br> /opt/local/lib/libicudata.67.dylib (compatibility version 67.0.0, current version 67.1.0)<br> /opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.24.0)<br> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)<br> /opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)<br> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9)<br>barf@tiger:/opt/local/var/macports/sources/<a target="_blank" href="http://rsync.macports.org/macports/release/tarballs/ports$">rsync.macports.org/macports/release/tarballs/ports$</a> nm /usr/lib/libgcc_s.1.dylib | grep divmoddi<br>/usr/lib/libgcc_s.1.dylib(_udivmoddi4_s.o):<br>90bd5b6d T ___udivmoddi4<br>braf@tiger:/opt/local/var/macports/sources/<a target="_blank" href="http://rsync.macports.org/macports/release/tarballs/ports$">rsync.macports.org/macports/release/tarballs/ports$</a> nm /opt/local/lib/libgcc/libgcc_s.1.dylib | grep divmoddi<br>00004480 T ___divmoddi4<br>000048b0 T ___udivmoddi4<div>barf@tiger:/opt/local/var/macports/sources/<a target="_blank" href="http://rsync.macports.org/macports/release/tarballs/ports$">rsync.macports.org/macports/release/tarballs/ports$</a> port installed<br>...<br>gcc7 @7.5.0_2 (active)<br>...<br>icu @67.1_4 (active)<br>...<br><div><br></div><div>OS X Tiger seems to be looking in the wrong libgcc_s for this particular symbol. How would I force the OS to look in the right place instead of just adjusting the compiler to not use this optimization?</div><div><br></div><div>Thanks.</div></div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Sat, Jun 26, 2021 at 7:12 PM Ken Cunningham <<a target="_blank" href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">> <span style="color:rgb(0,0,0);white-space:pre-wrap">dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/libxml2mod.so,</span></div><div dir="ltr"><pre style="white-space:pre-wrap;color:rgb(0,0,0)">> 2): Symbol not found: ___divmoddi4
Referenced from: /opt/local/lib/libicui18n.67.dylib
> resulting from the default build configuration of macports icu on Tiger?
</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">Assuming you built icu with gcc7 on Tiger, I suppose it is now expecting to find that symbol in libgcc:</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><a target="_blank" href="https://github.com/atgreen/gcc/blob/master/libgcc/config/spu/divmodti4.c">https://github.com/atgreen/gcc/blob/master/libgcc/config/spu/divmodti4.c</a><br></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">You would have built icu with a newer gcc compiler to get c++11 support for icu, but you are probably now using an older version of the gcc compiler like apple-gcc42, and that doesn't have that symbol in libgcc.</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">So you have to force a newer gcc (specifically to get a newer libgcc), and it should be there.</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre></div></div></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>