<div dir="auto">Hello,<div dir="auto"><br></div><div dir="auto">I have compiled TeXLive on </div><div dir="auto">OpenIndiana without any problem.</div><div dir="auto">So I do not think your local solution</div><div dir="auto">is a real solution as it might break</div><div dir="auto">compilation on more recent versions</div><div dir="auto">of Solaris and Illumos (Open version of</div><div dir="auto">Solaris).</div><div dir="auto"><br></div><div dir="auto">AS<br><br><div data-smartmail="gmail_signature" dir="auto">Sent from my Android device...</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Στις Σάβ, 4 Ιαν 2020, 08:17 ο χρήστης Mojca Miklavec <<a href="mailto:mojca.miklavec.lists@gmail.com">mojca.miklavec.lists@gmail.com</a>> έγραψε:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 13 Dec 2019 at 01:54, Mojca Miklavec wrote:<br>
> V čet., 12. dec. 2019 19:27 je oseba Karl Berry napisala:<br>
>><br>
>> I've updated the ICU in TeX Live to ICU 65.1 (r53103). I surmise it is<br>
>> likely to break the build on some systems. Please give it a try if you can.<br>
><br>
> It fails to build on Solaris and on an older Mac. On Mac there is a Python-related issue, on Solaris it's C++.<br>
<br>
The build issue on Mac can be fixed by defining something like<br>
    PYTHON=/path/to/python3.8<br>
however the build time (admittedly on a VM on an older box) increased<br>
from cca. 2 h 20 min to cca. 5 h 20 min which sounds a bit insane and<br>
not that easy to explain.<br>
<br>
On the other hand the build on Solaris seems to be caused by the following<br>
    <a href="https://docs.oracle.com/cd/E19253-01/816-5174/proc-4/index.html" rel="noreferrer noreferrer" target="_blank">https://docs.oracle.com/cd/E19253-01/816-5174/proc-4/index.html</a><br>
<br>
    For 32–bit x86 processes, the predefined constants listed below<br>
can be used as indices to refer to the corresponding registers.<br>
<br>
    SS<br>
    UESP<br>
    EFL<br>
    CS<br>
    EIP<br>
    ERR<br>
    TRAPNO<br>
    EAX<br>
    ECX<br>
    EDX<br>
    EBX<br>
    ESP<br>
    EBP<br>
    ESI<br>
    EDI<br>
    DS<br>
    ES<br>
    GS<br>
<br>
    The preceding constants are listed in <sys/regset.h>.<br>
<br>
clearly conflicting with<br>
<br>
    enum {<br>
        L=  U_LEFT_TO_RIGHT,                /*  0 */<br>
        R=  U_RIGHT_TO_LEFT,                /*  1 */<br>
        EN= U_EUROPEAN_NUMBER,              /*  2 */<br>
        ES= U_EUROPEAN_NUMBER_SEPARATOR,    /*  3 */<br>
        ET= U_EUROPEAN_NUMBER_TERMINATOR,   /*  4 */<br>
        AN= U_ARABIC_NUMBER,                /*  5 */<br>
        CS= U_COMMON_NUMBER_SEPARATOR,      /*  6 */<br>
    ...<br>
    }<br>
<br>
I reported the issue upstream in mid-december, but there was no<br>
response on their mailing list yet (I sent some more details now).<br>
<br>
I still didn't quite figure out where these constants are actually<br>
defined. They are supposed to come from<br>
    /usr/include/sys/regset.h<br>
(both according to the compiler and the docs) but I fail to see what<br>
black magic precisely is setting them :)<br>
Not that I should actually care.<br>
<br>
Maybe we could patch the sources locally in TeX Live to undefine ES<br>
and CS until upstream fixes the issue?<br>
I assume that TeX Live doesn't use Solaris registers? :) As long as<br>
some other headers don't start interfering ...<br>
<br>
Mojca<br>
<br>
</blockquote></div>