autotools and Lua modules

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

autotools and Lua modules

Wesley Smith
Anyone know how to write a Makefile.am in order to generate a .so Lua
module?  Here's what I've got so far:

INCLUDES = -I$(srcdir)/include -I/usr/include/lua5.1
LIBS = -shared

lib_LTLIBRARIES = libtest.la
libtest_la_SOURCES = src/test.cpp


While it does produces the shared library, it's less than desirable.
It builds a libtest.la and a libtest.so.0.0.0 with libtest.so as a
symlink.  Ideally, I'd actually have just test.so, but autotools
complains bitterly since such a name doesn't have "lib" or ".la" in
the name.  I'm wondering if anyone else has tried this.

thanks,
wes
Reply | Threaded
Open this post in threaded view
|

Re: autotools and Lua modules

Luiz Henrique de Figueiredo
> Anyone know how to write a Makefile.am in order to generate a .so Lua
> module?

I'm sorry, I don't know anything about autotools but this works for me
in Linux:

MAKESO= $(CC) -shared

test.so: test.o
        $(MAKESO) -o $@ test.o

In 64-bit Linux platforms, you may need to add -fPIC to CFLAGS.

For Mac OS X I use

MAKESO= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) -bundle -undefined dynamic_lookup

(Perhaps it's time to move to 10.4 :-)
Reply | Threaded
Open this post in threaded view
|

Re: autotools and Lua modules

Peter Drahoš
In reply to this post by Wesley Smith

On Jun 19, 2010, at 1:38 PM, Wesley Smith wrote:

> Anyone know how to write a Makefile.am in order to generate a .so Lua
> module?  Here's what I've got so far:
>
> INCLUDES = -I$(srcdir)/include -I/usr/include/lua5.1
> LIBS = -shared
>
> lib_LTLIBRARIES = libtest.la
> libtest_la_SOURCES = src/test.cpp
>
>
> While it does produces the shared library, it's less than desirable.
> It builds a libtest.la and a libtest.so.0.0.0 with libtest.so as a
> symlink.  Ideally, I'd actually have just test.so, but autotools
> complains bitterly since such a name doesn't have "lib" or ".la" in
> the name.  I'm wondering if anyone else has tried this.
You might also try CMake[1] as alternative to autotools.
This works for most OSes, compilers and architectures.

// Find Lua and set up LUA_ variables
FIND_PACKAGE(Lua51 REQUIRED)
INCLUDE_DIRECTORIES(${LUA_INCLUDE_DIR})

// Build module
ADD_LIBRARY(myModule MODULE mySource.c myOtherSource.c)
TARGET_LINK_LIBRARIES(myModule ${LUA_LIBRARY})

// Remove any prefix from the module such as "lib" or "cyg" depending on platform
SET_TARGET_PROPERTIES(myModule PROPERTIES PREFIX "")

pd

[1] http://www.cmake.org
Reply | Threaded
Open this post in threaded view
|

Re: autotools and Lua modules

Wesley Smith
I know about Cmake.  It doesn't suit my purposes though.  I'm trying
to do things within the standard GNU conventions.  Got some good
advice on the automake list:

AM_CPPFLAGS = -I$(srcdir)/include -I/usr/include/lua5.1

lib_LTLIBRARIES = test.la
test_la_LDFLAGS = -module -avoid-version
test_la_SOURCES = src/test.cpp


-module -avoid-version apparently just generates the final .so I had wanted.

wes
Reply | Threaded
Open this post in threaded view
|

Re: autotools and Lua modules

Aleksey Cheusov
In reply to this post by Wesley Smith
> Anyone know how to write a Makefile.am in order to generate a .so Lua
> module?

Just for your information.

   http://sf.net/projects/mk-configure
   http://mova.org/~cheusov/pub/mk-configure/mkc-presentation.pdf

mk-configure is not Lua-centric.
It is a full-featured replacement for GNU autotools.
Latest version has support for Lua.

==================================================
$  cat Makefile
LUA_CMODULE=    foo

.include <mkc.lib.mk>
==================================================
$  mkcmake
checking for program pkg-config... /usr/pkg/bin/pkg-config
checking for [pkg-config] lua... 1 (yes)
checking for [pkg-config] lua --cflags... -I/usr/pkg/include
checking for [pkg-config] lua --libs... -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -llua -lm
checking for [pkg-config] lua --variable=INSTALL_CMOD... /usr/pkg/lib/lua/5.1
checking for header lua.h... yes
checking for program cc... /usr/bin/cc
cc  -DHAVE_HEADER_LUA_H=1   -I/usr/pkg/include  -c -fPIC -DPIC foo.c -o foo.os
building shared foo library (version )
cc -shared -Wl,-soname -Wl,libfoo.so.1 -o foo.so  foo.os -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -llua -lm
==================================================
$  mkcmake installdirs install DESTDIR=/tmp/fakeroot
for d in _ /tmp/fakeroot/usr/pkg/lib/lua/5.1; do  test "$d" = _ ||
/usr/bin/install -d "$d";  done
/usr/bin/install   -c -o cheusov  -g users -m 644 foo.so
/tmp/fakeroot/usr/pkg/lib/lua/5.1/foo.so
==================================================
$

--
Best regards, Aleksey Cheusov.
Reply | Threaded
Open this post in threaded view
|

Re: autotools and Lua modules

Fidelis Assis-2
In reply to this post by Wesley Smith
2010/6/19 Wesley Smith <[hidden email]>
Anyone know how to write a Makefile.am in order to generate a .so Lua
module?

I wrote the Lua bindings for RRDtool, which uses autotools. It might be a starting point: http://oss.oetiker.ch/rrdtool/download.en.html.

--
Fidelis Assis

Reply | Threaded
Open this post in threaded view
|

Re: autotools and Lua modules

Jay Carlson
In reply to this post by Luiz Henrique de Figueiredo
This is a little off-topic, but it's been driving me crazy for years.

On Sat, Jun 19, 2010 at 8:22 AM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> Anyone know how to write a Makefile.am in order to generate a .so Lua
> module?

I'm sorry, I don't know anything about autotools but this works for me
in Linux:

MAKESO= $(CC) -shared

test.so:        test.o
       $(MAKESO) -o $@ test.o

In 64-bit Linux platforms, you may need to add -fPIC to CFLAGS.

It's not just 64-bit Linux systems; 32-bit Linux platforms other than i386 will probably need position-independent code for dynamic shared objects.

Very few Lua modules will need -fPIC, vice -fpic; on some architectures it's a big performance hit to ask for support for giant GOTs.  The linker will tell you in the unlikely case you have a lot of globally visible symbols in play. 

I wish you'd recommend -fpic on i386 too.  In addition to creating dirty pages and additional work at every load, there are security implications to requiring writable text pages.  Getting away with non-PIC DSOs on i386 is one of those optimizations like -ffast-math one tends to only look at when there's significant, benchmarked differences apparent.

To be fair, lpeg's code is 30k on i386.  For most purposes, adding eight pages of memory pressure is just lost in the noise compared to one GC cycle of a decent-sized Lua app.  So perhaps any memory savings is swamped by the engineering cost of maintaining a more complicated build system.

Jay