bug#24886: Why is die "doc" output downloaded when building this package?
Hi, (Adding a bug at bug-guix@gnu.org.) Hartmut Goebel skribis: > when building this package, qt-4.8.7-doc (the doc-output of qt-4.7.8) > will be downloaded. I do not understand why. Most likely this is due to a limitation of the current implementation of grafts: all the outputs of packages on a “grafting path” need to be downloaded, even if some of these outputs are unused. This is because ‘graft-derivation’ takes a derivation, such as Qt’s, and returns a derivation with as many outputs, but marked as non-substitutable (locally built). Because it’s locally built, all the outputs of the original derivation must be fetched just to be able to build the grafted derivation, even if only one of those outputs is needed. I think we could fix that by creating one graft derivation for each output of the original derivation. Thanks, Ludo’.
bug#24703: Store references in 8-byte chunks in compiled code
On Sat, Nov 05, 2016 at 12:15:25AM +0100, Ludovic Courtès wrote: > I’ve fiddled a bit with GCC and read some code. No success yet, but > here’s a status update. Thanks for writing this out! > Instead, the knobs we have are (1) global flag to enable/disable each > built-in function (like -fno-builtin-… does), and (2) an x86-specific > knob to determine whether to use ‘movabs’ or not (‘-mmemcpy-strategy’ > supposedly controls that, but ‘-mmemcpy-strategy=libcall:-1:noalign’ > doesn’t seem to have any effect for instance.) Please correct me if I paraphrase the choices incorrectly: (1) Completely disable the strcpy optimization for all architectures (2) Ostensibly change how strcpy is optimized on x86, except the knob seems to have no effect > These knobs are not great because that would lead us to disable the > optimization wholesale, which is not desirable. What are the costs of (1)? Should we report (2) upstream?
