<div dir="ltr">If and when you are looking at building things, it would be great if you could script creating a full set of binaries for each ace version. This would make life much easier for Zhong, Jacy and Indra.<div><br></div><div>ace</div><div>ace-which-makes-quickcheck files</div><div>fftb</div><div>ffmaster, ffworker</div><div>csaw</div><div>exmaster, exworker</div><div><br></div><div>yzlui </div><div>art </div><div>I'm not sure if the last two have to be redone for each version of ace, ...</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 11:09 PM Woodley Packard <<a href="mailto:sweaglesw@sweaglesw.org">sweaglesw@sweaglesw.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Stephan,<br> <br> My most recent attempt at building anything in the RHEL VM was not a successful experience. I have another ancient and 64-bit build environment that I used for my recent ACE and FFTB binary contributions to the LOGON tree, so far without noticeable incident. I believe you are right that attempts to make yzlui completely statically linked have been failures ever since the addition of pango support. I expect to be able to produce a yzlui binary of similar portability to the current LOGON tree’s ACE and FFTB without too much trouble, and will give that a try.<br> <br> >From the San Jose airport, where there is a distinct lack of adorable snow,<br> Woodley<br> <br> > On Dec 11, 2018, at 6:26 AM, Stephan Oepen <<a href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>> wrote:<br> > <br> > hi again, woodley,<br> > <br> > returning to a thread from a couple of years ago :-). dan is visiting<br> > this week, and we are seeking to consolidate things in the LOGON tree<br> > for premium support of the latest ERG release. in doing so, we<br> > re-discovered that the yzlui binaries in LOGON (contributed by you in<br> > february 2014) actually both are compiled for 32-bit environments. i<br> > dimly recall that was a deliberate decision at the time, but today it<br> > causes dan problems that he used to not be aware of (because he had<br> > back-dated his yzlui locally to an older 64-bit binary of unknown<br> > provenance); somewhat curiously, it does not cause me problems,<br> > apparently because i happen to have the right set of 32-bit<br> > compatibility libraries installed.<br> > <br> > hence ...<br> > <br> >> I believe there is no reason a 64-bit yzlui could not be built, and I also believe I still am in possession of an elderly RedHat VM, although I am not sure it is a 64-bit VM.<br> >> <br> >> Is the problem that running 32-bit binaries on a 64-bit system requires extra compatibility libraries, and you would like to remove that dependency?<br> > <br> > yes, indeed. it is getting increasingly difficult to make users<br> > install the right set of compatibility libraries, i feel. and i<br> > believe we had concluded (in 2014) that yzlui actually had to be<br> > dynamically linked and that at least several of its shared library<br> > dependencies could not be bundled with the binary, for proper font and<br> > unicode support on a specific local system. does that resonate with<br> > your memory from those days?<br> > <br> > so, could we take you up on the kind offer to try and cook a 64-bit<br> > version of yzlui in a suitably rustic linux environment (RHEL6 appears<br> > to be at glibc version 2.12 today; i suspect the virtual machine image<br> > you have may have originated from here)?<br> > <br> > best wishes; the snow is adorable! oe<br> <br> <br> </blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Francis Bond <<a href="http://www3.ntu.edu.sg/home/fcbond/" target="_blank">http://www3.ntu.edu.sg/home/fcbond/</a>><br>Division of Linguistics and Multilingual Studies<br>Nanyang Technological University<br></div>