[Bug bootstrap/7125] libz is built even if configured with --with-system-zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7125 Richard Purdie changed: What|Removed |Added CC||richard.purdie at ||linuxfoundation dot org --- Comment #10 from Richard Purdie 2012-02-06 15:09:38 UTC --- This bug is still present in gcc 4.6 as I've configured with --with-system-zlib yet it still builds zlib for the host.
[Bug bootstrap/7125] libz is built even if configured with --with-system-zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7125 --- Comment #11 from Richard Purdie 2012-02-06 16:23:16 UTC --- Sorry, my previous report should be disregarded as it was user error. The option does appear to work for me, removing the zlib compile where it was previously present.
[Bug other/55930] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 Richard Purdie changed: What|Removed |Added CC||richard.purdie@linuxfoundat ||ion.org --- Comment #6 from Richard Purdie --- (In reply to Andrew Pinski from comment #5) > (In reply to Richard Purdie from comment #2) > > Created attachment 30880 [details] > > patch which fixes the problem > > > > This patch fixes the build failure when --disable-dependency-tracking is > > passed > > Patches should be posted to gcc-patches@ . > > But the bigger question is why are you passing --disable-dependency-tracking > ? Its part of a Yocto Project build and we would only ever build it once so we don't need/want the overhead of the dependency tracking information.
[Bug other/55930] [7/8/9 Regression] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 --- Comment #9 from Richard Purdie --- (In reply to Jonathan Wakely from comment #8) > (In reply to Richard Purdie from comment #6) > > Its part of a Yocto Project build and we would only ever build it once so we > > don't need/want the overhead of the dependency tracking information. > > But is there any noticeable overhead when using GCC to bootstrap? > > Automake documents the option as: > > Some compilers do not offer any practical way to derive the list of > dependencies as a side-effect of the compilation, requiring a separate > run (maybe of another tool) to compute these dependencies. The performance > penalty implied by these methods is important enough to disable them by > default. > > That doesn't apply here though, because GCC is generating the dependencies > via -MD as a side effect of compilation. So there should be no need to use > the option (other than saving a bit of disk space during the build). We pass this option in globally to anything using automake so whilst for one piece of software it might not be a huge gain, over a complete Linux stack built from source the disk space (lack of IO) speed wins are useful alone.
[Bug other/55930] [7/8/9/10 Regression] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 --- Comment #12 from Richard Purdie --- I started to look at sorting out Yocto Project/Openembedded's gcc patches in general and ran into a contribution agreement legal quagmire. I still haven't been able to resolve that.
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #1 from Richard Purdie --- I can see why that would change behaviour with the patch :(. It is a tough dilemma since without the patch, files might have prefixes removed some of the time but not all the time, depending on whether they were accessed via a symlink (or similar) or not. It was effectively impossible to remap some prefix values meaning in some cases output files couldn't be build deterministically. One possible way to fix this issue might be to call realpath on DW_AT_comp_dir so that we're always working on canonicalized paths? I'm not sure if that would be acceptable or not, the challenge right now is that we're making comparisons against things which aren't always definitive.
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #3 from Richard Purdie --- (In reply to Jakub Jelinek from comment #2) > Dunno about other uses of remap_filename, but for remap_debug_filename what > that commit changed doesn't seem to be ever appropriate. I think it depends on your use case. For example if via debug-prefix-map you say you want: /somepath/somesources translated to /somewhere and then some code references ../somesources and ../../somesources from it's build tree, would you want the user to have to add mappings for those and any other combination some build system might end up generating due to it's source layout? > Users pass often > pass what they get from pwd to -fdebug-prefix-map=, and that is usually not > the canonicalized path. And DW_AT_comp_dir was that same path as well and > IMHO it would be a very bad idea to change that. Debug info contains > relative paths in many cases, that also shouldn't be canonicalized, should > be whatever user used in -I etc. options or #include paths etc. > If one is mixing absolute paths and some are canonical and others aren't, > one can use multiple -fdebug-prefix-map= options. But ignoring what user > asked for is just wrong. It can be argued that if you ask for my above example and it doesn't remap the relative accesses, it is also just wrong. I can say that with all the cross compiling we do (in Yocto Project), making this handle the corner cases improved our binary reproducibility quite significantly. gcc can revert the change but we'd just have to patch something in to handle this. Another possible option is to resolve both sides of the equation before deciding to remap or not (i.e. the directory in debug-prefix-map and the potential target)?
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #5 from Richard Purdie --- (In reply to Jakub Jelinek from comment #4) > Though, even for the other options the change doesn't seem to be a good idea > as is. > I think instead the syntax of those remapping options should be extended, so > that for each of the pair one can choose the behavior which is wanted. > Using the OLD=NEW syntax > with the previous behavior, and some other to mark pairs where you want new > behavior > (dunno whether to mark those using say extra = at the end after NEW or > whatever else). > Then when populating file_prefix_map entries, one would record this > non-canonicalizing vs. canonicalizing flag and in the latter case > canonicalize the old_prefix path in the structure. > remap_filename then would ideally lazily lrealpath when seeing first map > entry with the bool flag indicating canonicalization. Having some way to enable the behaviour would be very valuable to the places we use prefix mapping so we could make that work FWIW.
[Bug c++/47256] "--sysroot" option is not passed to COLLECT_GCC_OPTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47256 --- Comment #7 from Richard Purdie --- Thanks for the tip, we'll look into dropping it!
