Various applications fail with "CFLAGS changed" when the make.conf has more than one adjacent space in the CFLAGS. This is because something, somewhere is tokenising the CFLAGS and then recombining them, and a literal comparison between the old and the new one fails, thus: configure: error: `CFLAGS' has changed since the previous run: configure: former value: -O3 -march=pentium4 -fomit-frame-pointer -pipe configure: current value: -O3 -march=pentium4 -fomit-frame-pointer -pipe configure: error: changes in the environment can compromise the build configure: error: run `make distclean' and/or `rm examples include: http://bugs.gentoo.org/show_bug.cgi?id=92645 http://bugs.gentoo.org/show_bug.cgi?id=105442 http://bugs.gentoo.org/show_bug.cgi?id=106447 CFLAGS stripped of extra spaces are semantically identical, it's easy to see why people are encountering this bug. The correct workaround (sanctioned by gentoo dev) appears to be to sanitize your make.conf CFLAGS. This is certainly the easiest solution all round. *However, there's no mention that this could be a problem in either the default make.conf, or any of the installation guides.* So, this is a request that something be mentioned, somewhere appropriate. Alternative solutions are reporting this issue upstream everywhere that it occurs; or changing portage so that it doesn't trigger this issue.
Can we add one line to make.conf.example?
Another possibility would be for portage itself to sanitize spaces when reading files. It's done already for the cascaded variables and I can't think of any case where spaces should be important within portage config files. Anybody see a reason to not do this?
Was about to suggest that.
another vote for comment #2.. it will automagically fix this, while allowing make.conf to remain readable with larger cflags sets and/or smaller terminals. export CFLAGS="`echo $CFLAGS`" or equivalent somewhere after sourcing make.conf would be ideal.
*** Bug 125730 has been marked as a duplicate of this bug. ***
Has this been fixed yet? Solution looks like it was found 6 months ago, but it's possible that the bug title is now misleading. IIRC (it was a while ago!) the bug title is as it is because when I tried to report this as an apache ebuild bug, I was told that it was a documentation issue with an obvious workaround. It does have an obvious workaround; but it's not necessarily a documentation issue, as you can see from the comments. For example, this bug is triggered by anyone who has a large CFLAGS setting in make.conf which has been spaced for readability. So, i've changed the Summary from emerge fails with "CFLAGS changed", documentation required in make.conf docs to emerge fails with "CFLAGS changed" due to extra spaces being removed I hope this is ok.
...or I would have changed it if bugzilla allowed that sort of thing ;)
*** Bug 130506 has been marked as a duplicate of this bug. ***
*** Bug 132130 has been marked as a duplicate of this bug. ***
*** Bug 135174 has been marked as a duplicate of this bug. ***
--- naim-0.11.7.2.ebuild 2005-09-03 20:35:49.000000000 +0100 +++ naim-0.11.7.2-r1.ebuild 2006-07-04 10:44:31.000000000 +0100 @@ -26,7 +26,7 @@ --enable-detach \ ${myconf} \ || die "configure failed" - emake || die "make failed" + emake -j1 || die "make failed" } src_install() {
(In reply to comment #11) > --- naim-0.11.7.2.ebuild 2005-09-03 20:35:49.000000000 +0100 > +++ naim-0.11.7.2-r1.ebuild 2006-07-04 10:44:31.000000000 +0100 > @@ -26,7 +26,7 @@ > --enable-detach \ > ${myconf} \ > || die "configure failed" > - emake || die "make failed" > + emake -j1 || die "make failed" > } > > src_install() { > er excuse me. please delete this comment and the one quoted, it was intended to go with a different bug. so sorry!
*** Bug 142541 has been marked as a duplicate of this bug. ***
*** Bug 144289 has been marked as a duplicate of this bug. ***
*** Bug 150041 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > Another possibility would be for portage itself to sanitize spaces when > reading files. It's done already for the cascaded variables and I can't think > of any case where spaces should be important within portage config files. > Anybody see a reason to not do this? I don't think it's a good idea for use to implement a *global* policy like this of collapsing whitespace in variables just because these configure scripts aren't very robust in their checks. We'd be committing ourselves to a global policy just to hack around somebody else's bug. I don't want a special case hack on CFLAGS for somebody else's bug either. Anyway, does anybody actually know what is collapsing the whitespace in these cases? If portage is collapsing the whitespace somewhere it shouldn't, then I think we should fix that. However, my tests show that the extra whitespace is preserved in ${T}/environment like one would expect.
I'm concerned that this bug has been closed as "WONTFIX" when all of the bugs which report individual ebuilds as exhibiting this behaviour have also been resolved as DUPLICATE of this bug or as WONTFIX. Shifting the blame about indefinitely obviously isn't the way to go. My point of view on "hacking around somebody else's bugs" is that we already do this extensively by patching ebuilds, so i don't think an idea can be justifiably dismissed on these grounds alone. If, instead, your reasoning is that we shouldn't do something for every single ebuild just because a significant handful need it, then we should start patching ebuilds and not resolving bugs as duplicate of this one, and reopen a bunch of bugs. I don't know portage's ebuild helper structure too well, but perhaps providing a utility class or something to do this when necessary in an ebuild is the way forward. This next bit is purely opinion, but I believe that the idea of the portage system is to make porting and compiling packages as easy as possible for both the end user and the package maintainer. As the package maintainer is rarely the software author, i believe it makes sense to provide as many tools and easy solutions for working around common bugs as possible.
(In reply to comment #17) > I'm concerned that this bug has been closed as "WONTFIX" when all of the bugs > which report individual ebuilds as exhibiting this behaviour have also been > resolved as DUPLICATE of this bug or as WONTFIX. Shifting the blame about > indefinitely obviously isn't the way to go. I'd say that a global policy to hide upstream bugs is obviously not the way to go. > My point of view on "hacking around somebody else's bugs" is that we already do > this extensively by patching ebuilds, so i don't think an idea can be > justifiably dismissed on these grounds alone. Those patches should be sent upstream whenever possible. > If, instead, your reasoning is that we shouldn't do something for every single > ebuild just because a significant handful need it, then we should start > patching ebuilds and not resolving bugs as duplicate of this one, and reopen a > bunch of bugs. Patching ebuild and/or sending the patches upstream... > I don't know portage's ebuild helper structure too well, but perhaps providing > a utility class or something to do this when necessary in an ebuild is the way > forward. Perhaps function in flag-o-matic.eclass could do this. > This next bit is purely opinion, but I believe that the idea of the portage > system is to make porting and compiling packages as easy as possible for both > the end user and the package maintainer. As the package maintainer is rarely > the software author, i believe it makes sense to provide as many tools and easy > solutions for working around common bugs as possible. If there's no way to fix this upstream, then a function in flag-o-matic.eclass or something like that is probably the way to go.
*** Bug 162290 has been marked as a duplicate of this bug. ***
*** Bug 167178 has been marked as a duplicate of this bug. ***
*** Bug 172599 has been marked as a duplicate of this bug. ***
*** Bug 174058 has been marked as a duplicate of this bug. ***
*** Bug 181404 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > Anyway, does anybody actually know what is collapsing the whitespace in these > cases? autoconf was, and has since been fixed with <http://cvs.savannah.gnu.org/viewvc/autoconf/lib/autoconf/status.m4?root=autoconf&r1=1.98&r2=1.99> If this problem happens with any package now, all that needs to be done is regenerating the configure script.
