Hardcoded i686 architecture breaks x86_64 builds

Bug #923161 reported by Jay Carlson
This bug affects 1 person
Affects Status Importance Assigned to Milestone
luarocks (Ubuntu)

Bug Description

...and because luarocks hardcodes an x86_64 workaround for lua.org upstream's non-pic brain damage ("it works on i386!"), the luarocks workaround is undone by luarocks.deb lying to it about the architecture.

The exact bug is present in Debian, except inverted: the architecture is hardcoded to x86_64. I forget, is that "grave"? Should I file there too?

$ luarocks build lpack
gcc -O2 -I/usr/include/lua5.1 -c lpack.c -o lpack.o
gcc -shared -o pack.so -L/usr/local/lib lpack.o
/usr/bin/ld: lpack.o: relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
lpack.o: could not read symbols: Bad value

$ grep fPIC /usr/share/lua/5.1/luarocks/cfg.lua
if proc == "x86_64" and not defaults.variables.CFLAGS:match("-fPIC") then
   defaults.variables.CFLAGS = defaults.variables.CFLAGS.." -fPIC

$ grep UNAME_M /usr/share/lua/5.1/luarocks/config.lua
$ uname -m

$ grep -A 10 proper /usr/share/lua/5.1/luarocks/cfg.lua
-- A proper installation of LuaRocks will hardcode the system
-- and proc values with config.LUAROCKS_UNAME_S and config.LUAROCKS_UNAME_M,
-- so that this detection does not run every time. When it is
-- performed, we use the Unix way to identify the system,
-- even on Windows (assuming UnxUtils or Cygwin).
system = config.LUAROCKS_UNAME_S or io.popen("uname -s"):read("*l")
proc = config.LUAROCKS_UNAME_M or io.popen("uname -m"):read("*l")
if proc:match("i[%d]86") then
   proc = "x86"
elseif proc:match("amd64") or proc:match("x86_64") then
   proc = "x86_64"

$ # So if we simply remove the i686 line from config.lua, luarocks will get the architecture right. Feel free to set it in /etc in postinst instead....

$ # apply attached patch directly to /usr/share/lib/lua5.1 because I'm grumpy

$ luarocks build lpack
Archive: /tmp/luarocks_luarocks-rock-lpack-20070629-1-760/lpack-20070629-1.src.rock
  inflating: lpack-20070629-1.rockspec
 extracting: lpack.tar.gz
Do not use 'module' as a build type. Use 'builtin' instead.
gcc -O2 -fPIC -I/usr/include/lua5.1 -c lpack.c -o lpack.o
gcc -shared -o pack.so -L/usr/local/lib lpack.o
$ # Installation works as well.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: luarocks 2.0.2-1
ProcVersionSignature: Ubuntu 3.0.0-15.26-generic 3.0.13
Uname: Linux 3.0.0-15-generic x86_64
NonfreeKernelModules: fglrx
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Sat Jan 28 16:00:09 2012
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
PackageArchitecture: all
 PATH=(custom, user)
SourcePackage: luarocks
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Jay Carlson (nop-nop) wrote :
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "Let luarocks discover the architecture dynamically, since this is an all-arch package." of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Revision history for this message
Jay Carlson (nop-nop) wrote :

This patch is bogus, or rather the patch needs to be applied at build time, since that's when config.lua is created. 'grep -v'ing out the LUAROCKS_UNAME_M name during build is probably the simplest thing to do.

Revision history for this message
Hiroshi Miura (miurahr) wrote :
Revision history for this message
Hiroshi Miura (miurahr) wrote :

fixed in 2.0.8-1

luarocks (2.0.8-1) unstable; urgency=low

  * Moved from CDBS to dh7
  * Source format 3.0 (quilt)
  * Set debian/compat to 7
  * Bumped standards-version to 3.9.3
  * New upstream release (Closes: #656194)
  * Hardcode lua interpreter to lua5.1 (Closes: #6508660)
  * Probe system at run time calling io.popen('uname') (Closes: #663695)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.