Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] api2 module change to remove *.la files

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Remko van der Vossen <wich AT yuugen.jp>
  • To: Robin Cook <rcook AT wyrms.net>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] api2 module change to remove *.la files
  • Date: Mon, 17 Jun 2013 21:51:57 +0900

Hi All,


tldr: I think this is a bad idea. It would be better to standardize the
use of the --as-needed linker flag in my opinion.


The .la files ar used by libtool as most of you will know. It servestwo
purposes, it informs the build process of the actual file containing the
static or dynamic object, which may be different on different platforms.
Secondly it defines which libraries the library specified by the .la
file depends on. This way the final executable will know which libraries
it needs to link to to get a working executable.

Now, first lets say that the first point is of course moot as we will
(at the moment at least) always be on a consistent GNU linux platform so
the files containing the static and dynamic objects should follow the
usual conventions. However, you never know, maybe someone will release a
sourcemage for cygwin or whatever some day...

For the second point we have of course both the static and the dynamic
case. Let's first look at the dynamic case as that one is very easy
these days. With the introduction of DT_NEEDED in DSOs (which happened
quite a long time ago already) this hierarchical parsing of .la files to
get all shared objects is not necessary anymore, the executable only
needs to link against the direct dependencies. Except of course when a
different format than ELF is used for the dynamic objects.

For the static case however we still need to link the executable
directly against all the static libraries needed for the executable,
including indirect dependencies. This will be covered by libtool and
it's .la files. Would we not install the .la files any static builds
that rely on libtool will fail. As we claim to provide the user with
choice I don't think we should force dynamic builds on people. In fact
we even provide the user with the opportunity to build some packages
statically with a configure_query.

Now, the annoyance is that, even though in the case of dynamic linking
the indirect dependencies do not have to be put into the DT_NEEDED
entries of the dynamic objects, libtool still just puts the whole tree
into ld and ld obediently makes DT_NEEDED entries for each of them. This
creates a lot of unnecessary dynamic linking dependencies which can all
break with every ABI incompatible upgrade. Which is of course exactly
the thing that bites us so frequently with any less than trivial spell
upgrade.

The --as-needed linker flag will tell ld only to include DT_NEEDED
entries for those dynamic objects from which symbols are actually used,
which solves our problem. There is however a caveat, sometimes builds
may fail because of incorrect argument ordering in build systems, or a
package may rely on library X to bring in library Y even though the
package also directly depends on Y. Even runtime behaviour may be
changed or break, e.g. because of reliance on symbol overriding
functionality of ELF which may get compromised. This and the dislike of
foring choices on our users kept me from wanting to move forward on
introducing --as-needed globally in Source Mage. I would rather have
liked to see libtool fixed to do it's job properly and not include
indirect dependencies in the arguments unless the situation calls for
it, but this never happened.

Fortunately though several other distros such as OpenSuSe, Gentoo and
Debian have already moved to using --as-needed globally and because of
their bigger clout quite a few packages that were broken got fixed
upstream, still though not all packages will work with --as-needed, so
we will still have some work to do. Nonetheless, I do think that it is
time to go ahead with a global move to --as-needed. We are running into
too many problems with ABI incompatible changes and we simply don't have
the manpower to deal with it all leading to stuff bitrotting in devel
branches or causing massive breakage for many people. Additionally using
--as-needed will reduce linking times with packages which only use parts
of large toolkits.

So, I propose to modify default_build to add "-Wl,--as-needed" to
LDFLAGS, possibly depending on a flag in the sorcery feature menu and/or
an optional NO_AS_NEEDED flag in DETAILS to allow problematic spells to
build without --as-needed. I think the proper way forward is add support
in devel sorcery with the option <unset> and a default to off, have
individual developers turn it on and fix spells where needed. Once we
are satisfied we have a workable base, set the default in sorcery to on,
release devel sorcery, make sure we have a stable release of grimoire
with everything needed and then release a stable sorcery with the flag
default to on.

I do believe some mages already run with --as-needed by default. I
myself have mostly worked without it as I wanted to test the whole
libpng upgrade business without it, however I have set my latest system
to include --as-needed in LDFLAGS. Thus far I have seen no problems
related to it.

Thoughts? Opinions? Rants?

Regards,

Remko van der Vossen

On Sat, Jun 15, 2013 at 08:26:48AM -0500, Robin Cook wrote:
> I made the change below to remove any *.la files that get installed.
> There are some spells where the find statements need to be added to the
> INSTALL file as they done use default_install.
>
>
> So far I have found only one spell that looks for a *.la file during
> configure but was easily fixed.
>
>
>
>
> #---------------------------------------------------------------------
> ## @Type API
> ## Used if no INSTALL script is found
> ## Default install is:
> ## <pre>
> ## make install
> ## </pre>
> ##
> #---------------------------------------------------------------------
> function real_default_sorcery_install() {
> debug "build_api/api2" "Starting real_default_sorcery_install"
> make install
> find ${INSTALL_ROOT}/lib -name "*.la" | xargs rm -fv
> find ${INSTALL_ROOT}/usr/lib -name "*.la" | xargs rm -fv
> find ${INTALLL_ROOT}/usr/libexec -name "*.la" | xargs rm -fv
> }



> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss





Archive powered by MHonArc 2.6.24.

Top of Page