Re: pkg-config and static builds
>> Indeed. However, how is that related to my request of having a >> separate set of linker flags for *static* linking? > > Before libtool could adequately address such a feature, it would > need to be supported by autoconf and configure scripts based on > autoconf. If there are two sets of LDFLAGS then each set should be > tested to make sure that it works. Options from pkg-config normally > feed configure scripts which deliver the final settings to Makefiles > which build the software. Libtool is subordinate to both autoconf > and the makefile (perhaps based on Automake). > > Libtool itself is configured using a set of autoconf macros. This probably explains why nothing has happened the last five years... In other words, someone has to step forward, providing patches *at the same time* for autoconf, automake, and libtool. Then *maybe* there is a chance that it gets incorporated. Sigh. Werner ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: pkg-config and static builds
On Tue, 4 Mar 2014, Werner LEMBERG wrote: Indeed. However, how is that related to my request of having a separate set of linker flags for *static* linking? Before libtool could adequately address such a feature, it would need to be supported by autoconf and configure scripts based on autoconf. If there are two sets of LDFLAGS then each set should be tested to make sure that it works. Options from pkg-config normally feed configure scripts which deliver the final settings to Makefiles which build the software. Libtool is subordinate to both autoconf and the makefile (perhaps based on Automake). Libtool itself is configured using a set of autoconf macros. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: pkg-config and static builds
> Depending entirely on pkg-config is not wise since it is an add-on > which is not part of the autotools framework and not uniformly > maintained. It is unrealistic to expect that all libraries needed by a package are manually compiled by the user so that all `.la' files are present. Additionally, there are zillions of packages that don't use libtool. > If an end user installs his own libraries from source code (GNU > still wants to support using source code), then the pkg-config > information may not be correct for the end-user's build. Let's assume that .pc files are correct, otherwise this discussion leads to nowhere. In addition, if you install a library from the source code, a proper .pc file is also installed in most cases. > Nothing has changed in libtool since the discussion you refer to. Hmm. I wonder whether the libtool team is going to improve that. Using, say, LDFLAGS_STATIC instead of LDFLAGS (if defined) for static builds would not be too difficult to implement, I reckon. > Static libraries do not have implicit dependencies (without benefit > of the .la files) and they do not support library dependency > versioning either. Static libraries are normally linked directly > into the application being built and not into other libraries. > Dependencies must be fully specified in order to avoid linkage > failure. This makes static libraries much more fragile and > problematic than using shared libraries. Well, yes, this is exactly why I'm discussing this issue :-) > Please note that there are some major operating systems that require > that dependencies be fully specified while linking a shared library. > An approach which works for GNU/Linux may fail on other systems. I'm aware of that, too. > Without an organization dedicated to making sure that it works (as > most GNU/Linux distributions do have), it is not feasable to depend > on shared library implicit dependencies. Successful implicit > dependencies are the outcome of careful planning, design, and > testing. Indeed. However, how is that related to my request of having a separate set of linker flags for *static* linking? Werner ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: pkg-config and static builds
On Mon, 3 Mar 2014, Werner LEMBERG wrote:
it seems it has been already discussed that libtool should use a
different set of link flags if compiling a static library, especially
for libraries that come without a corresponding `.la' file, cf. this
thread:
http://lists.gnu.org/archive/html/automake/2009-05/msg00068.html
Such a feature would be useful in combination with `pkg-config', which
has the `--static' command line option to give such a different set.
What's the current state? As an example, let's assume that my library
uses libpng. If I'm going to statically link to it, I need to add
`-lz' and `-lm'. From where do I get this information for static
linking if I want to use libtool for building my own library? I've
read that it would be better to not specify `-lz' and `-lm' while
building a shared library to avoid built-in references.
If the libary.la files are deleted, then you are on your own and your
configure script can only make an educated guess based on experience
and test those guesses. Guessing may be improved by using pkg-config
("manually" as you describe). Depending entirely on pkg-config is not
wise since it is an add-on which is not part of the autotools
framework and not uniformly maintained. If an end user installs his
own libraries from source code (GNU still wants to support using
source code), then the pkg-config information may not be correct for
the end-user's build.
Nothing has changed in libtool since the discussion you refer to.
Static libraries do not have implicit dependencies (without benefit of
the .la files) and they do not support library dependency versioning
either. Static libraries are normally linked directly into the
application being built and not into other libraries. Dependencies
must be fully specified in order to avoid linkage failure. This makes
static libraries much more fragile and problematic than using shared
libraries.
Please note that there are some major operating systems that require
that dependencies be fully specified while linking a shared library.
An approach which works for GNU/Linux may fail on other systems.
Without an organization dedicated to making sure that it works (as
most GNU/Linux distributions do have), it is not feasable to depend on
shared library implicit dependencies. Successful implicit
dependencies are the outcome of careful planning, design, and testing.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman/listinfo/libtool
