<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 dir="ltr" class="gmail_attr">On Sun, Jun 27, 2021 at 12:46 PM Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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 dir="ltr" class="gmail_attr">On Sat, Jun 26, 2021 at 7:05 PM brian <<a href="mailto:bholder%2Bmacports@gmail.com" target="_blank">bholder+macports@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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 href="http://rsync.macports.org/macports/release/tarballs/ports$" target="_blank">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 href="http://rsync.macports.org/macports/release/tarballs/ports$" target="_blank">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 href="http://rsync.macports.org/macports/release/tarballs/ports$" target="_blank">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 href="http://rsync.macports.org/macports/release/tarballs/ports$" target="_blank">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 dir="ltr" class="gmail_attr">On Sat, Jun 26, 2021 at 7:12 PM Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" target="_blank">ken.cunningham.webuse@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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 href="https://github.com/atgreen/gcc/blob/master/libgcc/config/spu/divmodti4.c" target="_blank">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>