[ST-devel] packaging libst: autoconf and libtool

[Wesley W. T. <we...@io...>]

Heya! 

I've been looking into packaging libst as a .deb and .rpm. I have versions
that work on linux, but they assume that libtool is installed and that it
should use -DLINUX.

For it to build properly on any target platform, I need to make a configure
script that will detect those settings that libst needs. Right now, the
system of 'make arch' really doesn't cut it for cross-platform packaging.

Has anyone already looked into making an autoconf configure script?
From what I can tell, the only things that would need to be detected are:
USE_POLL
MD_ALWAYS_UNSERIALIZED_ACCEPT
MD_STACK_GROWS_DOWN/UP
MD_ACCEPT_NB_(NOT_)INHERITED
MALLOC_STACK
MD_USE_SYSV_ANON_MMAP
MD_GET_UTIME
MD_USE_SYSV_ANON_MMAP
and the presence of a few headers. This is certainly doable by autoconf, but
I have no desire to duplicate someone else's work. :-)

If anyone has already written portable tests for the context switching
MD_STACK_GROWS_DOWN/UP, MALLOC_STACK, and MD_ACCEPT_NB_(NOT_)INHERITED
stuff, I'd love to have them. The rest I'm sure I'll get right, but the ones
above I have no way to test on all the target platforms.

The way I figure autoconf should approach the issue is to try various
context switching mechanisms in order of which is faster and select the
first which works. Detect whether poll or anonymous mmap are available, etc
and then output a config.h with the appropriate defines. In this manner, it
will work on any platform which provides some combination of the necessary
features.

The ia64 code -- what is it for? Is it faster than the setjmp/longjmp
technique? Or is setjmp/longjmp not available on this platform? (I am not
familiar with the ia64)

Also, the method used to build linux libraries presently employed is
actually incorrect... You should compile the shared objects with -fPIC -FPIC
and when linking specify the soname of the output library. Otherwise the
library will not be relocatable, and programs will link to libst.so instead
of libst.so.1 as they should.

To correct this, in my debian packaging of the project I have it use libtool
to compile the project. Libtool is very good at determining the correct
options to use for compiling on a target platform. It knows more than any
single developer I've met. :-)

However, if I do make a patch which uses libtool and autoconf, the tar.gz
and build time will be significantly increased. I'm not sure whether
download size / build time is a goal of the project? It won't increase the
compiled size of the library -- just the source tar.gz.

It would likely be 180k instead of 70k. This is because typically libtool
and autoconf are included in the source tar.gz so that if the user doesn't
have them, the build still works. The other alternative is to require the
user to have these packages installed in which case there will be almost no
size impact.

Further, libtool does and configure will end up doing a lot of tests that
take some time. Perhaps it's overkill given the size of the project, but it
is how most OS projects deal with it. :-)

Finally, do you have access to the platforms on which this presently builds?
If I do get it working with autoconf/libtool it would be nice if I could
test it on all the platforms it worked on before.

One last thing -- the program 'sox' has a /usr/lib/libst.a in it already
which conflicts with the obvious installed library name. Not sure what to do
about this. Maybe ask them to rename their supporting lib? ;-)

Thanks! I want to contribute to this project (which I love using), but I
don't know who's involved and what's been done in the direction of packaging
it already, etc.

PS. I'm out in the middle of nowhere using a modem for Christmas so my email
response times will be a bit longer than normal.

-- 
Wesley W. Terpstra <we...@te...>