Summary: | =app-text/texlive-core-2014 bundles =dev-lang/lua-5.2.3 app-text/libpaper dev-lang/luajit | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | Current packages | Assignee: | Alexis Ballier <aballier> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bertrand, cruzki123, esigra, itumaykin+gentoo, kingjon3377, lssndrbarbieri, martin, tex |
Priority: | Normal | Keywords: | NeedPatch |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 251464 | ||
Attachments: | app-text:texlive-core-2014:20141104-085727.log |
just fixed libpaper issue; for lua & luajit it's much more difficult: those are not made to be unbundled by upstream and I remember whenever I tried to make luatex use system lua I failed horribly... (In reply to Alexis Ballier from comment #1) > > for lua & luajit it's much more difficult Only judging from the output during compilation, texlive bundles lua-5.2.3, that is, you will probably not have a chance to make it work with lua-5.1.5 (the two versions are largely incompatible). Unfortunately, eselect-lua and lua-5.2.3 are masked since months in portage (and indeed eselect-lua cannot be uesd to switch between lua-5.1.5 and 5.2.3). It seems that lua development in gentoo is stalled... What is needed is probably some wrapper like for python, and a dynamic switch of include directories. I'll have a look at lua/luajit. Making lua/luajit _optional_ would probably be a good first step, especially since luajit doesn't work on most of the architectures texlive-core is keyworded for. If that fixes the bundling along the way, that would be nice too. (In reply to Jeroen Roovers from comment #3) > I'll have a look at lua/luajit. Making lua/luajit _optional_ would probably > be a good first step, especially since luajit doesn't work on most of the > architectures texlive-core is keyworded for. If that fixes the bundling > along the way, that would be nice too. making it optional would be even more difficult: luatex/luajittex is mandatory even for texlive-basic... (grep lua /etc/texmf/fmtutil.d/*) configure: --disable-luajittex do not compile and install LuaJITTeX That should be easy to convert to a USE flag. (In reply to Alexis Ballier from comment #4) > making it optional would be even more difficult: luatex/luajittex is > mandatory even for texlive-basic... (grep lua /etc/texmf/fmtutil.d/*) All use of USE=luajit in the tree says dev-lang/luajit will be used _instead of_ dev-lang/lua, so maybe it's the same here? (In reply to Jeroen Roovers from comment #5) > configure: --disable-luajittex do not compile and install LuaJITTeX > > That should be easy to convert to a USE flag. The problem is not to disable it or not in texlive-core, it is that the rest of texlive still builds and works fine with it disabled. (In reply to Alexis Ballier from comment #7) > The problem is not to disable it or not in texlive-core, it is that the rest > of texlive still builds and works fine with it disabled. Of course. That's why I was talking about luajit and not lua. The problem I'm focusing on right now is whether luajit is _required_. I doubt it, since it normally _replaces_ lua. _KPSE_LIB_FLAGS in m4/kpse-common.m4 seems to support "system" includes and libraries using libtool "[lt]" instead of included includes and libraries "[tree]" so there is hope that changing only kpse-lua52-flags.m4 and kpse-luajit-flags.m4 slightly might be enough. It doesn't solve the other problem with lua5.1/lua5.2 of course. Yes, adding $(use_enable luajit luajittex) does help build on HPPA (with USE=-luajit that is). Should be fixed for _really_ long time. |
Created attachment 388512 [details] app-text:texlive-core-2014:20141104-085727.log I found out because luajit fails on HPPA. :)