Building icu port on macos x tiger

[brian]

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

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

I'll see about sorting out where Trac is and recreating the issue as time
permits.

Thanks.

On Sun, Jun 27, 2021 at 12:46 PM Ken Cunningham <
ken.cunningham.webuse at gmail.com> wrote:

> Now here we have to make sure we are asking the right question.
>
> 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.
>
> 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.
>
> Certain things set DYLD_LIBRARY_PATH and can totally hose you without you
> having any idea what is going on.
>
> 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.
>
> It is much more likely that something else is at play.
>
> 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.
>
> 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.
>
> 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.
>
> On Sat, Jun 26, 2021 at 7:05 PM brian <bholder+macports at gmail.com> wrote:
>
>> You assume correctly regarding the build but I'm not sure I grok your
>> suggested alternative for making it run properly. I have:
>>
>> barf at tiger:/opt/local/var/macports/sources/
>> rsync.macports.org/macports/release/tarballs/ports$ otool -L
>> /opt/local/lib/libicui18n.67.1.dylib
>> /opt/local/lib/libicui18n.67.1.dylib:
>>         /opt/local/lib/libicui18n.67.dylib (compatibility version 67.0.0,
>> current version 67.1.0)
>>         /opt/local/lib/libicuuc.67.dylib (compatibility version 67.0.0,
>> current version 67.1.0)
>>         /opt/local/lib/libicudata.67.dylib (compatibility version 67.0.0,
>> current version 67.1.0)
>>         /opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version
>> 7.0.0, current version 7.24.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.9)
>> barf at tiger:/opt/local/var/macports/sources/
>> rsync.macports.org/macports/release/tarballs/ports$ nm
>> /usr/lib/libgcc_s.1.dylib | grep divmoddi
>> /usr/lib/libgcc_s.1.dylib(_udivmoddi4_s.o):
>> 90bd5b6d T ___udivmoddi4
>> braf at tiger:/opt/local/var/macports/sources/
>> rsync.macports.org/macports/release/tarballs/ports$ nm
>> /opt/local/lib/libgcc/libgcc_s.1.dylib | grep divmoddi
>> 00004480 T ___divmoddi4
>> 000048b0 T ___udivmoddi4
>> barf at tiger:/opt/local/var/macports/sources/
>> rsync.macports.org/macports/release/tarballs/ports$ port installed
>> ...
>> gcc7 @7.5.0_2 (active)
>> ...
>> icu @67.1_4 (active)
>> ...
>>
>> 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?
>>
>> Thanks.
>>
>> On Sat, Jun 26, 2021 at 7:12 PM Ken Cunningham <
>> ken.cunningham.webuse at gmail.com> wrote:
>>
>>> >
>>> 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.dylib
>>>
>>> > resulting from the default build configuration of macports icu on Tiger?
>>>
>>>
>>>
>>> Assuming you built icu with gcc7 on Tiger, I suppose it is now expecting to find that symbol in libgcc:
>>>
>>>
>>> https://github.com/atgreen/gcc/blob/master/libgcc/config/spu/divmodti4.c
>>>
>>>
>>> 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.
>>>
>>>
>>> So you have to force a newer gcc (specifically to get a newer libgcc), and it should be there.
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20210628/0bb2daed/attachment.htm>