Building C++ modules for python using GNU autotools,automake,whatever

[af30...@gmail.com]

Hi,

I'm a complete neophyte to the whole use of GNU autotools/automake/auto... . (I'm not sure what it should be called anymore.) Regardless, I'm porting a library project, for which I'm a team member, to using this toolset for building in Linux. I'm to the point now of writing the Makefile.am file for the actual library. (There are several other static libraries compiled first that are sucked into this shared object file.)

I found some references here: http://www.gnu.org/savannah-checkouts/gnu/automake/manual/html_node/Python.html, which seemed to be just what I was after. However, I've got a big question about a file named "module.la" instead of "module.so" which is what we compile it to now.

I guess I should have mentioned some background. Currently, we build this tool through some homegrown makefiles. This has worked, but distribution is difficult and our product must now run on an embedded platform (so building it cleanly requires the use of autotools).

Basically, I need this thing to install to /usr/lib/python2.6/site-packages when the user invokes "make install". I thought the variables and primaries discussed at the link above were what I needed. However, what is a "*.la"? I'm reading up on libtool now, but will it function the same way as a *.so?

I need pointers on where to go from here.

Thanks,
Andy

[Jason Swails]

On Thu, 2015-02-26 at 07:57 -0800, af30...@gmail.com wrote:
> Hi,
>
> I'm a complete neophyte to the whole use of GNU
> autotools/automake/auto... . (I'm not sure what it should be called
> anymore.) Regardless, I'm porting a library project, for which I'm a
> team member, to using this toolset for building in Linux. I'm to the
> point now of writing the Makefile.am file for the actual library.
> (There are several other static libraries compiled first that are
> sucked into this shared object file.)
>
> I found some references here:
> http://www.gnu.org/savannah-checkouts/gnu/automake/manual/html_node/Python.html, which seemed to be just what I was after. However, I've got a big question about a file named "module.la" instead of "module.so" which is what we compile it to now.

I certainly hope module.la is not what it gets compiled to. Open it up
with a text editor :). It's just basically a description of the library
that libtool makes use of. In the projects that I build, the .la files
are all associated with a .a archive or a .so (/.dylib for Macs).
Obviously, static archives won't work for Python (and, in particular, I
believe you need to compile all of the objects as position independent
code, so you need to make sure the appropriate PIC flag is given to the
compiler... for g++ that would be -fPIC).

>
> I guess I should have mentioned some background. Currently, we build
> this tool through some homegrown makefiles. This has worked, but
> distribution is difficult and our product must now run on an embedded
> platform (so building it cleanly requires the use of autotools).
>
> Basically, I need this thing to install
> to /usr/lib/python2.6/site-packages when the user invokes "make
> install". I thought the variables and primaries discussed at the link
> above were what I needed. However, what is a "*.la"? I'm reading up
> on libtool now, but will it function the same way as a *.so?

To libtool, yes... provided that you *also* have the .so with the same
base name as the .la. I don't think compilers themselves make any use
of .la files, though.

HTH,
Jason

--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher

[af30...@gmail.com]

On Thursday, February 26, 2015 at 9:35:12 AM UTC-7, Jason Swails wrote:

> On Thu, 2015-02-26 at 07:57 -0800, af300wsm wrote:
> > Hi,
> >
> > I'm a complete neophyte to the whole use of GNU
> > autotools/automake/auto... . (I'm not sure what it should be called
> > anymore.) Regardless, I'm porting a library project, for which I'm a
> > team member, to using this toolset for building in Linux. I'm to the
> > point now of writing the Makefile.am file for the actual library.
> > (There are several other static libraries compiled first that are
> > sucked into this shared object file.)
> >
> > I found some references here:
> > http://www.gnu.org/savannah-checkouts/gnu/automake/manual/html_node/Python.html, which seemed to be just what I was after. However, I've got a big question about a file named "module.la" instead of "module.so" which is what we compile it to now.
>
> I certainly hope module.la is not what it gets compiled to. Open it up
> with a text editor :). It's just basically a description of the library

Fascinating! This is all new territory for me. I'm used these tools for a number of years, of course, as I've run "./configure && make && make install" many times. Now things are starting to make more sense.

> that libtool makes use of. In the projects that I build, the .la files
> are all associated with a .a archive or a .so (/.dylib for Macs).
> Obviously, static archives won't work for Python (and, in particular, I
> believe you need to compile all of the objects as position independent
> code, so you need to make sure the appropriate PIC flag is given to the
> compiler... for g++ that would be -fPIC).

We are compiling all of our code with -fPIC. I looked over the final build line and I see that a module.so was placed in .libs. I looked in that directory and actually the module is named "module.so.0.0.0" and there is a symbolic link "module.so" which points to that. This is cool stuff.


Thanks for the clarification on things.