Building icu port on macos x tiger

[brian]

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:

barf at tiger:~/lib/foo$ 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 4096
    size 99832
    align 2^12 (4096)
barf at tiger:~/lib/foo$ otool -f /opt/local/lib/libgcc/libgcc_s.1.dylib.bak
Fat headers
fat_magic 0xcafebabe
nfat_arch 1
architecture 0
    cputype 7
    cpusubtype 3
    capabilities 0x0
    offset 2048
    size 99832
    align 2^11 (2048)

and now the problem is solved

barf at tiger:~/Documents$ 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
>>>

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.

On Mon, Jun 28, 2021 at 9:16 AM brian <bholder+macports at gmail.com> wrote:

> > 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/20210630/c2ac3baa/attachment.htm>