shared object and Makefile.am

[Wesley Smith]

Hi,
I'm trying to use autotools to compile shared object Lua modules.  The
way these modules are named differs from the typical .so conventions
because they're not actually libs one links against but are instead
loaded by Lua itself.  For example, a Lua module binding OpenGL would
look like opengl.so instead of libopengl.so.  I've got a Makefile.am
that works for the usual conventions:

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

lib_LTLIBRARIES = libopengl.la
libopengl_la_SOURCES = src/LuaGL.cpp src/LuaGlu.c

but when I do lib_LTLIBRARIES = opengl.so, I get:


$ autoreconf -i
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
opengl/Makefile.am:4: `opengl.so' is not a standard libtool library name
opengl/Makefile.am:4: did you mean `libopengl.la'?
autoreconf: automake failed with exit status: 1

Is there any way around this?  Some kind of option or setting to
ignore these conventions and not throw an error?

thanks,
wes

Re: shared object and Makefile.am

[Wesley Smith]

On Sat, Jun 19, 2010 at 5:50 AM, Ralf Wildenhues  wrote:
> Hello Wesley,
>
> * Wesley Smith wrote on Sat, Jun 19, 2010 at 02:40:53PM CEST:
>> I'm trying to use autotools to compile shared object Lua modules.  The
>> way these modules are named differs from the typical .so conventions
>> because they're not actually libs one links against but are instead
>> loaded by Lua itself.  For example, a Lua module binding OpenGL would
>> look like opengl.so instead of libopengl.so.
>
> Is that true for all systems, even those where the usual shared library
> extension is different, e.g., .sl on HP-UX systems, .dll on w32 ones,
> etc.?

On Windows, it's opengl.dll.  On OSX it's opengl.so as well.  Not sure
about the others.


>
> You can avoid warnings about the 'lib' prefix by making these things
> modules instead of libraries, as in
>  lib_LTLIBRARIES = opengl.la
>  opengl_la_LDFLAGS = -module -avoid-version

Thank you!!

>> INCLUDES = -I$(srcdir)/include -I/usr/include/lua5.1 -I/usr/include/GL
>
> This is ok, but INCLUDES is an old name; use AM_CPPFLAGS instead.

Where is this documented?  I've been looking here:
http://www.gnu.org/software/autoconf/manual/autoconf.html .  There's
not much in the way of what the various Makefile.am conventions are on
this page.  Is there a better reference?

Your suggestions were spot on.  Thanks very much!
wes

Re: shared object and Makefile.am

[Wesley Smith]

Also, one more follow up questions ... how can I have autotools not
put things in the .libs hidden dir but in the source dir itself?

wes

performing pre-build shell commands with automake

[Wesley Smith]

I've been looking through the automake docs trying to figure out how
to execute shell commands as part of the build process but before
anything actually gets compiled.  Is this possible?  I need this for
things like Qt's 'moc' and some other script-based code generation
utilities.  thanks in advance!

wes

Re: performing pre-build shell commands with automake

[Wesley Smith]

> However, that said, the correct way to do what you want is to place a
> make dependency between the sources you want to generate, and the
> consumers of those sources. Automake generates normal makefiles (or
> rather makefile.in templates for Autotconf) from Makefile.am files. Some
> of the code in a Makefile.am file contain directives for automake. The
> rest is just make script that is passed through from Makefile.am to
> (ultimately) Makefile.
>
> Just write rules like this:
>
> consumer.o: resource.qt

Thanks for the info.  I'll give it a shot.
wes

Re: performing pre-build shell commands with automake

[Wesley Smith]

>>
>> consumer.o: resource.qt
>

How does one do this kind of thing when the source file is specified
in a subfolder?
INCLUDES = -I/usr/include/lua5.1 -I/usr/include/cairo
-I/usr/include/directfb -I/usr/include/freetype2

lib_LTLIBRARIES = cairo.la
cairo_la_LDFLAGS = -module -avoid-version
cairo_la_LIBADD = -llua5.1 -L/usr/lib -lcairo -L/usr/lib -ldirectfb
-L/usr/lib -lfreetype -L/usr/lib
cairo_la_SOURCES = src/lcairo.c

resource.qt:
touch TESTING

lcairo.o: resource.qt



lcairo.o never gets triggered here.  If I explicitly do make lcairo.o
then it will get triggered, but I'm not sure from scanning the
Makefile and Makefile.in how it would get implicitly triggered.

wes

Re: performing pre-build shell commands with automake

[Wesley Smith]

I also tried using lcairo.lo, which triggered the preliminary shell
commands but barfed because the commands didn't generate lcairo.lo.
hmm..  Is there a way to print out what rules were invoked during a
make invocation?

wes

On Sun, Jun 20, 2010 at 10:14 PM, Wesley Smith  wrote:
>>>
>>> consumer.o: resource.qt
>>
>
> How does one do this kind of thing when the source file is specified
> in a subfolder?
> INCLUDES = -I/usr/include/lua5.1 -I/usr/include/cairo
> -I/usr/include/directfb -I/usr/include/freetype2
>
> lib_LTLIBRARIES = cairo.la
> cairo_la_LDFLAGS = -module -avoid-version
> cairo_la_LIBADD = -llua5.1 -L/usr/lib -lcairo -L/usr/lib -ldirectfb
> -L/usr/lib -lfreetype -L/usr/lib
> cairo_la_SOURCES = src/lcairo.c
>
> resource.qt:
>        touch TESTING
>
> lcairo.o: resource.qt
>
>
>
> lcairo.o never gets triggered here.  If I explicitly do make lcairo.o
> then it will get triggered, but I'm not sure from scanning the
> Makefile and Makefile.in how it would get implicitly triggered.
>
> wes
>

Re: performing pre-build shell commands with automake

[Wesley Smith]

> Build once without your qt dependencies in place and carefully note the
> name and relative location of the object file generated from
> src/lcairo.c. The qt dependency rule will have to look like this:
>
> exact-name-and-relative-location-of-object : resource.qt
>
> This is the short answer. You might also want to use the $(OBJEXT) macro
> for the extension on the object file for portability's sake:
>
> .../lcairo.$(OBJEXT) : resource.qt


Funny enough, I was actually looking through the printout trying to
set it up properly as you mention.  From the output, lcairo.o should
be the proper rule.  I have the following structure

Makefile.am
Makefile.in
Makefile
src/
lcairo.c



The output looks like:

/bin/bash ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H
-I. -I../.. -I/usr/include/lua5.1 -I/usr/include/cairo
-I/usr/include/directfb -I/usr/include/freetype2 -g -O2 -MT
lcairo.lo -MD -MP -MF .deps/lcairo.Tpo -c -o lcairo.lo `test -f
'src/lcairo.c' || echo './'`src/lcairo.c

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../..
-I/usr/include/lua5.1 -I/usr/include/cairo -I/usr/include/directfb
-I/usr/include/freetype2 -g -O2 -MT lcairo.lo -MD -MP -MF
.deps/lcairo.Tpo -c src/lcairo.c  -fPIC -DPIC -o .libs/lcairo.o

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../..
-I/usr/include/lua5.1 -I/usr/include/cairo -I/usr/include/directfb
-I/usr/include/freetype2 -g -O2 -MT lcairo.lo -MD -MP -MF
.deps/lcairo.Tpo -c src/lcairo.c -o lcairo.o >/dev/null 2>&1

mv -f .deps/lcairo.Tpo .deps/lcairo.Plo

/bin/bash ../../libtool --tag=CC   --mode=link gcc  -g -O2 -module
-avoid-version  -o cairo.la -rpath /usr/local/lib lcairo.lo -llua5.1
-L/usr/lib -lcairo -L/usr/lib -ldirectfb -L/usr/lib -lfreetype
-L/usr/lib  -llua5.1

libtool: link: gcc -shared  .libs/lcairo.o   -L/usr/lib
/usr/lib/libcairo.so -ldirectfb /usr/lib/libfreetype.so
/usr/lib/liblua5.1.so-Wl,-soname -Wl,cairo.so -o .libs/cairo.so

libtool: link: ar cru .libs/cairo.a  lcairo.o
libtool: link: ranlib .libs/cairo.a
libtool: link: ( cd ".libs" && rm -f "cairo.la" && ln -s "../cairo.la"
"cairo.la" )


There are 2 issues I see:
1) Why would the Makefile.am below produce 2 commands compiling the
same source file into 2 different directories?
2) One of those builds commands actually puts lcairo.o in the same
directory as the Makefile, so I would assume that the rule lcairo.o
would correspond to this step.

I also tried .libs/lcairo.o to no avail.



INCLUDES = -I/usr/include/lua5.1 -I/usr/include/cairo
-I/usr/include/directfb -I/usr/include/freetype2

lib_LTLIBRARIES = cairo.la
cairo_la_LDFLAGS = -module -avoid-version
cairo_la_LIBADD = -llua5.1 -L/usr/lib -lcairo -L/usr/lib -ldirectfb
-L/usr/lib -lfreetype -L/usr/lib
cairo_la_SOURCES = src/lcairo.c

Re: performing pre-build shell commands with automake

[Wesley Smith]

>> There are 2 issues I see:
>> 1) Why would the Makefile.am below produce 2 commands compiling the
>> same source file into 2 different directories?
>>
>
> The two libtool commands are not exactly alike. The first command
> generates position-independent code (PIC) to be used in your libtool
> shared library. That's why the object file is placed in the .libs
> directory. The second line doesn't use the -fPIC and -DPIC options. This
> version of the object file is used in the traditional archive (static
> library). The double compile comes from the use of Libtool. However, if
> you don't use Libtool, you'll only get static libraries.

Ah!


>> 2) One of those builds commands actually puts lcairo.o in the same
>> directory as the Makefile, so I would assume that the rule lcairo.o
>> would correspond to this step.
>>
>
> Automake is a little too smart for us here. It won't generate a rule to
> build a libtool object if you've already written one - even if it's only
> a dependency rule (no commands). To fix this, place the dependency on
> the source file, not on the object:
>
> src/lcairo.c : resource.qt
>
> I tested this and it works - here's my test code:

It definitely does work!  Thanks so much.  The QT resources in my case
or code generated files from the actual source files, so it makes
sense to trigger the rules off of the sources themselves.  I really
appreciate the help.

wes

checking for optional dependencies

[Wesley Smith]

I'm looking for some sample code on how to best check for an optional
dependencies (like gstreamer or some other lib) and set a compilation
flag like -DMYLIB_HAVE_GSTREAMER.

I'm not exactly which one of these functions or how to use them to do
this, so any pointers to a sample is much appreciated.
AC_CHECK_LIB
AC_SEARCH_LIBS


wes

determining 32 v. 64 bit compilation

[Wesley Smith]

What's the appropriate way to determine 32 v. 64 bit compilation?
I've looked into using:

AC_CANONICAL_BUILD

with the $build_cpu $build_vendor $build_os variables, but it doesn't
give the right info (in my case i686 pc linux-gnu).  I'm essentially
looking for something in autoconf land equivalent to:

#if defined(__LP64__) || defined(_LP64)
#define OSBIT 64;
#else
#define OSBIT 32;
#endif


thanks in advance!
wes

Re: determining 32 v. 64 bit compilation

[Wesley Smith]

no problem.  I'll take the Q over there.
wes

On Tue, Jun 29, 2010 at 8:06 PM, Stefano Lattarini
 wrote:
> At Tuesday 29 June 2010, Wesley Smith wrote:
>> ... I'm essentially looking for something in autoconf land ...
> I think you should write to the autoconf list (autoc...@gnu.org) for
> general questions regarding autoconf.
>
> Regards,
>    Stefano
>

conditionals in Makefile.am

[Wesley Smith]

> From the automake manual:

You may only test a single variable in an if statement, possibly
negated using ‘!’. The else statement may be omitted. Conditionals may
be nested to any depth. You may specify an argument to else in which
case it must be the negation of the condition used for the current if.
Similarly you may specify the condition that is closed on the endif
line:

 if DEBUG
 DBG = debug
 else !DEBUG
 DBG =
 endif !DEBUG


What's the purpose of "specifying the condition that is closed"?  I've
never seen this kind of construct before.  Is it a substitute for
elseif?

wes

custom install paths

[Wesley Smith]

I've been reading ch12 in the automake manual, trying to make heads or
tails of how to setup a custom install location as a default that can
be overridden by the user.

Here's an example Makefile.am

AM_CPPFLAGS = -I/usr/include/lua5.1 -I/usr/include/cairo
-I/usr/include/directfb -I/usr/include/freetype2

lib_LTLIBRARIES = cairo.la
cairo_la_LDFLAGS = -module -avoid-version
cairo_la_LIBADD = -llua5.1 -L/usr/lib -lcairo -L/usr/lib -ldirectfb
-L/usr/lib -lfreetype -L/usr/lib
cairo_la_SOURCES = src/lcairo.c



On linux (or ubuntu at the very least), modules get installed in
/usr/share/lua/5.1.  What do I need to do in order to have 'make
install' put the resulting binary in that location?

thanks,
wes

Re: custom install paths

[Wesley Smith]

> Surely not given that you're generating the module by compiling code.
> /usr/lib/lua/5.1, perhaps?

Actually you're right.  Egg on my face.  I looked into how other
packages like Lua Socket do it  They put symlinks in /usr/lib/lua/5.1
to the actual compiled libs in /usr/lib.

Here are the Lua Socket install locations:

/usr/lib/liblua5.1-mime.so.2
/usr/lib/liblua5.1-mime.so.2.0.0
/usr/lib/liblua5.1-socket.so.2
/usr/lib/liblua5.1-socket.so.2.0.0
/usr/lib/liblua5.1-unix.so.2
/usr/lib/liblua5.1-unix.so.2.0.0
/usr/lib/lua/5.1/mime/core.so
/usr/lib/lua/5.1/socket/core.so
/usr/lib/lua/5.1/socket/unix.so
/usr/share/doc/liblua5.1-socket2/README
/usr/share/doc/liblua5.1-socket2/changelog.Debian.gz
/usr/share/doc/liblua5.1-socket2/copyright
/usr/share/lua/5.1/ltn12.lua
/usr/share/lua/5.1/mime.lua
/usr/share/lua/5.1/socket.lua
/usr/share/lua/5.1/socket/ftp.lua
/usr/share/lua/5.1/socket/http.lua
/usr/share/lua/5.1/socket/smtp.lua
/usr/share/lua/5.1/socket/tp.lua
/usr/share/lua/5.1/socket/url.lua



/usr/lib/liblua5.1-mime.so.2
/usr/lib/liblua5.1-mime.so.2.0.0
/usr/lib/lua/5.1/mime/core.so

core.so is a symlink to the above libs in /usr/lib.  Hmm..   Thanks
for the info about the install paths.  I just have one more follow up
then.  How do you install the "versioned" .so.2 .so.2.0.0 etc. libs in
one location and the main one, core.so, in another location?

wes

Re: custom install paths

[Wesley Smith]

> luadir = $(LUA_DIR)
> lua_LTLIBRARIES = cairo.la

ok, one more thing.  I understand what's going on with the above code
with *dir matching *_LTLIBRARIES, but before you posted that code, I
had not idea that such things were possible.  In other words, I
thought lib_LTLIBRARIES was a single variable name, not a name broken
up in to parts that are associated with other data by what names their
parts have.

Trying to find some documentation about this, it seems to be scattered
throughout the manual.  I see _LTLIBRARIES in the General Index B, but
nothing about dir.  Any pointers in the docs where I can read more
about how these variables are associated with each other?

thanks,
wes

Re: custom install paths

[Wesley Smith]

> Maybe these can help (please read them in the order given here):
>  
>  
>  
>  

perfect!

build and installation names

[Wesley Smith]

I'm trying to setup a Makefile.am such that the lib and modules I
build get installed in the following way:


/usr/local/lib/liblua5.1-mymodule.so.0.0.0
/usr/local/lib/liblua5.1-mymodule.so.0
/usr/local/lib/lua/5.1/mymodule.so

As a start, I tried to see if I could just build
liblua5.1-mymodule.so.0.0.0.  Here's the Makefile.am:


AM_CPPFLAGS = -I/usr/include/lua5.1 -I/usr/include/cairo
-I/usr/include/directfb -I/usr/include/freetype2
lib_LTLIBRARIES = liblua5.1-cairo.la
liblua5_1_cairo_la_LIBADD = -llua5.1 -L/usr/lib -lcairo -L/usr/lib
-ldirectfb -L/usr/lib -lfreetype -L/usr/lib
liblua5_1_cairo_la_SOURCES = src/lcairo.c


But I end up with this error:


/bin/bash ../../libtool --tag=CC   --mode=link gcc  -g -O2   -o
liblua5.1-cairo.la -rpath /usr/local/lib lcairo.lo -llua5.1 -L/usr/lib
-lcairo -L/usr/lib -ldirectfb -L/usr/lib -lfreetype -L/usr/lib
-lgstapp-0.10 -lgstreamer-0.10 -lcairo -lapr-1 -llua5.1
libtool: link: gcc -shared  .libs/lcairo.o   -Wl,-rpath
-Wl,/home/wesleysmith/Documents/luaav3/modules/cairo/.libs -Wl,-rpath
-Wl,/usr/local/lib/lua/5.1 -L/usr/lib -ldirectfb
/usr/lib/libfreetype.so -lgstapp-0.10 /usr/lib/libgstreamer-0.10.so
/home/wesleysmith/Documents/luaav3/modules/cairo/.libs/libcairo.so
/usr/lib/libapr-1.so /usr/lib/liblua5.1.so-pthread -Wl,-soname
-Wl,liblua5.1-cairo.so.0 -o .libs/liblua5.1-cairo.so.0.0.0
gcc: /home/wesleysmith/Documents/luaav3/modules/cairo/.libs/libcairo.so:
No such file or directory
make[1]: *** [liblua5.1-cairo.la] Error 1



I have a feeling it's because the name of the lib liblua5.1-cairo.la
and how I refer to its target liblua5_1_cairo are messing things up.
How do the characters '.' and '-' get translated into target names?
When I put them in there, I get errors on autoreconf.

thanks,
wes

Re: build and installation names

[Wesley Smith]

Thanks for all the help.  I'll address the paths in later refinements,
but for now, I'd like to understand why the error is happening in this
particular instance.


> I'm not quite sure what you mean with this.  Can you give an example?
> Or do you mean the translation from
>  lib_LTLIBRARIES = libxy-.z.la
> to
>  libxy__z_la_SOURCES = ...
>
> ?  That is documented in 'info Automake Canonicalization'.

Yes, thank you.  canonicalization is exactly what I was talking about.
 In my current Makefile.am:

AM_CPPFLAGS = -I/usr/include/lua5.1 -I/usr/include/cairo
-I/usr/include/directfb -I/usr/include/freetype2
lib_LTLIBRARIES = liblua5.1-cairo.la
liblua5_1_cairo_la_LIBADD = -llua5.1 -L/usr/lib -lcairo -L/usr/lib
-ldirectfb -L/usr/lib -lfreetype -L/usr/lib
liblua5_1_cairo_la_SOURCES = src/lcairo.c

Leads to:
/bin/bash ../../libtool --tag=CC   --mode=link gcc  -g -O2   -o
liblua5.1-cairo.la -rpath /usr/local/lib lcairo.lo -llua5.1 -L/usr/lib
-lcairo -L/usr/lib -ldirectfb -L/usr/lib -lfreetype -L/usr/lib
-lgstapp-0.10 -lgstreamer-0.10 -lcairo -lapr-1 -llua5.1
libtool: link: gcc -shared  .libs/lcairo.o   -Wl,-rpath
-Wl,/home/wesleysmith/Documents/luaav3/modules/cairo/.libs -Wl,-rpath
-Wl,/usr/local/lib/lua/5.1 -L/usr/lib -ldirectfb
/usr/lib/libfreetype.so -lgstapp-0.10 /usr/lib/libgstreamer-0.10.so
/home/wesleysmith/Documents/luaav3/modules/cairo/.libs/libcairo.so
/usr/lib/libapr-1.so /usr/lib/liblua5.1.so-pthread -Wl,-soname
-Wl,liblua5.1-cairo.so.0 -o .libs/liblua5.1-cairo.so.0.0.0


It's for some reason looking for
/home/wesleysmith/Documents/luaav3/modules/cairo/.libs/libcairo.so,
which doesn't make sense.  Firstly, this file doesn't exist, and I'm
not building it in my build process.  Instead, I'm trying to use it to
build a Lua module called liblua5.1-cairo.la.  Is there anything in
the above Makefile.am that would generate such a path?

wes