<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>One option to reduce the pain I’ve inflicted on the world from strict ACE versioning would be to offer dynamically linked binaries for all of these, and distribute an updated libace.so with each ACE release.  That would entail either the user either employ root privileges to install said library or set up some sort of shared library repository within their home directories using LD_LIBRARY_PATH (doable, but a bit of a pain to set up the first time).  How would users feel about such a scenario?</div><div><br></div><div>Another option would be for me to make a more nuanced versioning system, where a given grammar image format version would be compatible with a substantial range of tool versions.  As is I assume the grammar image format may have changed between each release, which is actually only sometimes true.</div><div><br></div><div>Using scripts to compile more tools and release static binaries of every tool at every release is probably also worth doing but is cumbersome both for users and me and hence not a completely perfect solution, especially as the number of minor tools depending on ACE grammar images grows.</div><div><br></div><div>Best,</div><div>Woodley</div><div><br>On Dec 11, 2018, at 7:21 AM, Francis Bond <<a href="mailto:bond@ieee.org">bond@ieee.org</a>> wrote:<br><br></div><blockquote type="cite"><div><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> </div></blockquote></body></html>