> The overhead attributed to libtool seems rather high. Is there
> something about your execution environment or your libtool usage which
> causes more overhead than usual?
Not that I am aware of, its the standard GNU libtool in
Slackware64-current.
> How does slibtool validate arguments? Does it understand the specific
> set of arguments allowed by the compiler/linker being used?
Slibtool handles all arguments that ere required for correct operation
and then passes everything that is not related to libtool to the
compiler. In my example I recall it was a compiler error and libtool
was swallowing the bogus argument before it got the compiler.
> What are the supported targets and target flavors?
>
> Does slibtool discard most of the portabilty (host OSs and toolchains)
> offered by the libtool script?
The slibtool developer offered me this reply to post:
===============
Regarding slibtool's portability: the tool is written in C and has no
external dependencies (other than the system's libc). The official
requirement for building slibtool is a c99 compiler and a system
supporting -D_XOPEN_SOURCE=600, however with just a few CFLAGS you
could build slibtool with a c89 compiler for a system that only
supports -D_XOPEN_SOURCE=500.
With respect to targets and target flavors, slibtool's approach (as
well as the approach of slibtool's own configure+Makefile) is to
*support any target by default* while making support of "special"
targets, as well as non-default target flavors, both possible and easy.
For additional context, here are some relevant bits from slibtool's
driver and API:
struct slbt_host_params {
const char * host;
const char * flavor;
const char * ar;
const char * ranlib;
const char * dlltool;
const char * mdso;
const char * ldrpath;
};
struct slbt_flavor_settings {
const char * imagefmt;
const char * arprefix;
const char * arsuffix;
const char * dsoprefix;
const char * dsosuffix;
const char * exeprefix;
const char * exesuffix;
const char * impprefix;
const char * impsuffix;
const char * ldpathenv;
};
#define
SLBT_FLAVOR_SETTINGS(flavor,bfmt,arp,ars,dsop,dsos,exep,exes,impp,imps,ldenv) \
static const struct slbt_flavor_settings flavor = { \
bfmt,arp,ars,dsop,dsos,exep,exes,impp,imps,ldenv}
SLBT_FLAVOR_SETTINGS(host_flavor_default, "elf", "lib",".a", "lib",".so",
"","", "", "", "LD_LIBRARY_PATH");
SLBT_FLAVOR_SETTINGS(host_flavor_midipix, "pe", "lib",".a", "lib",".so",
"","", "lib",".lib.a", "LD_LIBRARY_PATH");
SLBT_FLAVOR_SETTINGS(host_flavor_mingw, "pe", "lib",".a", "lib",".dll",
"",".exe", "lib",".dll.a", "PATH");
SLBT_FLAVOR_SETTINGS(host_flavor_cygwin, "pe", "lib",".a", "lib",".dll",
"",".exe", "lib",".dll.a", "PATH");
SLBT_FLAVOR_SETTINGS(host_flavor_darwin, "macho","lib",".a",
"lib",".dylib", "","", "", "", "DYLD_LIBRARY_PATH");
===============
> Usually it is possible to substitute Makefile text to replace the
> default rules used by Automake. This should allow changing how
> Automake invokes the tool in order to pass additional arguments. Have
> you tried that?
No, I did not consider that and I am not sure I really understand the
suggestion?
