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.
