lua.pc pkg-config file

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

lua.pc pkg-config file

Taylan Ulrich Bayırlı/Kammer
Hi, I'm a GNU Guix packager and have been bitten a few times by Lua
upstream providing no lua.pc file and yet many programs relying on it
because some popular distributions have a patch in their Lua package to
provide the missing .pc file.  It would be nice to fix the problem at
its root by making Lua provide a .pc file itself.

It seems like the topic was brought up three years ago but the issue
mentioned in http://lua-users.org/lists/lua-l/2012-02/msg00814.html was
never resolved.  I think it should be fairly easy, like adding the
following lines to the 'pc' section in the Makefile:

        @echo "Name: Lua"
        @echo "Cflags: -I${includedir}"
        @echo "Libs: -L${libdir} -llua"

Additionally, making the Makefile write this to $libdir/pkgconfig/lua.pc
automatically during installation would make things more convenient.

I'm shy of providing an actual patch because I'm not a pkg-config expert
but I hope the input helps. :-)

Taylan

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Luiz Henrique de Figueiredo
> adding the following lines to the 'pc' section in the Makefile:
>
> @echo "Name: Lua"
> @echo "Cflags: -I${includedir}"
> @echo "Libs: -L${libdir} -llua"

The last two lines should be
        echo 'Cflags: -I$${includedir}'
        echo 'Libs: -L$${libdir} -llua'

because make expands $ everywhere.

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Tom N Harris
In reply to this post by Taylan Ulrich Bayırlı/Kammer
On Monday, March 23, 2015 11:13:24 AM Taylan Ulrich Bayırlı /Kammer wrote:
> Hi, I'm a GNU Guix packager and have been bitten a few times by Lua
> upstream providing no lua.pc file and yet many programs relying on it
> because some popular distributions have a patch in their Lua package to
> provide the missing .pc file.  It would be nice to fix the problem at
> its root by making Lua provide a .pc file itself.

Your suggestion also falls into the trap of assuming there is only one "Lua"
on a system. There is not and it is dangerous to use "-llua" without a
version.

Actually, from what I understand about Guix, you might be the only platform
that could get away with that because you can present whatever Lua version to
the build environment under the name "lua" and the package manager will take
care of linking to the correct version. I'm not sure the rest of us on lesser
operating systems will appreciate you encouraging unversioned libraries
though.

--
tom <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Ką Mykolas
On 3/24/15, Tom N Harris <[hidden email]> wrote:
> Your suggestion also falls into the trap of assuming there is only one "Lua"
>
> on a system. There is not and it is dangerous to use "-llua" without a
> version.
> --
> tom <[hidden email]>

Wondering if something like Debian alternatives [1] would at least
partly solve this kind of problem or open another one can of worms.
Managing couple versions of Java and leaving system-wide default, but
for couple of applications wasn't fun at all.


[1] https://wiki.debian.org/DebianAlternatives

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Taylan Ulrich Bayırlı/Kammer
In reply to this post by Tom N Harris
Tom N Harris <[hidden email]> writes:

> On Monday, March 23, 2015 11:13:24 AM Taylan Ulrich Bayırlı /Kammer wrote:
>
>> Hi, I'm a GNU Guix packager and have been bitten a few times by Lua
>> upstream providing no lua.pc file and yet many programs relying on it
>> because some popular distributions have a patch in their Lua package
>> to provide the missing .pc file.  It would be nice to fix the problem
>> at its root by making Lua provide a .pc file itself.
>
> Your suggestion also falls into the trap of assuming there is only one
> "Lua" on a system. There is not and it is dangerous to use "-llua"
> without a version.

How about providing one .pc file per version, so pkg-config can be
called with "lua-5.1" and "lua-5.2" and such?  So Lua X.Y installs:

$prefix/lib/lua/X.Y/liblua.a
$prefix/lib/pkgconfig/lua-X.Y.pc

and "pkg-config --libs lua-X.Y" returns the appropriate -L flag.


There could also be a make directive to install a plain lua.pc file
which will point to the version at hand.  So running "make install-pc"
from the build directory of Lua X.Y will install/overwrite:

$prefix/lib/pkgconfig/lua.pc

after which "pkg-config --libs lua" returns the -L flag for Lua X.Y.


If programs are expected to always link against explicit Lua versions,
since you say -llua without a version is dangerous, then scrap the last
idea, and the former is clearly the right way to go I think.

Taylan

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

steve donovan
On Tue, Mar 24, 2015 at 11:46 PM, Taylan Ulrich Bayırlı/Kammer
<[hidden email]> wrote:
> How about providing one .pc file per version, so pkg-config can be
> called with "lua-5.1" and "lua-5.2" and such?  So Lua X.Y installs:

On this Ubuntu machine, I have both Lua 5.1 and 5.2 installed as
Debian packages.

Curiously, there is a lua5.1.pc but not a lua5.2.pc !

But yes, the .pc must be versioned.

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Enrico Tassi
On Wed, Mar 25, 2015 at 08:08:02AM +0200, steve donovan wrote:
> On Tue, Mar 24, 2015 at 11:46 PM, Taylan Ulrich Bayırlı/Kammer
> <[hidden email]> wrote:
> > How about providing one .pc file per version, so pkg-config can be
> > called with "lua-5.1" and "lua-5.2" and such?  So Lua X.Y installs:
>
> On this Ubuntu machine, I have both Lua 5.1 and 5.2 installed as
> Debian packages.
>
> Curiously, there is a lua5.1.pc but not a lua5.2.pc !

Isn't that you don't have liblua5.2-dev installed?
The .pc file is only in the -dev package.

> But yes, the .pc must be versioned.

Absolutely!

Best,
--
Enrico Tassi

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

steve donovan
On Wed, Mar 25, 2015 at 12:07 PM, Enrico Tassi <[hidden email]> wrote:
> Isn't that you don't have liblua5.2-dev installed?
> The .pc file is only in the -dev package.

Ah, thanks Enrico! That explains it.

And (getting back to the topic of Naming Things)  lua5.1.pc, lua5.2.pc
seems like reasonable default names.

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Philipp Janda
Am 25.03.2015 um 11:36 schröbte steve donovan:
> On Wed, Mar 25, 2015 at 12:07 PM, Enrico Tassi <[hidden email]> wrote:
>> Isn't that you don't have liblua5.2-dev installed?
>> The .pc file is only in the -dev package.
>
> Ah, thanks Enrico! That explains it.
>
> And (getting back to the topic of Naming Things)  lua5.1.pc, lua5.2.pc
> seems like reasonable default names.

That ship has sailed. We recently had this discussion on GitHub:
LuaRocks chose `luarocks-5.1`, on Windows `lua52.dll` seems customary
now (for Lua 5.1 LuaBinaries chose `lua5.1.dll` instead), on FreeBSD you
have `/usr/local/include/lua51` (but `lua-5.1` as executable and
pkg-config name), and on Debian/Ubuntu you have the names you mentioned.
And that's only the three OSes I work with ...

Philipp




Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Taylan Ulrich Bayırlı/Kammer
Philipp Janda <[hidden email]> writes:

> Am 25.03.2015 um 11:36 schröbte steve donovan:
>
>> And (getting back to the topic of Naming Things)  lua5.1.pc, lua5.2.pc
>> seems like reasonable default names.
>
> That ship has sailed. We recently had this discussion on GitHub:
> LuaRocks chose `luarocks-5.1`, on Windows `lua52.dll` seems customary
> now (for Lua 5.1 LuaBinaries chose `lua5.1.dll` instead), on FreeBSD
> you have `/usr/local/include/lua51` (but `lua-5.1` as executable and
> pkg-config name), and on Debian/Ubuntu you have the names you
> mentioned. And that's only the three OSes I work with ...

Do new versions have to follow the same naming schemes?  Would it be an
issue if the next Lua release ships e.g. lua-5.3.pc?

Taylan

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Enrico Tassi
In reply to this post by Philipp Janda
On Wed, Mar 25, 2015 at 12:08:05PM +0100, Philipp Janda wrote:
> name), and on Debian/Ubuntu you have the names you mentioned. And that's
> only the three OSes I work with ...

That is not 100% exact, Debian and derivatives name the .pc file as in
lua5.1.pc but also provide convenience symlinks for lua-5.1.pc and
lua51.pc.

The best way out is that the Lua authors fix the spelling, exactly as
they fixed it for the language name (not LUA, but Lua).

Please,
--
Enrico Tassi

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Fontana Nicola
Il Wed, 25 Mar 2015 14:01:58 +0100 Enrico Tassi <[hidden email]> scrisse:

> The best way out is that the Lua authors fix the spelling, exactly as
> they fixed it for the language name (not LUA, but Lua).

I second that. I personally used a variation of this code (courtesy of
AX_LUA [1]):

dnl Some default directories to search.
LUA_SHORT_VERSION=`echo "$LUA_VERSION" | $SED 's|\.||'`
m4_define_default([_AX_LUA_INCLUDE_LIST],
[ /usr/include/lua$LUA_VERSION \
/usr/include/lua-$LUA_VERSION \
/usr/include/lua/$LUA_VERSION \
/usr/include/lua$LUA_SHORT_VERSION \
/usr/local/include/lua$LUA_VERSION \
/usr/local/include/lua-$LUA_VERSION \
/usr/local/include/lua/$LUA_VERSION \
/usr/local/include/lua$LUA_SHORT_VERSION \
])

and I bet there are much more snippets around following this pattern.

An upstream pkg-config that imposes a specific versioning scheme would
resolve this issue.

Ciao.
--
Nicola

[1] https://github.com/peti/autoconf-archive/blob/master/m4/ax_lua.m4#L470

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

William Ahern
On Wed, Mar 25, 2015 at 02:35:07PM +0100, Nicola Fontana wrote:

> Il Wed, 25 Mar 2015 14:01:58 +0100 Enrico Tassi <[hidden email]> scrisse:
>
> > The best way out is that the Lua authors fix the spelling, exactly as
> > they fixed it for the language name (not LUA, but Lua).
>
> I second that. I personally used a variation of this code (courtesy of
> AX_LUA [1]):
>
> dnl Some default directories to search.
> LUA_SHORT_VERSION=`echo "$LUA_VERSION" | $SED 's|\.||'`
> m4_define_default([_AX_LUA_INCLUDE_LIST],
> [ /usr/include/lua$LUA_VERSION \
> /usr/include/lua-$LUA_VERSION \
> /usr/include/lua/$LUA_VERSION \
> /usr/include/lua$LUA_SHORT_VERSION \
> /usr/local/include/lua$LUA_VERSION \
> /usr/local/include/lua-$LUA_VERSION \
> /usr/local/include/lua/$LUA_VERSION \
> /usr/local/include/lua$LUA_SHORT_VERSION \
> ])
>
> and I bet there are much more snippets around following this pattern.

Unfortunately that only handles the easy cases, which are already handled by
pkg-config. But for things like firmwares and other ad hoc installations,
/usr/local is meaningless. Also, none of the above will find the LuaJIT
headers, which are identical to PUC Lua headers from an API perspective.

One of the strategies I use in my luapath script (which automates all of
this using POSIX-portable shell code) is to first locate the appropriate lua
binary in $PATH, using whatever scheme you use to detect the version. If the
lua binary path is LUA, then look for ${LUA}/../include/lua.h and
${LUA}/../include/*/lua.h, and examine them for the correct LUA_VERSION_NUM.
For example, using the POSIX-specied -E flag

  printf "#include <lua.h>\n@@LUA_VERSION_NUM@@\n" \
  | cc -E - -I/include/path/to/test \
  | sed -ne 's/@@\([[:digit:]]*\)@@/\1/p

you can check if LUA_VERSION_NUM exists and what it expands to.

Another strategy I use in luapath is to do `pkg-config --list-all`, grep for
anything that looks like a lua package (including luajit), and then
iteratively test each package name to see if `pkg-config --cflags $NAME`
locates the correct header location.

AX_LUA is nice except that you can only build against a single version of
Lua at a time. If you support multiple Lua versions as a module author, it
becomes _very_ tedious to have to `./configure && make` once for each
version just to make sure your code still compiles after each edit. (And if
you don't check after each edit, it quickly becomes a headache to support
multiple Lua versions, which is why projects which consistently work across
Lua 5.1, 5.2, and 5.3 are so rare.)

> An upstream pkg-config that imposes a specific versioning scheme would
> resolve this issue.
>

It sucks that people are relying on pkg-config so much. If pkg-config is
installed, then you're already on Linux or one of the BSDs (and OS X only
_if_ something like homebrew is already installed), in which case
portability is relatively simple. I just had to hack the OpenDKIM build
because it assumes pkg.m4 already exists, which is only installed with
pkg-config.

pkg-config is useful when it's available. But it's _not_ available in
environments where autotools actually adds value. Why bother using autoconf
and automake, which go to extreme lengths to ship the necessary build
dependencies, and which add tremendous complexity, then have a hard
dependency on something like pkg-config, which would only be available by
default on systems where you wouldn't even need automake to begin with.

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Taylan Ulrich Bayırlı/Kammer
William Ahern <[hidden email]> writes:

> It sucks that people are relying on pkg-config so much. If pkg-config is
> installed, then you're already on Linux or one of the BSDs (and OS X only
> _if_ something like homebrew is already installed), in which case
> portability is relatively simple. I just had to hack the OpenDKIM build
> because it assumes pkg.m4 already exists, which is only installed with
> pkg-config.
>
> pkg-config is useful when it's available. But it's _not_ available in
> environments where autotools actually adds value. Why bother using autoconf
> and automake, which go to extreme lengths to ship the necessary build
> dependencies, and which add tremendous complexity, then have a hard
> dependency on something like pkg-config, which would only be available by
> default on systems where you wouldn't even need automake to begin with.

Shipping .pc files for those who want to use pkg-config does not mean
depending on pkg-config, does it?

Are there any problems with making "make install" put lua-X.Y.pc into
$prefix/lib/pkgconfig/, with the following contents as generated by the
Makefile?

version=$R
prefix=$(INSTALL_TOP)
libdir=$(INSTALL_LIB)
includedir=$(INSTALL_INC)

Name: Lua
Version: $${version}
Libs: -L$${libdir} -llua
Cflags: -I$${includedir}

If that looks OK, I can try to make a patch, though I'm a Makefile noob
and all.

Taylan

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Fontana Nicola
In reply to this post by William Ahern
Il Wed, 25 Mar 2015 16:08:53 -0700 William Ahern <[hidden email]> scrisse:

> It sucks that people are relying on pkg-config so much.

I disagree with almost anything you wrote but on this I disagree more.

pkg-config is just a piece of C code (just like Lua) that makes life
(much) easier to packagers, period. When you are cross-compiling (and
guess what I'm doing right now?) it is not usefull, it is essential!

Every distro I used (archlinux, debian, ubuntu and fedora) provides its
own version of lua*.pc and they will never agree until something is
proposed upstream. And this means, as Taylan correctly specified,
generating and installing a text file.

Ciao.
--
Nicola

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

steve donovan
On Thu, Mar 26, 2015 at 12:24 PM, Nicola Fontana <[hidden email]> wrote:
> pkg-config is just a piece of C code (just like Lua) that makes life
> (much) easier to packagers, period. When you are cross-compiling (and
> guess what I'm doing right now?) it is not usefull, it is essential!

It is an unusually awkward piece of C code:

$ ldd $(which pkg-config)  (taking out linux-specific stuff)
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x00007fa31b16a000)
    libpopt.so.0 => /lib/x86_64-linux-gnu/libpopt.so.0 (0x00007fa31af5e000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fa31a959000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fa31a73b000)

that Glib dependency is the nasty one, a very Gnome-centric thing. To
build pkg-config, you need Glib. To build Glib, you need pkg-config

If you look at the end of 'man pkg-config' you'll see that it has been
re-written a number of times. I suspect that Havoc Pennington was
having too much fun.

I did a very functional clone in 500 lines of C, when testing llib,
with absolutely no dynamic dependencies.  I imagine a smart person
could do a Lua version in about that as well, but do note that the
manual lies about some important things.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Daniel Silverstone
On Thu, Mar 26, 2015 at 16:22:48 +0200, steve donovan wrote:
> that Glib dependency is the nasty one, a very Gnome-centric thing. To
> build pkg-config, you need Glib. To build Glib, you need pkg-config

To be fair to pkg-config -- it embeds enough glib to bootstrap itself.

D.

--
Daniel Silverstone                         http://www.digital-scurf.org/
PGP mail accepted and encouraged.            Key Id: 3CCE BABE 206C 3B69

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Fontana Nicola
In reply to this post by steve donovan
Il Thu, 26 Mar 2015 16:22:48 +0200 steve donovan <[hidden email]> scrisse:

> On Thu, Mar 26, 2015 at 12:24 PM, Nicola Fontana <[hidden email]> wrote:
> > pkg-config is just a piece of C code (just like Lua) that makes life
> > (much) easier to packagers, period. When you are cross-compiling (and
> > guess what I'm doing right now?) it is not usefull, it is essential!
>
> It is an unusually awkward piece of C code:
>
> $ ldd $(which pkg-config)  (taking out linux-specific stuff)
>     libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
> (0x00007fa31b16a000)
>     libpopt.so.0 => /lib/x86_64-linux-gnu/libpopt.so.0 (0x00007fa31af5e000)
>     libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fa31a959000)
>     libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007fa31a73b000)

This is OT but... yes, C code can have dependencies and still be C code.

$ ldd $(command -vp lua)
linux-vdso.so.1 (0x00007ffd9a5fc000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f558a463000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f558a25f000)
libreadline.so.6 => /usr/lib/libreadline.so.6 (0x00007f558a014000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f5589c71000)
/lib64/ld-linux-x86-64.so.2 (0x00007f558a768000)
libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x00007f5589a0c000)

> that Glib dependency is the nasty one, a very Gnome-centric thing.

Although hosted on gnome.org GLib2 is hardly GNOME-centric. Even my
LaTeX distro (together with tons of other non-GNOME applications)
depends on GLib2.

> I did a very functional clone in 500 lines of C, when testing llib,
> with absolutely no dynamic dependencies.  I imagine a smart person
> could do a Lua version in about that as well, but do note that the
> manual lies about some important things.

We are not discussing on the technical merits/demerits of pkg-config,
but on the advantages/disadvantages of including the generation of a
lua.pc file in the official Lua distro.

Ciao.
--
Nicola

Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Enrico Tassi
In reply to this post by Ką Mykolas
On Tue, Mar 24, 2015 at 08:42:34PM +0200, Ką Mykolas wrote:
> On 3/24/15, Tom N Harris <[hidden email]> wrote:
> > Your suggestion also falls into the trap of assuming there is only one "Lua"
> >
> > on a system. There is not and it is dangerous to use "-llua" without a
>
> Wondering if something like Debian alternatives [1] would at least
> partly solve this kind of problem or open another one can of worms.

Debian lets you choose the version of lua and luac using the
alternatives mechanism.
But I think the problem is not about easily switching from one version
of Lua to the other.  The problem is to be able to name a precise Lua
version in a unique and standard way.

Even if we forget about the .pc file, or the -llua linker flag, the very
same issue affects the name of the interpreter!

If I have a Lua script that is written for Lua 5.2 (because I like _ENV
for example), then what do I put in the shebang line? #!lua-5.2 ?  or
#!lua52 ?  Writing there just #!lua is wrong, since the meaning of 'lua'
is "system dependent" and in some Linux distributions I'm not naming
here at some point the version of 'lua' silently switched from 5.1 to
5.2 (breaking working software of course).

Please,
--
Enrico Tassi

PS: giving a policy here can be the exception confirming the rule
that the Lua authors never give a policy


Reply | Threaded
Open this post in threaded view
|

Re: lua.pc pkg-config file

Fontana Nicola
In reply to this post by Taylan Ulrich Bayırlı/Kammer
This is a proof of concept patch that tries to be less intrusive as
possible.

The generated pkg-config includes interpreter, compiler, LMOD and CMOD
paths together with the usual Libs and Cflags items... this should be
everything needed.

Feel free to do whatever you want with that code.

Ciao.
--
Nicola

pkg-config.patch (3K) Download Attachment
12