automake
[Top][All Lists]
Advanced

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

Makefile.in, LIBTOOL and shared/static builds.


From: address@hidden
Subject: Makefile.in, LIBTOOL and shared/static builds.
Date: Fri, 22 Jun 2018 20:55:16 -0700

Hi,

I am using the GNU libtool alternative slibtool which has some benefits
such as a smaller code base, actively maintained and a huge performance
boost.

The problem is that because slibtool doesn't work in the top directory
of a project it doesn't know if it should build with --enable-static,
--enable-shared or etc. To work around this slibtool ships with
symlinks, slibtool-shared and slibtool-static which alter the behavior
and works well enough if the user knows if it should be a static or
shared build. Unfortunately this also means that slibtool is not
capable of respecting ./configure flags such as --enable-shared or
--enable-static and will fall apart with more complicated builds like
libreoffice which has many internal dependencies where they mix and
match shared and static builds.

From talking with the slibtool developer I am informed this would be
best fixed in automake.

Currently it seems automake will add to Makefile.in.

$(LIBTOOL)

For slibtool and maybe some other projects (?) it would be much better
if automake instead added to Makefile.in.

$(LIBTOOL) $(LIBTOOL_LINKAGE)

Or something to that effect which I understand should be safe, this way
slibtool could know exactly what it should use with much less
complications for the user or failures with more complicated builds.

For reference the slibtool git repo can be found in the following link.

https://git.midipix.org/cgit.cgi/slibtool/

Thanks for any help,
Hunter



reply via email to

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