Building icu port on macos x tiger

Ken Cunningham ken.cunningham.webuse at gmail.com
Wed Jun 30 14:22:14 UTC 2021 

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.

I'm not 100% sure how changing this information in that library has solved
your issue, however.

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.

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.

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.

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.

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.

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.

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.

Glad to have you around, please keep contributing.

Ken


On Wed, Jun 30, 2021 at 12:21 AM brian <bholder+macports at gmail.com> wrote:

> 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/84c9eaa3/attachment.htm>

More information about the macports-users mailing list