[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re:, LIBTOOL and shared/static builds.

From: address@hidden
Subject: Re:, LIBTOOL and shared/static builds.
Date: Mon, 25 Jun 2018 17:05:11 -0700

> 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

> 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;

SLBT_FLAVOR_SETTINGS(flavor,bfmt,arp,ars,dsop,dsos,exep,exes,impp,imps,ldenv) \
        static const struct slbt_flavor_settings flavor = {                \

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]