2015-08-08 15:49 GMT-03:00 Laurent Bercot:
>
> Not using vpath would result in not checking
> external libraries (so, fo instance, failing to rebuild if libskarnet.a
> changes)
And I don't know why you would want to do that. Software packages
usually don't bother; external libraries are at most checked to exist
and work during configuration phase, and that's it. This would only be
useful, I suppose, if you keep, say, execline's build directory intact
until the next upgrade, instead of just erasing it, and want to save
some build time in case you upgrade skalibs and want the same version
of execline to link with the new libskarnet?
But it's not a big deal anyway, I only said I didn't like it :)
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=541092
> Can you please translate that bug and/or give a concrete example ?
> I can't speak Gentooese, so I don't understand either the bug-report
> or the patch. ^^'
Hahaha, sure. Take for example execline, and assume you want to
*upgrade* it to a more recent version. Or that for some reason you
want to reinstall (new skalibs version, etc.). That is, you *already
have* a libexecline.so and/or libexecline.a, and the newly built ones
are going to be installed in the same directory as the older ones,
replacing them. That's what the person who made the bug report was
doing (indirectly through Gentoo's package manager).
What happens then? There are makefile rules containing
'libexecline.so' or 'libexecline.a' prerequisites, depending on what
configure options were used. There are vpath directives specifiying
library directories, so that '-lskarnet' prerequisites work. And there
is the possibility that the directories in which libexecline.{a,so}
are going to be installed ('libdir' and/or 'dynlibdir'), might be
shared with libskarnet.{a,so}. For example, because the user wants to
dump all skarnet.org package dynamic libraries in, say, /lib or
/lib/skarnet. In the case of that bug report, libskarnet.so and
libexecline.so were both installed in /lib64, so let's take that to
continue the exposition.
The result is that make gets confused about the libexecline.so
prerequisite, because there is a /lib64/libexecline.so already, the
old library about to be replaced, that is found as a result of vpath
search. And it sees two rules: the rule for the "plain" libexecline.so
target in package/deps.mak, that has prerequisites but no recipe, and
a pattern rule '$(DESTDIR)$(dynlibdir)/lib%.so:' with a recipe in the
main makefile, that can match a /lib64/libexecline.so target and a
"plain" libexecline.so prerequisite. The prerequisite gets discarded
with a 'circular dependency dropped' warning, because make thinks it
means the /lib64/libskarnet.so found via vpath search:
make: Dipendenza circolare /lib64/libexecline.so <-
/lib64/libexecline.so scartata.
(in Italian because of the reporter's LANG="it" setting)
So that leaves it a rule with no prerequisites, that gets combined (in
a kinda hilarious way) with the other rule with no recipe. And make
ends up deciding, after expansion of '$<' to
'src/libexecline/el_execsequence.lo' (the first prerequisite in the
rule for "plain" libexecline.so), that the recipe to build the library
is './tools/install.sh -D -m 755 src/libexecline/el_execsequence.lo
/lib64/libexecline.so.2.0.2.1 && [...]'. And boom. That would
overwrite the existing library with a newly built object file, and for
the next executable that needs libexecline.so, that one will be picked
up because of vpath, and make will ultimately fail with a linker
error.
This will happen with static libraries as well, provided the setup is
similar, and will happen for s6 with libs6.{a|so}. The workaround
proposed in that report? Building the package using 'make
DESTDIR=dummy-directory' instead of a plain 'make'. 'dummy-directory'
doesn't even have to exist, its only purpose is that target
$(DESTDIR)$(dynlibdir)/lib%.so can no longer match
/lib64/libexecline.so and confuse make, so the two makefile rules do
not get combined, and libexecline.so gets built using the 'lib%.so:'
rule. And because the new libexecline.so exists now in the build
directory, the prerequisite search algorithm will prefer it over the
old library found via the vpath directive, so executables will also be
correctly built. Of course, the 'make install' step should use a
proper DESTDIR, if any.
In the specific case of that report, because Gentoo is a source-based
distribution and its package manager builds sotfware in a temporary
directory, and sets up a sandbox to do it, when make tries to
overwrite the existing library in the /lib64 directory, what happens
is that a sandbox violation is triggered because /lib64 is not allowed
to be written, and everything is aborted. What the patch talked about
does is modify the "Gentoo ebuild", i.e. Gentoo's "recipe" to build
the package from source, so it uses the DESDTIR trick for the compile
phase.
Cheers!
G.
Received on Sun Aug 09 2015 - 15:34:50 UTC