Created attachment 304287 [details]
after updating world, a lua update has been installed.
After rebooting, awesome refuses to start with segfault in syslog
awesome: segfault at 1e48 ip 771a661d sp 7f815180 error 4 in liblua.so.5.2.0[7718f000+33000]
After that I was trying to build awesome with this version of lua, and it has failed.
Build log is in attachment
I just had a build failure with gnuplot
after upgrade to lua-5.2.0
After masking lua-5.2.0 and rebuilding the older lua-5.1.4-r8
I rebuilt gnuplot successfully
... just to test if gnuplot is able to build with old lua
@Michael, I didnt want to pirate your bug, but I think this is an all common issue of all consumers of lua-5.2.0.
...perhaps with this new "local libtool" feature?
free to do so.
I'll just this bug duplicate of yours more common (:
I can confirm that x11-wm/awesome-3.4.11 crashes after upgrading to dev-lang/lua-5.2.0. In my case this is on ~amd64.
Yeap, awesome is incompatible with lua-5.2 at the moment and according to upstream it's not a trivial fix (many thanks to psychon for contacting me :)).
I updated the lua dependency to reflect this. Cheers :)
+ 05 Mar 2012; Alex Alexander <email@example.com> awesome-3.4.8.ebuild,
+ awesome-3.4.9.ebuild, awesome-3.4.9-r1.ebuild, awesome-3.4.10.ebuild,
+ awesome doesn't work with lua 5.2, restricted lua dep to 5.1.* - bug #406985
(In reply to comment #5)
> Yeap, awesome is incompatible with lua-5.2 at the moment and according to
> upstream it's not a trivial fix (many thanks to psychon for contacting me
> I updated the lua dependency to reflect this. Cheers :)
This is not legal to introduce this type of up and downgrade cycle to tree into same stabilization level. Be it arch or ~arch. Leave the latest one failing. And it most certainly isn't anykind of fix to this bug, so reopening
The real issue here is with lua breaking ABI without soname change :S
Well, I guess upstreams SONAME not changing is another case of "ops, we changed our minds about when we break ABI". Might be the time to switch lua to a slotted system (at least fixing the up-down-cycles?).
The ABI breakage is a problem, but that upstream has removed essential functions like module() *and* fsetenv() will create problems far beyond the ABI level.
IMHO, most existing Lua source files will have to be modified as well to make them work with 5.2, at least if they implement Lua objects.
The same applies to C extension libraries.
For those reasons, I doubt that a quick fix for this situation is about to come.
Its a bit like the Python-2 to Python-3 migration scenario, and might take just as long to be completed... ;-)
For those of you who do not want to wait and toy around with Lua-5.2 *now* - and without breaking your current system - consider installing my slotted version of Lua-5.2.
It's not a panacea for the whole problem, but it works and allows Lua-5.1 to continue operating undisturbed.
See bug # 414571 for details.
For those of you who want to toy around with the slotted Lua 5.2 mentioned in Comment # 9 but do not want to manually download and install the ebuild, I have placed the ebuild and related files into my private overlay.
You are welcomed to install from it using layman as follows:
$ layman -o http://220.127.116.11/rpo/gentoo/portage/overlays/xworld.xml \
-f -a xworld
$ echo "=dev-lang/lua:5.2" >> /etc/portage/package.unmask
$ echo "~dev-lang/lua-5.2.0" >> /etc/portage/package.keywords
$ emerge -av lua:5.2
Then one should be able to test it, such as the new "goto" feature:
$ lua-5.2 -e 'i=1; ::L:: print(i); i= i + 1; if i < 10 then goto L; end'
Note that "lua" still is the old 5.1 binary, so you have to use a shebang line like
#! /usr/bin/env lua-5.2
in your 5.2 scripts.
For developing C libraries, use pkg-config and provide "lua-5.2" as a package name. ("lua" alone will return the settings for Lua-5.1.)
Upstream has fixed lua-5.2 support in the 3.5 release, now in rc. As such, I'm closing this bug.