[tlbuild] asy and OpenGL

Johannes Hielscher jhielscher at posteo.de
Mon Apr 1 22:22:40 CEST 2019


Am Mon, 1 Apr 2019 16:59:01 +0900
schrieb Norbert Preining <preining at logic.at>:

> Hi all,
> 
> again asymptote ...
> 
> There is a problem I see recently, and that is that the OpenGL stuff
> isn't anymore reasonably usable, since libGLEW is changing major API
> version:
> - Debian jessie (old stable):   1.10.0
> - Debian stretch (current stable):      2.0.0
> - Debian buster (soon to be stable):    2.1.0
> 
> I don't know about other distributions etc, but for example the asy
> binary I compiled on jessie does not run on my buster system.
Yes, the new dependencies are problematic. Norbert's binary doesn't
run on Arch Linux unless glew1.10 is installed (fortunately available
from the community repo).
My aarch64-linux binary (stretch, linked against libGLEW.so.2.0)
doesn't run on my SBC (also stretch).

BTW: The official asy binaries from SourceForge suffer from dependency
hell, too /-: (libGLEW.so.2.1 over there)
> 
> I am tempted to ship *two* asy:
> - asy-opengl
> - asy
> and have the asy version do not include the OpenGL libs.
> 
> What do other think?

Until now, I wasn't aware that TL's asy binaries are essentially useless
on headless machines. Particularly now, with so many more OpenGL
dependencies, each bringing their own pace of development.

Often, I am impressed how detail-agnostic the TL core binaries are---but
only due to their modest demands on external libraries. Asymptote is an
exception to this, in these 2.48+ days more than ever.

IMHO this situation eventually exceeds the limits of maintaining
one-fits-all binaries. Rather, we could start off with a
``console-only'' binary w/o OpenGL (This would also relax building on
more problematic platforms).

Those lucky people with the proper library versions could be served with
the traditional ``fat'' asy binaries with --enable-gl (Where to put
documentation on versions?).
Besides DIY build instructions and more aggressive advertising for
native package managers, I see little more to be done from our side.

Can tlmgr treat mutually exclusive packages?

Best,
Johannes


More information about the tlbuild mailing list