libtool: Porting inter-library dependencies
1
1 15.1.2 Porting inter-library dependencies support
1 -------------------------------------------------
1
1 Since version 1.2c, libtool has re-introduced the ability to do
1 inter-library dependency on some platforms, thanks to a patch by Toshio
1 Kuratomi <badger@prtr-13.ucsc.edu>. Here's a shortened version of the
1 message that contained his patch:
1
1 The basic architecture is this: in 'libtool.m4', the person who
1 writes libtool makes sure '$deplibs' is included in '$archive_cmds'
1 somewhere and also sets the variable '$deplibs_check_method', and maybe
1 '$file_magic_cmd' when 'deplibs_check_method' is file_magic.
1
1 'deplibs_check_method' can be one of five things:
1 'file_magic [REGEX]'
1 looks in the library link path for libraries that have the right
1 libname. Then it runs '$file_magic_cmd' on the library and checks
1 for a match against the extended regular expression REGEX. When
1 'file_magic_test_file' is set by 'libtool.m4', it is used as an
1 argument to '$file_magic_cmd' to verify whether the regular
1 expression matches its output, and warn the user otherwise.
1
1 'test_compile'
1 just checks whether it is possible to link a program out of a list
1 of libraries, and checks which of those are listed in the output of
1 'ldd'. It is currently unused, and will probably be dropped in the
1 future.
1
1 'pass_all'
1 will pass everything without any checking. This may work on
1 platforms where code is position-independent by default and
1 inter-library dependencies are properly supported by the dynamic
1 linker, for example, on DEC OSF/1 3 and 4.
1
1 'none'
1 It causes deplibs to be reassigned 'deplibs=""'. That way
1 'archive_cmds' can contain deplibs on all platforms, but not have
1 deplibs used unless needed.
1
1 'unknown'
1 is the default for all systems unless overridden in 'libtool.m4'.
1 It is the same as 'none', but it documents that we really don't
1 know what the correct value should be, and we welcome patches that
1 improve it.
1
1 Then in 'ltmain.in' we have the real workhorse: a little
1 initialization and postprocessing (to setup/release variables for use
1 with eval echo libname_spec etc.) and a case statement that decides the
1 method that is being used. This is the real code... I wish I could
1 condense it a little more, but I don't think I can without function
1 calls. I've mostly optimized it (moved things out of loops, etc.) but
1 there is probably some fat left. I thought I should stop while I was
1 ahead, work on whatever bugs you discover, etc. before thinking about
1 more than obvious optimizations.
1