Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

http://www.lua.org/ftp/lua-5.1.tar.gz

Hi thedcm,

Thanks for the bug report. From looking at the package it seems that the
default lua-5.1 build system only builds static libraries. Many existing
applications in portage expect Lua to havee shared libraries (although you
could work around this by running revdep-rebuild after emergeing lua-5.1).

Lua 5.1's configuration system is also a bit simplistic: what they consider a
'linux' platform does not correspond very well to Gentoo (Gentoo includes a lot
more) and with paths hardcoded in C header files (src/luaconf.h) it's not
particularly easy to use.

Overall, the existing 5.1 build system doesn't play well with Gentoo. So, I can
forsee lua-5.1 going into portage packaged.mask'd so that it's available if
people really want it, but otherwise it won't go in to unstable until the build
system is upgraded. I'm not sure if/when I'll have time to do this.

Regards,

Tom

I created an autotoolized tree of Lua 5.1. It can be obtained from
http://www.digip.org/~akheron/lua-at/lua-at-5.1.tar.gz.

I hope this helps getting Lua 5.1 to Portage. I'll be glad to accept any
suggestions about the package.

By the way, Lua 5.1 is not backwards compatible with Lua 5.0.x. I think this
means it should go to a slot or something?

Created an attachment (id=86242) [details]
bzip2'ed patch to autotoolize Lua 5.1 tree.

Better still, here's a patch. It also has some fixes over the tarball linked in
the last post.

Looks like I *might* look at that autotooled version.  ion-3ds-20060519 from
http://modeemi.fi/~tuomov/ion/logs/ion-3-relnotes.html.gz requires Lua 5.1, and
according to http://www.lua.org/versions.html#5.1 Lua 5.1.1 is now released (so
version bump to Lua 5.1.1 if possible).

I'm not sure which version of Ion I may test.  Starting with 1, then will try 2
or 3 after that.  Currently fairly happy with ratpoison, so time may intercede
and stop me from trying anything.  :(

Any update for this version bump integration ?

Any update for this version bump integration ?

(In reply to comment #5)
> Any update for this version bump integration ?
> 

Well, I patched Lua 5.1.1 with the above 5.1 patch with a standard patch -p1
command, ignored the rejects which just removed files, then built and installed
it into local, unmerged the Gentoo lua so it wouldn't be used, and then built
and installed the latest development ion into local, and uninstalled the Gentoo
ion as well.  In an Xvnc, it ran OK for the few seconds I tested it.  I have no
idea how to stress test it, since I was investigating ion to replace ratpoison,
but didn't like it yet since the default keys are difficult and I simply
haven't had the time to fully test it in the main screen and tailor it.

Now, since I hate autoconf like the plague (it is horrendously slow and
impossible to program with), I naturally used the default "make" commands to
build, never touching ./configure at all.  Is that the point of this
discussion, per chance?  Maybe I missed out completely ... duh.

(In reply to comment #7)

> Now, since I hate autoconf like the plague (it is horrendously slow and
> impossible to program with), I naturally used the default "make" commands to
> build, never touching ./configure at all.  Is that the point of this
> discussion, per chance?  Maybe I missed out completely ... duh.

Ok, so now I'm trying both with ./configure.  I removed the 4 files that were
patch rejects of removing files, and then ran "autoconf", then "./configure
--prefix=/usr/local".  I got a VERY typical autoconf error:

then mv -f ".deps/loadlib.Tpo" ".deps/loadlib.Plo"; else rm -f
".deps/loadlib.Tpo"; exit 1; fi
 gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -g -O2 -MT loadlib.lo -MD -MP -MF
.deps/loadlib.Tpo -c loadlib.c  -fPIC -DPIC -o .libs/loadlib.o
loadlib.c: In function 'luaopen_package':
loadlib.c:646: error: 'LUA_PATH' undeclared (first use in this function)
loadlib.c:646: error: (Each undeclared identifier is reported only once
loadlib.c:646: error: for each function it appears in.)
loadlib.c:647: error: 'LUA_CPATH' undeclared (first use in this function)
make[3]: *** [loadlib.lo] Error 1
make[3]: Leaving directory `/tmp/gentoo/lua-5.1.1/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/gentoo/lua-5.1.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/gentoo/lua-5.1.1'
make: *** [all] Error 2


That's why I hate autoconf.  It makes porting IMPOSSIBLE and compilation the
most abysmally painful thing in the world.  And there's no way to fix it.  If
it's in the source code, that can be fixed, but there's no way to fix autoconf
without reading 1,000,000,000,000 lines of idiotic disorganized shell script.

(In reply to comment #8)
> I removed the 4 files that were
> patch rejects of removing files,

That's not what I meant.  I meant I removed the 4 files the rejected patch
files were trying to remove.

Created an attachment (id=90379) [details]
Quick and dirty lua-5.1.1.ebuild

I'm an ebuild newbie so sorry if I didn't respect the proper way to do it. 
This ebuild
 - does not use 'make install' but 'insinto' + 'doins' to avoid ACCESS DENIED
on mkdir and cp command.
 - use the 'linux' target plateform (don't know if a variable like $PLATEFORM
exist to write a proper switch)

But it worked here on x86. For those who urgely need >=lua5.1 ...

(In reply to comment #10)

It worked perfectly here on x86 too. All my scripts are working fine.
Plus, now the operation 4 % 3 works and gives me a 1, instead of an error. :)

Thanks for the ebuild.

Any progress in getting this into portage?

Created an attachment (id=93110) [details]
lua-5.1.1.ebuild - quick but not so dirty ;)

Here is a modified ebuild. It replaces INSTALL_TOP=.* with
INSTALL_TOP=$(DESTDIR)/usr so einstall works. Diff below:

--- lua-5.1.1.ebuild.orig       2006-07-31 10:07:38.047264000 +0200
+++ lua-5.1.1.ebuild    2006-07-31 10:12:00.268264000 +0200
@@ -20,7 +20,7 @@

        cd ${S}

-       sed -i Makefile -e 's:^\(INSTALL_TOP= \)/usr/local:\1/usr:'
+       sed -i Makefile -e 's:^INSTALL_TOP=.*:INSTALL_TOP= $(DESTDIR)/usr:'
        sed -i doc/readme.html -e 's:\(/README\)\("\):\1.gz\2:g'
 }

@@ -29,17 +29,5 @@
 }

 src_install() {
-       insinto /usr/bin
-       doins src/lua src/luac
-       fperms 0755 /usr/bin/luac /usr/bin/lua
-       insinto /usr/include
-       doins src/lua.h src/luaconf.h src/lualib.h src/lauxlib.h etc/lua.hpp
-       insinto /usr/lib
-       doins src/liblua.a
-
-       dohtml doc/*.html doc/*.gif
-       for i in `find . -name README -printf "%h\n"`; do
-               docinto ${i#.}
-               dodoc ${i}/README
-       done
+       einstall
 }

Created an attachment (id=93113) [details]
Updated ebuild

Sorry, when I tested it I didn't that I emerge 5.0.2 and not my modified 5.1.1
ebuild. While fixing it I also removed the sed line changing the INSTALL_TOP in
the Makefile and use a override instead. I also included the doc from the
original 5.1.1 ebuild.

Tested and works on embedded (uclibc) and amd64. However, as mentioned as
before, it should probably be slotted.

--- lua-5.1.1.ebuild.orig       2006-07-31 10:07:38.047264000 +0200
+++ lua-5.1.1.ebuild    2006-07-31 10:55:37.693540000 +0200
@@ -19,24 +19,15 @@
        unpack ${A}

        cd ${S}
-
-       sed -i Makefile -e 's:^\(INSTALL_TOP= \)/usr/local:\1/usr:'
        sed -i doc/readme.html -e 's:\(/README\)\("\):\1.gz\2:g'
 }

 src_compile() {
-       emake linux
+       emake linux INSTALL_TOP=${D}/usr
 }

 src_install() {
-       insinto /usr/bin
-       doins src/lua src/luac
-       fperms 0755 /usr/bin/luac /usr/bin/lua
-       insinto /usr/include
-       doins src/lua.h src/luaconf.h src/lualib.h src/lauxlib.h etc/lua.hpp
-       insinto /usr/lib
-       doins src/liblua.a
-
+       make install INSTALL_TOP=${D}/usr
        dohtml doc/*.html doc/*.gif
        for i in `find . -name README -printf "%h\n"`; do
                docinto ${i#.}

(In reply to comment #14)
> Created an attachment (id=93113) [edit] [details]
> Updated ebuild

The sed'ing in this ebuild is not enough. LUA_ROOT (and possibly LUA_LDIR and
LUA_CDIR) in luaconf.h must also be modified. They define the default search
paths used by lua module system to find libraries. The default search paths are
under /usr/local/.

I'd also like to see an USE flag for readline support. make linux includes
readline support by default. But after all, this is only a matter of some
sed'ing, too.

Shared libraries are a trickier problem. The default build system has no option
to build shared libraries. My opinion is that shared libraries need not be
built at all, because:
1) The default build system doesn't do it so programs using Lua can't depend on
it
2) The API seems to have backwards incompatible changes between minor versions
(e.g. from 5.0 to 5.1). This means that different versions of Lua must go to
slots anyway.

I'm not going to create another patch to autotoolize Lua 5.1.1 because it
changes the build system dramatically and I think it's not necessary anymore
because the main reason for autotooling was the shared libraries.

I don't have a Gentoo system around right now, so I can't test those ebuilds or
try to modify them to reflect my suggestions, but I would appreciate that if
some of you can.

Petri

Created an attachment (id=96154) [details]
lua-5.1.1-luaconf-paths.patch

The patch is sets LUA_ROOT, LUA_LDIR and LUA_CDIR in luaconf.h. I had a look at
the debian patches and this the way they do it.

I will also follow up and try to provide patches for dynamic linking using
libtool. If Debian can do it then can Gentoo do it too. ;)

I'll try making it slot'able too.

(In reply to comment #16)

> I will also follow up and try to provide patches for dynamic linking using
> libtool. If Debian can do it then can Gentoo do it too. ;)

Are there any updates on your patches, so we can see lua-5.1.1 in portage in
the near future? :)

(In reply to comment #17)
> Are there any updates on your patches, so we can see lua-5.1.1 in portage in
> the near future? :)

It would be great to have a lua ebuild in portage, especially with the new
build of ion3 coming near! I am available to test on amd64 (with both
--march=nocona and --march=athlon64), if someone has enough spare time to
create a new updated build.

Thanks for the work on lua so far!

(In reply to comment #17)
> (In reply to comment #16)
> 
> > I will also follow up and try to provide patches for dynamic linking using
> > libtool. If Debian can do it then can Gentoo do it too. ;)
> 
> Are there any updates on your patches, so we can see lua-5.1.1 in portage in
> the near future? :)

I'm sorry i haven't uploaded anythig yet. Since my local overlay orked just
fine with the static lua, I havent really prioriticed it.

I'm not very experienced with either libtool or slots in gentoo, so I'll tell
you what I'm thiking and are open for input.

I'm thinking of manually merging the patch for debian (see below) to the make
file. It will create the .so files and it will append 5.1 to the binary
(/usr/bin/lua5.1) and to the library (/usr/lib/lua5.1.so) That will let us have
several versions of lua installed in parallell i slots. A lua-config script or
something like that could make links  the desired verision. (/usr/bin/lua ->
/usr/bin/lua5.1)

Thoughts?

--- trunk~/src/Makefile 2006-01-11 18:49:05.000000000 -0500
+++ trunk/src/Makefile  2006-01-22 22:11:48.000000000 -0500
@@ -165,3 +165,29 @@
   ltm.h lzio.h lmem.h lopcodes.h lundump.h

 # (end of Makefile)
+
+# The following rules use libtool for compiling and linking in order to
+# provide shared library support.  While we are at it, our desired version
+# suffixes are added to the targets, preventing conflicts with rules in
+# the upstream makefile.
+
+LIB_NAME = liblua$(V).la
+LIB_OBJS = $(CORE_O:.o=.lo) $(LIB_O:.o=.lo)
+
+%.lo %.o: %.c
+       $(LIBTOOL) --mode=compile $(CC) -c $(CPPFLAGS) $(CFLAGS) $<
+
+$(LIB_NAME) $(LIB_NAME:.la=.a): $(LIB_OBJS)
+       $(LIBTOOL) --mode=link $(CC) -version-info $(LIB_VERSION) \
+            -rpath $(RPATH) -o $(LIB_NAME) $(LIB_OBJS) $(LIB_LIBS)
+
+lua$(V): $(LUA_O) $(LIB_NAME)
+       $(LIBTOOL) --mode=link $(CC) -static -Wl,-E -o $@ $(LUA_O) $(LIB_NAME)
$(LUA_LIBS)
+
+luac$(V): $(LUAC_O) $(LIB_NAME)
+       $(LIBTOOL) --mode=link $(CC) -static -o $@ $(LUAC_O) $(LIB_NAME)
+
+debian_clean:
+       $(LIBTOOL) --mode=clean $(RM) $(ALL_O:.o=.lo) $(LIB_NAME) lua$(V)
luac$(V)
+
+debian_all: $(LIB_NAME) lua$(V) luac$(V)

Why is this needed? Can't we just use the standard, static library?
Slot or mask it so it doesn't clash with those apps requiring a dynamic
library... (I'd be fine with masking.)
I guess that would be easier and bring me lua 5.1 much sooner...

Created an attachment (id=98486) [details]
files/lua-5.1.1-no-readline.patch

patch to remove readline support

Created an attachment (id=98487) [details]
lua-5.1.1.ebuild (update)

Updated ebuild with readline useflag.

I think this ebuild could be commited to the portage tree. If shared library is
really needed, a new bug could be opened. (or it could be proposed upstream)

(In reply to comment #22)

> I think this ebuild could be commited to the portage tree.

Yep, works fine here. :)

Just wondering what we are waiting for here. Are we waiting for me to provide a
shared lib or are we waiting for someone with commit power to do a commit?

I guess we are waiting for somebody with the power to commit the ebuild.
It works fine...

(In reply to comment #25)
> I guess we are waiting for somebody with the power to commit the ebuild.
> It works fine...

It does not work fine. I guess it's missing some pkgconfig stuff. I was unable
to compile lighttpd 1.4.13 against lua-5.1.1 using the three last files from
this bug report. A quick diff against the newest lua from portage tree reveals
that this ebuild does not have at least the following

>       cat >etc/lua.pc <<EOF
> prefix=/usr
> exec_prefix=\${prefix}
> includedir=\${prefix}/include
> libdir=\${exec_prefix}/$(get_libdir)
> interpreter=\${exec_prefix}/bin/lua
> compiler=\${exec_prefix}/bin/luac
>
> Name: Lua
> Description: An extension programming language
> Version: ${PV}
> Cflags: -I\${includedir}
> Libs: -L\${libdir} -llua -llualib -lm $(dlopen_lib)
> EOF
...
>       insinto /usr/$(get_libdir)/pkgconfig
>       doins etc/lua.pc

Maybe fixing those might help.

Since im not the maintainer here i cant give you any straight answers to why
the patch isn't accepted - but the thing is that this ebuild does not build
DSO's (which for instance lighttpd >1.4.12 wants).. and there are probably a
heap of ebuilds which expect DSO's from lua <5.1.
By dissecting the debian patch further (the other stuff in these ebuilds are
practically cut 'n' pastes from that patch) we should have a dso built with not
too much effort.

Just my 2 cents though :)

So, if I am getting all right there won't be an official ebuild for Lua that
builds DSO's? I spent a lot of time to figure out _why_ the devs just retain
DSO's for Linux. After reading some posts in the mailinglist I found two
reasons:
1) creating DSO's with Libtool isn't portable
2) DSO's need an extra register which will slow down the Lua VM

Does it matter? I actually don't care about this register, the VM is fast
enough for me and this is only Linux. I have Libtool and I dislike the idea of
static linking every binary/lib that has Lua support.

(In reply to comment #28)
> So, if I am getting all right there won't be an official ebuild for Lua that
> builds DSO's? I spent a lot of time to figure out _why_ the devs just retain
> DSO's for Linux. After reading some posts in the mailinglist I found two
> reasons:

This is the lua dev's right?

> 1) creating DSO's with Libtool isn't portable
> 2) DSO's need an extra register which will slow down the Lua VM
> 
> Does it matter? I actually don't care about this register, the VM is fast
> enough for me and this is only Linux. I have Libtool and I dislike the idea of
> static linking every binary/lib that has Lua support.

Thanks for the research. The only reason I havent made an DSO's of it yet is
that it's not supported upstream. I have been thinking that if we want/need
dynamic built lua, it should be fixed upstream.

I definitively agree with you that dynamic linking is worth the cost of speed.
We could even have support for the static useflag for those who need the speed.

So what do you say? Should we try maintaining our own libtoolified version of
lua (like debian) or should we just support what upstream provides? I would
like to hear what the gentoo devs thinks before I work more on it.

> This is the lua dev's right?
Of course it is, but I can't agree to their reasons. Their build system creates
DSO's for OS X and Windows, what the heck is the problem to use Libtool on
demand if someone wants it? Actually they replaces the autotool-scripts with a
really frugal makefile.

> I definitively agree with you that dynamic linking is worth the cost of speed.
> We could even have support for the static useflag for those who need the speed.
I doubt that most of the users care about a special useflag or even about
dynamic of static linking. In my opinion it would be a waste of disk space and
really hard to maintain, because you can't be certain which version was built
into the binary/library. And what happens on updates which rely on features of
newer versions of Lua? Automagically revdep?

> So what do you say? Should we try maintaining our own libtoolified version of
> lua (like debian) or should we just support what upstream provides? I would
> like to hear what the gentoo devs thinks before I work more on it.
I would prefer a libtoolized version with DSOs, if it won't be part of upstream
I will keep my overlayed version.

Actually there's another problem with the lack of DSO's: My current project
uses Lua too, that's how I got into this. During tests on different dists I
recognized the great ABI change bewteen 5.0 and 5.1*. It took me some time to
figure out WHY static linking ended in undefined references to all calls of Lua
functions. Later, after some researches again, I read about the required order
of the linker options. I don't know if it was just mistaken by me, but are
further checks of the linker options kind of mandatory for the projects with
Lua support?

(In reply to comment #30)
> > This is the lua dev's right?
> Of course it is, but I can't agree to their reasons. Their build system creates
> DSO's for OS X and Windows, what the heck is the problem to use Libtool on
> demand if someone wants it? Actually they replaces the autotool-scripts with a
> really frugal makefile.

I'll look at it (not today though). If more people ask about it they might
understand.

Another option (for upstream) would be to have current "make linux", just as it
is and just add "make libtool". It wouldnt break compatibility with current,
and it would give the people who needs DSO's that possibility.

> > I definitively agree with you that dynamic linking is worth the cost of speed.
> > We could even have support for the static useflag for those who need the speed.
> I doubt that most of the users care about a special useflag or even about
> dynamic of static linking. In my opinion it would be a waste of disk space and
> really hard to maintain, because you can't be certain which version was built
> into the binary/library. And what happens on updates which rely on features of
> newer versions of Lua? Automagically revdep?
> 
> > So what do you say? Should we try maintaining our own libtoolified version of
> > lua (like debian) or should we just support what upstream provides? I would
> > like to hear what the gentoo devs thinks before I work more on it.
> I would prefer a libtoolized version with DSOs, if it won't be part of upstream
> I will keep my overlayed version.

I think gentoo could maintain it. After all, debian does (so we could copy the
deiban patches). We should still poke the lua dev's again.

> Actually there's another problem with the lack of DSO's: My current project
> uses Lua too, that's how I got into this. During tests on different dists I
> recognized the great ABI change bewteen 5.0 and 5.1*. It took me some time to
> figure out WHY static linking ended in undefined references to all calls of Lua
> functions. Later, after some researches again, I read about the required order
> of the linker options. I don't know if it was just mistaken by me, but are
> further checks of the linker options kind of mandatory for the projects with
> Lua support?

require orer of linker opts? sounds wierd. Since you already have done some
research on it, would you care to send me some links? I'd like to read the
history about why lua build system refuses to support DSO's and try to give it
another try upstream.

(In reply to comment #31)
> Another option (for upstream) would be to have current "make linux", just as it
> is and just add "make libtool". It wouldnt break compatibility with current,
> and it would give the people who needs DSO's that possibility.
> 
There are still discussion on their mailinglists, some suggestions are a target
for DSO's as you said in your prior post. And of course about the different
version numbers and how to name (SONAME) it.

> I think gentoo could maintain it. After all, debian does (so we could copy the
> deiban patches). We should still poke the lua dev's again.
Indeed, most of the dists do it anyway. 

> require orer of linker opts? sounds wierd. Since you already have done some
> research on it, would you care to send me some links? I'd like to read the
> history about why lua build system refuses to support DSO's and try to give it
> another try upstream.
Yes, the object files must be before the link option. Within the autotools I
had to change LDFLAGS to LDADD to get this working.

Well, I don't know if I find this links again..

http://lua-users.org/lists/lua-l/2006-01/msg00663.html
http://lua-users.org/lists/lua-l/2006-01/msg00645.html
http://lua-users.org/lists/lua-l/2006-03/msg00119.html

Hm, I can't find the other post. Maybe later, I will add it here.

This ebuild does not create *.pc file.

-=>> pkg-config --libs --cflags 'lua'
Package lua was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua' found

-=>> pkg-config --libs --cflags 'lua5.1'
Package lua5.1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua5.1' found

While 5.0.3 is OK.

-=>> pkg-config --libs --cflags 'lua'
 -llua -llualib -lm -ldl

(In reply to comment #33)
> This ebuild does not create *.pc file.
The ebuild has no .pc, but the tarballs contains one. Just copy the values
either from the .pc or the ebuild of 5.0.*.

> -=>> pkg-config --libs --cflags 'lua'
>  -llua -llualib -lm -ldl
-lualib is deprecated, Lua 5.1.* is only one lib. Just: -llua -ln -ldl

Created an attachment (id=100980) [details]
lua-5.1.1 ebuild w/ pkg-config

This is the given ebuild plus a few lines in install() that manage the
pkg-config and xpm icon stuff. (taken from 5.0.3 ebuild)

Shouldn't lua be compiled with -fpic on AMD64 so it can be linked to dynamic
libraries?

According to the mailinglist the devs dissuade from using pic. The DSO problem
is still the same as mentioned before.

Can anyone explain what the DSO problem is about?

I'm getting a small (non-critical) error when installing the pkg-config version
(I haven't tested the other ones):

install: cannot stat `etc/lua.xpm': No such file or directory

We might want to fix it before this ebuild goes into portage.

Andre Bogus(In reply to comment #38)
> Can anyone explain what the DSO problem is about?
The devs of Lua complain about the non-portable way of creating shared libs
within makefiles. Within Linux/Unix environments they are mostly created with
libtool which isn't portable at all. Additionately they also bother about the
number of register on ia32. DSOs need one register for reference, so the Lua VM
will be slower.
Actually both aren't obvious reasons for me to get rid of the targets for
Linux/Unix DSOs. Most of the dists build them anyway and the other OS' still
get their DSOs.

* use libtool. Gentoo is a Unix distro, we don't care what upstream cares for.
If you are afraid of addditional work, switch to Debian as upstream source.
Btw. -fPICing is demanded by Gentoo policy.
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1

* lua 5.1.1 seems source incompatible with 5.0.2. ion-20060326 works with 5.0.2
but fails compiling with 5.1.1. You might have to slot lua.

I am not afraid, writing a makefile isn't much work. I just don't get the point
of the developers. PIC is another topic of discussion in the mailinglist.

There was a major ABI change between 5.0.3 and 5.1. I rely on Lua too and had
to set Lua 5.1 as required. Actually I am not sure how the slot mechanism works
with the linker. I know it will prefer shared over static libs. So even when
the newer version doesn't have a DSO?

PIC is demanded by the Gentoo policy, so the library can be shared in memory
among processes. This lowers the memory footprint. If you need the few extra
percent performance, then go and modify your lua-using program to link against
the static version (which will always be non-PIC). But for 98% of the users,
lua is not interesting at all, and a -fPIC shared library is just fine. I guess
that's the rational for the Gentoo policy.

> There was a major ABI change between 5.0.3 and 5.1. I rely on Lua too and had
> to set Lua 5.1 as required. Actually I am not sure how the slot mechanism works
> with the linker. I know it will prefer shared over static libs. So even when
> the newer version doesn't have a DSO?

Linker and the slot mechanism is totally unrelated. Usually slotted packages
use pkg-config (lua does). For instance, glib is slotted, and provides two
package config file, one for "glib" (the old one) and "glib-2.0" the new one,
that when asked for --libs returns the proper linker flags to use glib-2.0.

So for lua, I think there exists a lua-5.1 pc file already. You just have to
make sure that it returns the correct stuff when "pkg-config --libs lua-5.1". 

(In reply to comment #43)
> PIC is demanded by the Gentoo policy, so the library can be shared in memory
> among processes. This lowers the memory footprint. If you need the few extra
> percent performance, then go and modify your lua-using program to link against
> the static version (which will always be non-PIC). But for 98% of the users,
> lua is not interesting at all, and a -fPIC shared library is just fine. I guess
> that's the rational for the Gentoo policy.

That is one of the reasons why there is no ebuild upstream and of course the
incompatibilities of the different versions. Actually I did exact what you
suggested - but I took me a while to figure out why I got many undefined
references. (LDADD vs LDDFLAGS)

> Linker and the slot mechanism is totally unrelated. Usually slotted packages
> use pkg-config (lua does). For instance, glib is slotted, and provides two
> package config file, one for "glib" (the old one) and "glib-2.0" the new one,
> that when asked for --libs returns the proper linker flags to use glib-2.0.
> 
> So for lua, I think there exists a lua-5.1 pc file already. You just have to
> make sure that it returns the correct stuff when "pkg-config --libs lua-5.1". 

Ah for sure. I always use pkg-config, but there is a problem with the different
names. I read some discussions in the Debian mailinglist about this topic.
Prior it was just lua, later lua50, than lua5.1 and finally lua5.1.1. I think
the best workaround is to check the version of the lib with the version reply
of the interpreter and test the common names like the makefile of the latest
ion release does.

I've just committed an lua-5.1.1 ebuild to the tree. I dropped keywords b/c of
the API change. Additionally, due to the quite heavy patching and the open
slotting issue, it's listed in package.mask.
I'd appreciate testing and reports what i broke :)

I'll leave that bug open until it's time for stablization in ~30 days.

(In reply to comment #45)
> I've just committed an lua-5.1.1 ebuild to the tree. I dropped keywords b/c of
> the API change. Additionally, due to the quite heavy patching and the open
> slotting issue, it's listed in package.mask.
> I'd appreciate testing and reports what i broke :)
> 
> I'll leave that bug open until it's time for stablization in ~30 days.
> 

wow! thanks! :D

Could you please add keywords for amd64 and x86?

That's up to the arches (and the reason behind this depending on bug 155518),
so you can all watch progress there.

I just noticed that libtoolified usr/bin/lua-5.1.1 is not linked against liblua
which I kind of expected:

readelf -d /usr/bin/lua-5.1.1 | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libm.so.0]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.0]
 0x00000001 (NEEDED)                     Shared library: [libreadline.so.5]
 0x00000001 (NEEDED)                     Shared library: [libc.so.0]

I noticed because since the overall size increased to the double when I
actually expected it to shrink. (I use lua for size reasons)

Is it correct that LIB_VERSION = 6:1:1 and not LIB_VERSION = 5:1:1 in the
makefile patch?

For the first one: i *knew* i wanted to rip something off debians patches
*gna*, but here's some of the discussion:
http://article.gmane.org/gmane.comp.lang.lua.general/18519
Seems like we won't have luac linked against liblua, as i'm not prepared to rip
all the __attribute__((visibility="hidden")) out of upstreams code.

For the second: yes, that's kind of a hack, since i knew no other way to
produce that .so.5.1.1 :)
Yes it's dumb, and if you know better, please tell me.

I'll add a wrapper to symlink lua[c]-$PV with lua[c] tomorrow, to make this
package usable again. Before i do that however - is a slotted lua a thing worth
having?

Doesn't libtool have this flag (instead of -version-info) to do this kind of
hack internally? (I don't remember the name, though.)

(In reply to comment #50)
> For the first one: i *knew* i wanted to rip something off debians patches
> *gna*, but here's some of the discussion:
> http://article.gmane.org/gmane.comp.lang.lua.general/18519

They say that 150K (for every app linked against lua) is better than losing
15-20% speed. This is generally true, but in embedded this makes difference. I
would like to have a "minimal" use flag that will make it small and sacrifice
the speed for it.

Created an attachment (id=102444) [details]
files/lua-5.1.1-make_dynamic.patch

Patch to link lua dynamically (but not luac). Could be used together with
USE=minimal as showed below.

--- lua-5.1.1.ebuild.orig       2006-11-21 07:22:42 +0000
+++ lua-5.1.1.ebuild    2006-11-21 07:27:57 +0000
@@ -11,7 +11,7 @@
 LICENSE="MIT"
 SLOT="0"
 KEYWORDS="~ppc ~x86"
-IUSE="readline"
+IUSE="minimal readline"

 RDEPEND="readline? ( sys-libs/readline )"
 DEPEND="${RDEPEND}"
@@ -28,6 +28,13 @@
        if ! use readline ; then
                epatch "${FILESDIR}"/${P}-readline.patch
        fi
+
+       # Using dynamic linked lua is not recommended upstream for performance
+       # reasons. http://article.gmane.org/gmane.comp.lang.lua.general/18519
+       # We still allow it for people who care more about size.
+       if use minimal ; then
+               epatch "${FILESDIR}"/${P}-make_dynamic.patch
+       fi
 }

 src_compile() {

Well, it's not just embedded. The speed argument plain doesn't hit arches w/
plenty of GPRs.
So i'll go the other route, add a static useflag for lua and make lua build the
interpreter statically if a user so desires.

Wrapper coming up later today.

Did I get this right? I can now choose whether to compile Lua as a static lib
or not, depending on a USEflag? That's nice, thanks!

Uh well, not yet ;)
I'll think about it. Currently only the lua interpreter is statically linked to
the dynamic library liblua.
Since upstream encourages static librarys too, it would indeed make sense to
build statically here, too.

(In reply to comment #56)
> Uh well, not yet ;)
> I'll think about it. Currently only the lua interpreter is statically linked to
> the dynamic library liblua.
> Since upstream encourages static librarys too, it would indeed make sense to
> build statically here, too.
> 

Thats what I thought too. So by default it would build statically. However, in
some situations you might want to build the interpreter dynamically anyway and
ignore what they recommend upstream. So I was thinking USE=minimal or
USE=dynamic.

The lua compiler (luac) could be built statically anyway to avoid removing the
"__attribute__((visibility("hidden")))" as mentionen in mailing list. It would
be a middle way.

To make my plans more clear:
currently we have a USE="static". This controls whether you like to build lua
(the interpreter) statically (eg linking to liblua.so with -static enabled).
The default now is to build the interpreter dynamically to be more consistent
with Gentoos overall preference of shared objects.
What i'm now thinking about is letting USE="static" control building the
library itself as static. This is an interesting thing, but i've to speak with
twp and the others devs using lua in their ebuilds first, as nobody would like
ion3 failing to build b/c it expects a shared liblua...

Created an attachment (id=105276) [details]
lua-5.1.1 ebuild w/ pkg-config; libdir fixed

I definitly encourage further submissions of ebuild code. But what's the point
of this new ebuild? libdirs already gets set correctly with
RPATH="/usr/$(get_libdir)/" and pkg-config is already installed from upstream
(i'll look into that prefix thing though)

A more interesting point keeps coming up: with all the failures of apps linking
against lua and expecting liblualib to be there (it has vanished upstream, and
there's nothing i can/will do about it), i consider slotting lua so apps would
fall back on lua-5.0* if needed. I'll try to work out details tomorrow.

After bringing lua-5.1.1-r1 (the slotted glory) to the tree, i'm wondering what
will actually benefit from it. I'm currently wading through the list of luas
reverse deps and will remove the slotted lua if nothing really *needs* the old
libs. The hassle of teaching every dep to play nice with the slotted versions
are just not worth it. If i happen to stumble over a genuine dep will not be
solved by upgrading/revbumping, i'll stay on with the slotted builds and put
more work in to bring them to a usable state.

What about amd64? The keyword is still missing. I can test it if you want to.

Created an attachment (id=107879) [details]
unpacking fails with USE=static

Without "static" useflag, compiles, tests, installs & merges successfully on
amd64. I suggest adding ~amd64 keyword.

Created an attachment (id=107888) [details]
modified make_static patch that works with new lua-5.1.1 ebuild

I suggest modified version of make_static patch. Mainly line numbers and patch
context have changed.

Mh, i was sure that i posted to this bug o_O
The issue is 'fallout' from the slotted release, where it uses $(LUA_T) and
$(LUAC_T), which are in fact defined in the original Makefile. I adapted this
style to make it look more like upstreams :)

In any way: should be fixed now.

Ok, waiting for fixed ebuild :)

dev-lang/lua-5.1.1 has been in the tree for a while now, any reason to keep
this bug open?

Other than displaying a lack of progress on lua issues? No ;)