<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi again Francis et al,<div class=""><br class=""></div><div class="">On the subject of making quickcheck files: the SVN version of ACE now has a command-line option --gen-qc, which (1) causes quickcheck to be disabled for whatever operations take place, and (2) records unification failures and prints a suitable quickcheck skeleton upon termination (in ACE-readable format, though sadly not PET-readable format; maybe someone will be able to scriptually reformat if they care).  I can’t quite recall what historic situation resulted in you having something called "ace-which-makes-quickcheck files", but in the future this should be subsumed by the ordinary ACE.<div class=""><br class=""></div><div class="">Best,</div><div class="">-Woodley<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 11, 2018, at 7:21 AM, Francis Bond <<a href="mailto:bond@ieee.org" class="">bond@ieee.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""><br class=""></div><div class="">ace</div><div class="">ace-which-makes-quickcheck files</div><div class="">fftb</div><div class="">ffmaster, ffworker</div><div class="">csaw</div><div class="">exmaster, exworker</div><div class=""><br class=""></div><div class="">yzlui    </div><div class="">art </div><div class="">I'm not sure if the last two have to be redone for each version of ace, ...</div><div class=""><br class=""></div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Dec 11, 2018 at 11:09 PM Woodley Packard <<a href="mailto:sweaglesw@sweaglesw.org" class="">sweaglesw@sweaglesw.org</a>> wrote:<br class=""></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 class=""> <br class=""> 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 class=""> <br class=""> From the San Jose airport, where there is a distinct lack of adorable snow,<br class=""> Woodley<br class=""> <br class=""> > On Dec 11, 2018, at 6:26 AM, Stephan Oepen <<a href="mailto:oe@ifi.uio.no" target="_blank" class="">oe@ifi.uio.no</a>> wrote:<br class=""> > <br class=""> > hi again, woodley,<br class=""> > <br class=""> > returning to a thread from a couple of years ago :-).  dan is visiting<br class=""> > this week, and we are seeking to consolidate things in the LOGON tree<br class=""> > for premium support of the latest ERG release.  in doing so, we<br class=""> > re-discovered that the yzlui binaries in LOGON (contributed by you in<br class=""> > february 2014) actually both are compiled for 32-bit environments.  i<br class=""> > dimly recall that was a deliberate decision at the time, but today it<br class=""> > causes dan problems that he used to not be aware of (because he had<br class=""> > back-dated his yzlui locally to an older 64-bit binary of unknown<br class=""> > provenance); somewhat curiously, it does not cause me problems,<br class=""> > apparently because i happen to have the right set of 32-bit<br class=""> > compatibility libraries installed.<br class=""> > <br class=""> > hence ...<br class=""> > <br class=""> >> 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 class=""> >> <br class=""> >> 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 class=""> > <br class=""> > yes, indeed.  it is getting increasingly difficult to make users<br class=""> > install the right set of compatibility libraries, i feel.  and i<br class=""> > believe we had concluded (in 2014) that yzlui actually had to be<br class=""> > dynamically linked and that at least several of its shared library<br class=""> > dependencies could not be bundled with the binary, for proper font and<br class=""> > unicode support on a specific local system.  does that resonate with<br class=""> > your memory from those days?<br class=""> > <br class=""> > so, could we take you up on the kind offer to try and cook a 64-bit<br class=""> > version of yzlui in a suitably rustic linux environment (RHEL6 appears<br class=""> > to be at glibc version 2.12 today; i suspect the virtual machine image<br class=""> > you have may have originated from here)?<br class=""> > <br class=""> > best wishes; the snow is adorable!  oe<br class=""> <br class=""> <br class=""> </blockquote></div><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail_signature">Francis Bond <<a href="http://www3.ntu.edu.sg/home/fcbond/" target="_blank" class="">http://www3.ntu.edu.sg/home/fcbond/</a>><br class="">Division of Linguistics and Multilingual Studies<br class="">Nanyang Technological University<br class=""></div> </div></blockquote></div><br class=""></div></div></div></body></html>