recommended sequence to add libtool to an existing configure.ac

[Ed Mansky]

Hi

I am trying to add libtool functionality to an existing configure.ac
script so that the package will have the usual enable shared/static
options and support for threaded libraries, especially pthread.

I am using autoconf 2.69 and automake 1.14 on OSX Darwin 8.11.0 w/gcc
4.3.3 and GNU make 4.0

The reason I am doing this is because the existing configure script
of this package did not find my pthread library in /usr/lib and it
currently makes no use of libtool at all.

I have run other configure scripts that did find my pthread library.

I did the following in sequence:

1) Ran autoscan against the directory tree of the package. I added
the missing macros to the existing configure.ac script that the
autoscan result suggested.

2) Added LT_INIT to configure.ac

3) Ran autoreconf --install

Is this the recommended sequence to add correctly libtool
functionality to an existing configure.ac ?

I thought it would be better to add libtool functionality via the
correct macros to configure.ac, rather than hack at the configure
script directly.

Any tips or ideas would be greatly appreciated.

Thanks,

--Ed

[Eric Blake]

1) Ran autoscan against the directory tree of the package. I added the
missing macros to the existing configure.ac script that the autoscan
result suggested.
2) Added LT_INIT to configure.ac
3) Ran autoreconf --install

Yep, sounds fairly accurate. You may also need to run libtoolize to set
up the framework that libtool needs. You'll probably get better answers
from the libtool list, as this is more of a libtool usage question than
an autoconf question.

I thought it would be better to add libtool functionality via the
correct macros to configure.ac, rather than hack at the configure script
directly.

This part is absolutely true - you don't want to edit the generated
configure file, because those edits would be lost on the next run of
autoreconf.

[Ed Mansky]

Thanks Eric for the quick reply.

Good to know I am following a generally sound track. And yes, I did
run libtoolize and already had added the items in the output.

Another question comes to mind now.

Which of the macros :

AC_CANCAONICAL_SYSTEM

AC_CANONICAL_HOST

AC_CANONICAL_BUILD

AC_CANONICAL_TARGET

should one use in a configure.ac ?

Or should it be SYSTEM --or-- the triplet HOST/BUILD/TARGET ?

The configure.ac I am starting with used SYSTEM alone, and I added
the HOST macro too.

Thanks!

--Ed

Post by Eric Blake

1) Ran autoscan against the directory tree of the package. I added the
missing macros to the existing configure.ac script that the autoscan
result suggested.
2) Added LT_INIT to configure.ac
3) Ran autoreconf --install

Yep, sounds fairly accurate. You may also need to run libtoolize to set
up the framework that libtool needs. You'll probably get better answers
from the libtool list, as this is more of a libtool usage question than
an autoconf question.

I thought it would be better to add libtool functionality via the
correct macros to configure.ac, rather than hack at the configure script
directly.

This part is absolutely true - you don't want to edit the generated
configure file, because those edits would be lost on the next run of
autoreconf.
--
Eric Blake eblake redhat com [phone]
Libvirt virtualization library http://libvirt.org
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
Attachment converted: Macintosh HD:signature 4683.asc ( / ) (001F6C0D)

[Zack Weinberg]

Post by Ed Mansky
AC_CANCAONICAL_SYSTEM
AC_CANONICAL_HOST
AC_CANONICAL_BUILD
AC_CANONICAL_TARGET
should one use in a configure.ac ?

First, all of these are to be avoided: use them only when there's no way to
write a feature test instead.

Then, in most cases where you do need them, you should only need
AC_CANONICAL_HOST. That is the one that detects the identity of the system
your program will run on, which is what you normally care about. _BUILD is
different from _HOST only when your program is being cross compiled, in
which case it tells you the identity of the system where the compiler is
running. You would need to use this only if you need to compile and run
programs *on the build system* in order to build your program (custom code
generators, for instance) *and* those programs themselves contain
system-specific logic. _TARGET is even less often needed: it differs from
_HOST only when you are *building a cross compiler* (or assembler or other
tool chain component), in which case it identifies the system your program
is to generate code for.

_SYSTEM is an obsolete synonym for _HOST, iirc. (or possibly _HOST+_BUILD)

zw

[Ed Mansky]

Thanks Zack, this helps clarify the issue a lot.

--Ed

On Thursday, February 6, 2014, Ed Mansky
AC_CANCAONICAL_SYSTEM
AC_CANONICAL_HOST
AC_CANONICAL_BUILD
AC_CANONICAL_TARGET
should one use in a <http://configure.ac>configure.ac ?
First, all of these are to be avoided: use them only when there's no
way to write a feature test instead.
Then, in most cases where you do need them, you should only need
AC_CANONICAL_HOST. That is the one that detects the identity of the
system your program will run on, which is what you normally care
about. _BUILD is different from _HOST only when your program is
being cross compiled, in which case it tells you the identity of the
system where the compiler is running. You would need to use this
only if you need to compile and run programs *on the build system*
in order to build your program (custom code generators, for
instance) *and* those programs themselves contain system-specific
logic. _TARGET is even less often needed: it differs from _HOST only
when you are *building a cross compiler* (or assembler or other tool
chain component), in which case it identifies the system your
program is to generate code for.
_SYSTEM is an obsolete synonym for _HOST, iirc. (or possibly _HOST+_BUILD)
zw