Re: LUA_CDIR and /usr/lib64
- From: Enrico Tassi <gares@xxxxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Tue, 11 Jun 2013 10:29:35 +0200
On Tue, Jun 11, 2013 at 03:21:14AM +0300, Alek Paunov wrote:
> >Alek Paunov wrote:
> >>
> >>Which is the proper method for replacing /usr/lib with /usr/lib64 in
> >>LUA_CDIR on these systems?
> >
> >Yes, there's no way to do that without patching right now. I've
> >had some discussions with distro maintainers about that issue. But
> >AFAIR there was no consensus on the best way to achieve that.
> >
> >I'm offering to add a MULTIARCH make flag:
> >
> > make PREFIX=/usr MULTIARCH=lib64
>
> Great! - this sounds enough to me, but it is indeed the leading
> maintainers opinion that matters more - Enrico, Craig? (Craig Barnes
> is going to become the Fedora maintainer)
I guess It would be fine. Right now I'm doing something more
complicated, that is becoming the standard practice in Debian,
but that may be a bit overkilling for Lua(jit). I've no strong opinion,
I may as well opt for what Mike proposes, but It you may find interesting
to know this other possibility.
The issue about passing -D flags is that the installed .h files gets
unusable (or morally different) if one compiles a third party software
without passing the same flags that have been passed while compiling
the library.
For Lua/Luajit the problem is minor I guess, since LUA_CPATH_DEFAULT is
not documented, but if one looks at the .h files, it is easy to find.
One could ship the following files on amd64 for the liblua5.1-dev pkg:
/usr/include/x86_64-linux-gnu/lua5.1-deb-multiarch.h
/usr/include/lua5.1/luaconf.h
the former being:
#ifndef _LUA_DEB_MULTIARCH_
#define _LUA_DEB_MULTIARCH_
#define DEB_HOST_MULTIARCH "x86_64-linux-gnu"
#endif
the latter doing:
#include "lua5.1-deb-multiarch.h"
#define LUA_CPATH_DEFAULT ... DEB_HOST_MULTIARCH ...
this makes the -dev package of Lua coisntallable with itself multiple
times. People cross compiling for embedded architectures like that.
apt-get install liblua-5.1-dev:i386 liblua-5.1-dev:amd64
since files in /usr/include/lua5.1/ are the same dpkg does not complain,
while lua5.1-deb-multiarch.h is installed in a multiarched path and
holds a different value.
Toolchains adds the right /usr/include/triplet/ to their include paths.
Morally it is like if one was passing the right -DDEB_HOST_MULTIARCH= to
gcc. Obtaining the same effect using pkg-config (i.e. passing -D) is nearly
impossible due to weird escaping policy in pkg-config.
Note that the value of PREFIX is also hardcoded in the .h, but it is the
same on every architecture so it does not require anything special.
(Yes Mike, I know you don't recommend it, but I'm a bad guy :-).
Again it may be a bit overkillig here... The original syn is to
distribute luaconf.h I guess, but since it is there I'd prefer to have
its #define hold sensible values.
> AFAICT, Python and Node.js both do not specifically append
> /usr/local/... to their paths. For Python, the packager is supposed
> to modify site.py if wants /usr/local in sys.path. OTOH, the compile
> time Perl default is the symmetrical one - /usr/local/lib64/perl5.
> [cut]
> Ideally LOCAL_MULTIARCH should be configurable too, using the 'lib'
> as default (which indeed will cover better the mass case).
>
> If not, IMHO, still broadly inconvenient,
> /usr/local/${MULTIARCH}/... will be a safer choice because: If on a
> system /usr/local/${MULTIARCH}/lua already exists, that probably is
> the right place for the binaries lookup. If not, it may be always
> symlinked to /usr/local/lib/lua (we are under /usr/local).
I keep /usr/local/lib/lua/5.1 inside the package.cpath of the standard
interpreter only for retrocompatibility.
In general it is only a source of confusion so I would avoid adding even
more paths out of the control of the package manager. It may give the
impressions that one should use them.
It is very easy to adjust the value of package.cpath and there is no
hope that the Makefiles of the authors of the various Lua C modules available
in the wild get multiarch right. /usr/local/ should disappear from LSB
in my opinion, i.e. be ignored by default by any software installed in
/usr/. If one wants to mess up his installation, I guess it is fair to
expect he can fix package.cpath and/or export the right LUA_INIT.
Cheers
--
Enrico Tassi
Other related posts:
