Building icu port on macos x tiger

[Ken Cunningham]

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/20210627/982e1ef2/attachment.htm>