Previous: , Up: New ports   [Contents][Index]

15.1.2 Porting inter-library dependencies support

Since version 1.2c, libtool has re-introduced the ability to do inter-library dependency on some platforms, thanks to a patch by Toshio Kuratomi Here’s a shortened version of the message that contained his patch:

The basic architecture is this: in libtool.m4, the person who writes libtool makes sure ‘$deplibs’ is included in ‘$archive_cmds’ somewhere and also sets the variable ‘$deplibs_check_method’, and maybe ‘$file_magic_cmd’ when ‘deplibs_check_method’ is file_magic.

deplibs_check_method’ can be one of five things:

file_magic [regex]

looks in the library link path for libraries that have the right libname. Then it runs ‘$file_magic_cmd’ on the library and checks for a match against the extended regular expression regex. When file_magic_test_file is set by libtool.m4, it is used as an argument to ‘$file_magic_cmd’ to verify whether the regular expression matches its output, and warn the user otherwise.


just checks whether it is possible to link a program out of a list of libraries, and checks which of those are listed in the output of ldd. It is currently unused, and will probably be dropped in the future.


will pass everything without any checking. This may work on platforms where code is position-independent by default and inter-library dependencies are properly supported by the dynamic linker, for example, on DEC OSF/1 3 and 4.


It causes deplibs to be reassigned ‘deplibs=""’. That way ‘archive_cmds’ can contain deplibs on all platforms, but not have deplibs used unless needed.


is the default for all systems unless overridden in libtool.m4. It is the same as ‘none’, but it documents that we really don’t know what the correct value should be, and we welcome patches that improve it.

Then in we have the real workhorse: a little initialization and postprocessing (to setup/release variables for use with eval echo libname_spec etc.) and a case statement that decides the method that is being used. This is the real code… I wish I could condense it a little more, but I don’t think I can without function calls. I’ve mostly optimized it (moved things out of loops, etc.) but there is probably some fat left. I thought I should stop while I was ahead, work on whatever bugs you discover, etc. before thinking about more than obvious optimizations.

Previous: , Up: New ports   [Contents][Index]