Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 49309 - Can't link Lua apps with lualib due to missing loadlib dependency
Summary: Can't link Lua apps with lualib due to missing loadlib dependency
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Tom Payne (RETIRED)
URL:
Whiteboard:
Keywords:
: 59487 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-04-28 11:40 UTC by yagu
Modified: 2005-07-27 22:13 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch against the current lua ebuild for developer reference. (lua-5.0.2-r1.ebuild.patch,1.60 KB, patch)
2005-03-23 15:07 UTC, Francisco José Cañizares Santofimia
Details | Diff
New patch against the current lua ebuild for developer reference. (lua-5.0.2-r1.ebuild.patch,2.34 KB, patch)
2005-03-23 15:14 UTC, Francisco José Cañizares Santofimia
Details | Diff
Lua ebuild changed to -r2 just for user reference. (lua-5.0.2-r2.ebuild,2.90 KB, text/plain)
2005-03-23 15:16 UTC, Francisco José Cañizares Santofimia
Details
Lua ebuild changed to -r2 just for user reference (again). (lua-5.0.2-r2.ebuild,2.92 KB, text/plain)
2005-03-23 17:25 UTC, Francisco José Cañizares Santofimia
Details
New patch against the current lua ebuild for developer reference. (again) (lua-5.0.2-r1.ebuild.patch,2.37 KB, patch)
2005-03-23 17:26 UTC, Francisco José Cañizares Santofimia
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description yagu 2004-04-28 11:40:16 UTC
This would appear to be related to Bug #36797.  When I attempt to link a Lua app
against lualib, I get several undefined reference errors to "dlerror", "dlclose",
etc.

Interestingly, if I also link against SDL, it works.

Reproducible: Always
Steps to Reproduce:
1.  Write a simple Lua app:

extern "C"
{
#include "lua.h"
#include "lualib.h"
}

int main()
{
    lua_State* state = lua_open();
    lua_close(state);
    return 0;
}


2.  Compile it, linking against lualib: 
    $ g++ -g -o lua lua.cpp -llua -llualib

Actual Results:  
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../liblualib.so: undefined
reference to `dlerror'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../liblualib.so: undefined
reference to `dlclose'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../liblualib.so: undefined
reference to `dlopen'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../liblualib.so: undefined
reference to `dlsym'
collect2: ld returned 1 exit status

Expected Results:  
A working executable.

As I mentioned, the following works fine:
   $ g++ -g -o lua lua.cpp -lSDL -llua -llualib

I'm using lua-5.0.2, gcc 3.3.2, and sdl 1.2.6-r3

Thanks.
Comment 1 Tom Payne (RETIRED) gentoo-dev 2004-05-08 11:39:25 UTC
OK, I'm looking into this.

The work-around is to add -ldl to to the libs when linking. It works with SDL because SDL itself pulls in -ldl. For some reason -ldl is not being pulled in automatically when you specifiy -llua.
Comment 2 Tom Payne (RETIRED) gentoo-dev 2004-05-09 07:14:08 UTC
BTW, recent versions of the lua ebuild include a pkg-config script so you can use

g++ -g -o lua lua.cpp `pkg-config lua --libs`

to automatically pull in the correct libraries.
Comment 3 yagu 2004-05-10 20:41:47 UTC
Thanks, Tom.

These workarounds suit my needs.
Comment 4 Mr. Bones. (RETIRED) gentoo-dev 2004-05-12 01:24:25 UTC
Might be interesting to see what debian, suse and fedora do about this.
Bet there's a patch to the lua build we should be using.
Comment 5 Tom Payne (RETIRED) gentoo-dev 2004-05-15 02:11:57 UTC
You're right. This looks promising:

http://ftp.debian.org/debian/pool/main/l/lua50/lua50_5.0.2-1.diff.gz

It uses gcc rather than ld to link, which I suspect will do the trick. Will test&apply this weekend.
Comment 6 Glenn Maynard 2004-06-04 13:25:36 UTC
All dynamic libraries should link against their dependencies.  That way, you aren't forced to use -config scripts (which are annoying and normally unnecessary), and you don't have to track library dependencies yourself.

A recent Debian update to lua50 (5.0.2-2) lists in the changelog:

  * Update the link line for liblualib50.so so that it gets -ldl too

which is the "correct" fix for this problem.  The result is that "-llualib50" works, without any further hoop-jumping (which is how ELF shared libraries are supposed to work).

The change from the diff linked earlier is:

# shared libraries (for Linux)
so:
...
        gcc -o lib/liblualib50.so.$V -shared -Wl,-soname,liblualib50.so.$V \
               src/lib/*.os -Llib -llua-build50 -lm -ldl -lc

Note the addition of "-ldl".  Again, this should *not* be done to liblua50; only liblualib50.
Comment 7 Tom Payne (RETIRED) gentoo-dev 2004-08-05 13:52:07 UTC
*** Bug 59487 has been marked as a duplicate of this bug. ***
Comment 8 Tom Payne (RETIRED) gentoo-dev 2004-08-05 13:52:52 UTC
lua-5.0.2-r1 is now in the tree and hopefully fixes these problems.

Please test and report success/failure back here.

Thanks,

Tom
Comment 9 Mathieu Pillard 2004-08-15 13:28:15 UTC
Doesn't work well for me:

mkdir -p /var/tmp/portage/lua-5.0.2-r1/image//usr/bin /var/tmp/portage/lua-5.0.2-r1/image//usr/include /var/tmp/portage/lua-5.0.2-r1/image//usr/lib /var/tmp/portage/lua-5.0.2-r1/image//usr/share/man/man1
cp bin/* /var/tmp/portage/lua-5.0.2-r1/image//usr/bin
cp include/*.h /var/tmp/portage/lua-5.0.2-r1/image//usr/include
cp lib/*.a /var/tmp/portage/lua-5.0.2-r1/image//usr/lib
cp doc/*.1 /var/tmp/portage/lua-5.0.2-r1/image//usr/share/man/man1
cp lib/*.so.* /var/tmp/portage/lua-5.0.2-r1/image//usr/lib
cp: cannot stat `lib/*.so.*': No such file or directory
make: *** [soinstall] Error 1

!!! ERROR: dev-lang/lua-5.0.2-r1 failed.
!!! Function src_install, Line 65, Exitcode 2
!!! (no error message)

Full log is here: http://mat.virgule.info/temp/emerge.lua.log
Comment 10 Francisco José Cañizares Santofimia 2005-03-23 15:07:46 UTC
Created attachment 54279 [details, diff]
Patch against the current lua ebuild for developer reference.
Comment 11 Francisco José Cañizares Santofimia 2005-03-23 15:13:28 UTC
Comment on attachment 54279 [details, diff]
Patch against the current lua ebuild for developer reference.

--- lua-5.0.2-r1.ebuild.old	2005-03-24 00:07:22.000000000 +0100
+++ lua-5.0.2-r1.ebuild 2005-03-24 00:12:12.000000000 +0100
@@ -10,7 +10,7 @@

 LICENSE="MIT"
 SLOT="0"
-KEYWORDS="~alpha -hppa ~mips ~ppc ~sparc ~x86 ~amd64"
+KEYWORDS="~alpha -hppa ~mips ~ppc ~sparc ~x86 ~amd64 ~ppc-macos"
 IUSE="readline"

 DEPEND=">=sys-apps/sed-4
@@ -20,17 +20,28 @@
	unpack ${A}

	epatch ${FILESDIR}/lua-${PV}-gentoo.patch
+	use ppc-macos && epatch ${FILESDIR}/lua-ppc-macos-Makefile.patch

	cd ${S}

-	sed -i config \
-		-e 's:^#\(LOADLIB= -DUSE_DLOPEN=1\):\1:' \
-		-e 's:^#\(DLLIB= -ldl\):\1:' \
-		-e 's:^#\(MYLDFLAGS= -Wl,-E\):\1:' \
-		-e 's:^#\(POPEN= -DUSE_POPEN=1\)$:\1:' \
-		-e "s:^\(MYCFLAGS= \)-O2:\1${CFLAGS} -fPIC -DPIC:" \
-		-e 's:^\(INSTALL_ROOT= \)/usr/local:\1$(DESTDIR)/usr:' \
-		-e 's:^\(INSTALL_MAN=
$(INSTALL_ROOT)\)/man/man1:\1/share/man/man1:'
+	if ! use ppc-macos; then
+		sed -i config \
+			-e 's:^#\(LOADLIB= -DUSE_DLOPEN=1\):\1:' \
+			-e 's:^#\(DLLIB= -ldl\):\1:' \
+			-e 's:^#\(MYLDFLAGS= -Wl,-E\):\1:' \
+			-e 's:^#\(POPEN= -DUSE_POPEN=1\)$:\1:' \
+			-e "s:^\(MYCFLAGS= \)-O2:\1${CFLAGS}:" \
+			-e 's:^\(INSTALL_ROOT= \)/usr/local:\1$(DESTDIR)/usr:'
\
+			-e 's:^\(INSTALL_MAN=
$(INSTALL_ROOT)\)/man/man1:\1/share/man/man1:'
+	else
+		sed -i config \
+			-e 's:^#\(LOADLIB= -DUSE_DLOPEN=1\):\1:' \
+			-e 's:^#\(DLLIB= -ldl\):\1:' \
+			-e 's:^#\(POPEN= -DUSE_POPEN=1\)$:\1:' \
+			-e "s:^\(MYCFLAGS= \)-O2:\1${CFLAGS}:" \
+			-e 's:^\(INSTALL_ROOT= \)/usr/local:\1/usr:' \
+			-e 's:^\(INSTALL_MAN=
$(INSTALL_ROOT)\)/man/man1:\1/share/man/man1:'
+	fi

	sed -i doc/readme.html \
		-e 's:\(/README\)\("\):\1.gz\2:g'
@@ -58,11 +69,25 @@
 }

 src_compile() {
-	emake
+	export PICFLAGS=-fPIC
+	emake || die emake failed
+
+	 if use ppc-macos; then
+		 # OSX does not have so files.
+		 emake dylib dylibbin || die "emake dylib failed"
+	 else
+		 emake so || die "emake so failed"
+	 fi
+
 }

 src_install() {
-	make DESTDIR=${D} install soinstall || die
+	if use ppc-macos; then
+		 # OSX does not have so files.
+		 make DESTDIR=${D} install dylibinstall || die "make install   
 dylibinstall failed"
+	 else
+		 make DESTDIR=${D} install soinstall || die "make install
soinstall failed"
+	 fi

	dodoc HISTORY UPDATE
	dohtml doc/*.html doc/*.gif
Comment 12 Francisco José Cañizares Santofimia 2005-03-23 15:14:55 UTC
Created attachment 54281 [details, diff]
New patch against the current lua ebuild for developer reference.
Comment 13 Francisco José Cañizares Santofimia 2005-03-23 15:16:28 UTC
Created attachment 54282 [details]
Lua ebuild changed to -r2 just for user reference.
Comment 14 Francisco José Cañizares Santofimia 2005-03-23 15:22:26 UTC
First of all, sorry for comment #13, I touched the worng button.
Then, explanation of this:
First, I have had the same issue as comment #9
Then, the patch is agains the current -r1 and is provided here for user reference, and the ebuild called -r2 it's for users as is easy to use.

How was that the package did not compiled?
Easy, the developer that made the -r1 ebuild, "accidentally" deleted the macos keywording and in src_compile() deleted the emake so needed for other platforms different than macos, so didn't compile the lib, and thus, the package does not install.
This is, you need to *unmask* the ebuild as soon as you can.
Please not I've also added ppc-macos. 
I'm not sure if it compiles, because I haven't got that arch and hasn't been able to find one that haves it, but I see not reasons for it to compile (well, I see one as it's applied a different patch in -r1).
Comment 15 Francisco José Cañizares Santofimia 2005-03-23 17:25:09 UTC
Created attachment 54291 [details]
Lua ebuild changed to -r2 just for user reference (again).
Comment 16 Francisco José Cañizares Santofimia 2005-03-23 17:26:24 UTC
Created attachment 54292 [details, diff]
New patch against the current lua ebuild for developer reference. (again)
Comment 17 Lina Pezzella (RETIRED) gentoo-dev 2005-03-23 18:41:58 UTC
I have already fixed the error described in Comment #9 (about 2-3 days ago). It is in CVS, so if you re-emerge lua (r1), that should fix that problem.

Tom: I'm not sure if you've already put that functionality into r2 or not. Last time I looked, I believe r2
was package masked. Please correct me if I'm wrong and either you or I can merge those changes into r2 (either way is fine by me).
Comment 18 Francisco José Cañizares Santofimia 2005-03-23 19:07:46 UTC
Nope, Lina.
In fact changes in CVS were to 5.0.2.
-r1 ebuild dates from 6 weeks.
Comment 19 Lina Pezzella (RETIRED) gentoo-dev 2005-03-23 19:37:04 UTC
Teaches me to check before commenting. You are correct. It is -r1 that is package.masked, so I made
my modifications to the latest unmasked package, which happens to be 5.0.2.

I try not to make changes to another developer's package.masked stuff. My reasoning is that it's 
package.masked because the developer isn't done messing with it yet (or upstream) and in that case
 any changes I were to make might not work in the final version of that ebuild (or source tarball in the case of patches).

The bug from Comment #9 is fixed in the 5.0.2 ebuild. Sorry for the confusion.
Comment 20 Francisco José Cañizares Santofimia 2005-03-23 19:45:15 UTC
Ok, thanks for clearing things :-)
We should to wait Tom's opinion :-)
Comment 21 Lina Pezzella (RETIRED) gentoo-dev 2005-07-27 22:13:16 UTC
Since I haven't heard back from the maintainer, I took the liberty of porting the patch from the 5.0.2 
version to the 5.0.2-r1 version. It should not affect any other arch than ppc-macos.

Closing out this bug since that fix is in CVS. I've verified that the example code here compiles. 
Unfortunately I don't know enough about lua to do much more than that, but that should be more than 
okay for testing purposes.