[developers] LUI binaries in the main LKB repository

[Woodley Packard]

Hi Stephan,

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.

>From the San Jose airport, where there is a distinct lack of adorable snow,
Woodley

> On Dec 11, 2018, at 6:26 AM, Stephan Oepen <oe at ifi.uio.no> wrote:
> 
> hi again, woodley,
> 
> returning to a thread from a couple of years ago :-).  dan is visiting
> this week, and we are seeking to consolidate things in the LOGON tree
> for premium support of the latest ERG release.  in doing so, we
> re-discovered that the yzlui binaries in LOGON (contributed by you in
> february 2014) actually both are compiled for 32-bit environments.  i
> dimly recall that was a deliberate decision at the time, but today it
> causes dan problems that he used to not be aware of (because he had
> back-dated his yzlui locally to an older 64-bit binary of unknown
> provenance); somewhat curiously, it does not cause me problems,
> apparently because i happen to have the right set of 32-bit
> compatibility libraries installed.
> 
> hence ...
> 
>> 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.
>> 
>> 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?
> 
> yes, indeed.  it is getting increasingly difficult to make users
> install the right set of compatibility libraries, i feel.  and i
> believe we had concluded (in 2014) that yzlui actually had to be
> dynamically linked and that at least several of its shared library
> dependencies could not be bundled with the binary, for proper font and
> unicode support on a specific local system.  does that resonate with
> your memory from those days?
> 
> so, could we take you up on the kind offer to try and cook a 64-bit
> version of yzlui in a suitably rustic linux environment (RHEL6 appears
> to be at glibc version 2.12 today; i suspect the virtual machine image
> you have may have originated from here)?
> 
> best wishes; the snow is adorable!  oe