Emerging webkit-gtk-1.1.15.2 and later it crushes with message: make -j3 glib-mkenums \ --fhead "#ifndef WEBKIT_ENUM_TYPES_H\n" \ --fhead "#define WEBKIT_ENUM_TYPES_H\n\n" \ --fhead "#include <glib-object.h>\n\n" \ --fhead "#include <webkit/webkitdefines.h>\n\n" \ --fhead "G_BEGIN_DECLS\n\n" \ --ftail "G_END_DECLS\n\n" \ --ftail "#endif\n" \ --fprod "#include <webkit/@basename@>\n\n" \ --eprod "#define WEBKIT_TYPE_@ENUMSHORT@ @enum_name@_get_type()\n\n" \ --eprod "WEBKIT_API GType\n@enum_name@_get_type(void);\n\n" \ ./WebKit/gtk/webkit/webkit.h ./WebKit/gtk/webkit/webkitdefines.h ./WebKit/gtk/webkit/webkitdownload.h ./WebKit/gtk/webkit/webkiterror.h ./WebKit/gtk/webkit/webkithittestresult.h ./WebKit/gtk/webkit/webkitnetworkrequest.h ./WebKit/gtk/webkit/webkitnetworkresponse.h ./WebKit/gtk/webkit/webkitsoupauthdialog.h ./WebKit/gtk/webkit/webkitwebbackforwardlist.h ./WebKit/gtk/webkit/webkitwebdatasource.h ./WebKit/gtk/webkit/webkitwebframe.h ./WebKit/gtk/webkit/webkitwebhistoryitem.h ./WebKit/gtk/webkit/webkitwebinspector.h ./WebKit/gtk/webkit/webkitwebnavigationaction.h ./WebKit/gtk/webkit/webkitwebpolicydecision.h ./WebKit/gtk/webkit/webkitwebresource.h ./WebKit/gtk/webkit/webkitwebsettings.h ./WebKit/gtk/webkit/webkitwebwindowfeatures.h ./WebKit/gtk/webkit/webkitwebview.h ./WebKit/gtk/webkit/webkitwebdatabase.h ./WebKit/gtk/webkit/webkitsecurityorigin.h ./WebKit/gtk/webkit/webkitversion.h | \ sed 's,web_kit,webkit,' | \ sed 's,WEBKIT_TYPE_KIT,WEBKIT_TYPE,' \ > xgen-gth \ && (cmp -s xgen-gth WebKit/gtk/webkit/webkitenumtypes.h || cp xgen-gth WebKit/gtk/webkit/webkitenumtypes.h) \ && rm -f xgen-gth \ && echo timestamp > stamp-webkitenumtypes.h make: execvp: /bin/sh: Argument list too long Reproducible: Always Steps to Reproduce: 1a.just emerge "=webkit-gtk-1.1.15.2" 1b. env - PATH=$PATH emerge "=webkit-gtk-1.1.15.2" have the same result
Created attachment 216384 [details] emerge info
Attach full build log.
Created attachment 216392 [details] full build log
what is your /bin/sh linking to ?
(In reply to comment #4) > what is your /bin/sh linking to ? > /bin/bash also checked /usr/bin/zsh but same situation there. P.S. There'is a discusstion about situation with this package: http://www.mail-archive.com/bug-autoconf@gnu.org/msg02266.html and patch for make as conclusion of discussion: http://thread.gmane.org/gmane.comp.gnu.make.bugs/4219 But in my situation this also won't help. I've try to emerge webkit-gtk with patched make and with normal.
Another thing, if I'm trying to make project form /var/tmp/portage/net-libs/webkit-gtk-1.1.15.2/work then it will be ok. And if make my own ebuild in local overlay and change: - emake || die "Compile failed" + env - PATH=$PATH emake || die "Compile failed" and + emake DESTDIR=${D} install || die "Install failed" - env - PATH=$PATH emake DESTDIR=${D} install || die "Install failed" with this "hack" package will be installed. So I think, this is not really a bug but some kind of bottle neck. I'm still waiting for the real solution. Maybe there will be some ideas about situation.
Could you now try again as sys-devel/make now comes with the patch that should fix the argument list too long issue.
(In reply to comment #7) > Could you now try again as sys-devel/make now comes with the patch that should > fix the argument list too long issue. > The same situation with sys-devel/make-3.81 and sys-devel/make-3.81-r1, the latest version in official portage. Or should I use another make version?
(In reply to comment #8) > The same situation with sys-devel/make-3.81 and sys-devel/make-3.81-r1, the > latest version in official portage. Or should I use another make version? > Unfortunately I have no better idea atm, I was only hoping it would fix this issue.
*** Bug 308669 has been marked as a duplicate of this bug. ***
I have been able to get webkit-gtk to compile with the following ebuild hack: src_compile() { # ARG_MAX is to long, so we have to remove as much from the arguments as possible env - PATH="${PATH}" CHOST="${CHOST}" CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}" \ emake || die "compile failed" } src_install() { # ARG_MAX is to long, so we have to remove as much from the arguments as possible env - PATH="${PATH}" CHOST="${CHOST}" CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}" \ emake DESTDIR="${D}" install || die "Install failed" dodoc WebKit/gtk/{NEWS,ChangeLog} || die "dodoc failed" } The issue I discovered is that my environment was to large for the shell to deal with. Prefacing the command "env - PATH=..." to emake allows it to build. I am not sure if I have included enough environmental variables, but with this hack I was able to update my entire system. So, it seems to work and there are likely better ways to solve the problem, but this might give other people a clue in potential solutions.
Do you suffer the same with 1.2.1?
yep. It still fails.
CCing "make" maintainers to try to clarify this a bit :-/
looks like that make line is unnecessarily long/complicated. how about rewriting it like so: glib-mkenums .... | \ sed -e 's,web_kit,webkit,' -e 's,WEBKIT_TYPE_KIT,WEBKIT_TYPE,' \ > xgen-gth cmp -s xgen-gth WebKit/gtk/webkit/webkitenumtypes.h \ || cp xgen-gth WebKit/gtk/webkit/webkitenumtypes.h rm -f xgen-gth echo timestamp > stamp-webkitenumtypes.h standard make behavior of aborting upon failure means those && are pointless
Hello, I got same with new ebuild ( net-libs/webkit-gtk-1.2.3 ) but it still work with - emake || die "Compile failed" + env - PATH=$PATH emake || die "Compile failed" and + emake DESTDIR=${D} install || die "Install failed" - env - PATH=$PATH emake DESTDIR=${D} install || die "Install failed" Baybe we must make an upstream report ? Best regards
They might be able to fix it up stream, but since prepending "env PATH=$PATH" seems to fix the problem, it seems like a fix we can make in portage. If/when they fix it up stream, then it can be removed. Is there a reason that we cannot use that to patch the ebuild?
(In reply to comment #17) > They might be able to fix it up stream, but since prepending "env PATH=$PATH" > seems to fix the problem, it seems like a fix we can make in portage. If/when > they fix it up stream, then it can be removed. > > Is there a reason that we cannot use that to patch the ebuild? > Thanks for your answer. I will try just with env PATH=$PATH. It seems to be crazy if it work. Best Regards
Does webkitgtk compile ok when compiling it manually on your home for example? (./configure && make)
> Does webkitgtk compile ok when compiling it manually on your home for example? > (./configure && make) yes, everything is ok. It seems that problem is in big ENV var produced by portage when it emerges program. When I spoke with webkit-gtk updstream (january 2010) they had not be able to reproduce this problem. But maybe now something have changed. I think it's a good idea to add "env -" patch to ebuild unless it will be fixed in upstream.
(In reply to comment #20) > I think it's a good idea to add "env -" patch to ebuild unless it will be fixed > in upstream. > I would prefer to hear first portage maintainers opinion (CCing them so) before applying this workaround or ask upstream to apply changes suggested by SpanKY in comment #15
(In reply to comment #21) > I would prefer to hear first portage maintainers opinion (CCing them so) before > applying this workaround or ask upstream to apply changes suggested by SpanKY > in comment #15 That 'env - PATH=$PATH' thing clears out all environment variables, which might cause some problems. I've never seen a report like this for any other package, so it seems like the package is doing something abnormal. Maybe the cleanest solution would be to reduce the length of the argument list, if possible.
(In reply to comment #22) > Maybe the cleanest > solution would be to reduce the length of the argument list, if possible. > Should I then suggest upstream to reduce it even if compilation outside portage succeeds? :-/
(In reply to comment #23) > (In reply to comment #22) > > Maybe the cleanest > > solution would be to reduce the length of the argument list, if possible. > > > > Should I then suggest upstream to reduce it even if compilation outside portage > succeeds? :-/ Upstream already reduced it and fixed bug in 'make'. See bug #301116
But looks like "more reduction" is still required :-(
I suppose the 'env - PATH=$PATH' thing isn't so bad if that's your only alternative. You just have to make sure that you pass in any relevant variables.
is there a new version of the ebuilds for testing? The one updated last week is still busted.
Could the issue be fixed in changes due to https://bugs.gentoo.org/show_bug.cgi?id=343249 ?
most likely not.
Are you still able to reproduce with 1.2.6? In that case, please try changes suggested in comment #15
I will have to check later as there are no 1.2.6 ebuilds (for Gentoo) as of yet. I'll try it later. I'll volunteer to test/verify if someone had a 1.2.6 ebuild.
I added it some hours ago ;-)
>>> Source configured. >>> Compiling source in /var/tmp/portage/net-libs/webkit-gtk-1.2.6/work/webkit-1.2.6 ... make -j5 XDG_DATA_HOME=/var/tmp/portage/net-libs/webkit-gtk-1.2.6/temp/.local make: execvp: /bin/sh: Argument list too long make: *** [stamp-webkitenumtypes.h] Error 127 emake failed ... nope, still there.
Created attachment 258932 [details] emerge info
There was an update to the 1.2.6 ebuild today (Jan 10, 2011). It still dies with the "Argument list too long" error
Maybe people hits this when compiling using emerge instead of manually compiling because makefiles are regenerated due eautoreconf, could you try skipping eautoreconf?
(In reply to comment #36) > Maybe people hits this when compiling using emerge instead of manually > compiling because makefiles are regenerated due eautoreconf, could you try > skipping eautoreconf? > Did you try it?
sorry for the delay. I just tried commenting out the line "AT_M4DIR=autotools eautoreconf", but it still dies with arg list to long. I played around and discovered the problem. It appears that it has nothing to do with the configuration but with both make and emake. The underlying problem is that the environment (env) which portage's ebuild passes to make is to big for it. I printed it out in an experimental ebuild (just before it died, and it was pages long. If I then go into the temp directory and run make by hand it works fine. If I prepend all the emakes with "env - PATH="${PATH}" CHOST="${CHOST}" CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}" " then the ebuilds works fine. I have no idea why of all the ebuilds in Gentoo, this is the only time I have ever run across this. hope this helps. EBo --
a little more information. When I printenv just before the emake which dies, I find that it icludes stuff from /etc/make.conf, the ebuild variables, various system configuration stuff, in addition to what I would expect to see. When I do a "printenv | wc" in the xterm I see that env contains 74/95/4969 or 74 lines. The same thing from within the ebuild contains 272/656/15753, or more than three times as much junk. Hope this helps.
Maybe attaching here a file with your "env" contents just before emake fails could help portage team (that is also CCed here) to try to know where could be the problem here :-/
I thought about attaching it to my last bug report, but there is more system/personal information in it than I choose to divulge openly on the net and the thought of spending half an hour weeding out anything that I thought could potentially be useful to a hacker made me choose otherwise. So, I'm sending this information directly to you, and am OK with you forwarding it to the portage team. I as that this info not go out further without first consulting me.
(In reply to comment #41) I'm not sure what to look for in your environment, other than KV=2.6.34-gentoo-r6 which indicates a fairly recent kernel. Is that what you're actually running? Since linux-2.6.23, ARG_MAX is practically unlimited on the kernel side, as mentioned in bug 262647, comment #11. But maybe you're hitting a limitation in glibc or something. What version of glibc do you have? The output of `emerge --version` is handy here since it reports both running kernel version and glibc version. Anyway, have you tried the 'env - PATH=$PATH' trick to see if that helps?
Zac, My emrge --version give "Portage 2.1.9.25 (default/linux/amd64/10.0, gcc-4.4.4, glibc-2.11.2-r3, 2.6.34-gentoo-r6 x86_64)". As a note, whenever I upgrade gcc or glibc, I run "emerge -e world" and rebuild everything so I know there is no incompatibilities. As a further note, yes I use a variant of 'env - PATH=$PATH' as stated above and it does work. The ebuild as is is still broken.
Will try to say again that ENV file is too big so we have problems. There can be some solutions: 1). webkit-gtk upstream will fix make file. But can be a low priority thing, because it works everywhere except emerge. It will be very good if somebody can update makefiles or send patch to make it work and report it to upstream (comment 15) 2). make upstream can try to do something with execution behavior. But here we have same situation as above. 3). try to shrink env variable, maybe it can be done in emake command, because in make there is no need in gentoo specific env variables and functions like virtualmake,unpack_pdv.
Alexander, I understand the the ENV is to big. While it would be nice for them to fix the GNUMakefile upstream it also is unlikely since only emerge has a problem. There is a simple trick to fix this for now: 'env - PATH=$PATH' Why do we not simply add that before all the emake's for now until it is fixed upstream? That way the ebuild just works now, and we can undo it later?
Please retry with 1.4.1-r200
(In reply to comment #46) > Please retry with 1.4.1-r200 still not work for me: >>> Source configured. >>> Compiling source in /var/tmp/portage/net-libs/webkit-gtk-1.4.1-r200/work/webkit-1.4.1 ... make -j3 XDG_DATA_HOME=/var/tmp/portage/net-libs/webkit-gtk-1.4.1-r200/temp/.local echo WTF_USE_NATIVE_GTK_MAIN_FRAME_SCROLLBAR=1 ENABLE_CHANNEL_MESSAGING=1 ENABLE_METER_TAG=1 ENABLE_PROGRESS_TAG=1 ENABLE_JAVASCRIPT_DEBUGGER=1 ENABLE_OFFLINE_WEB_APPLICATIONS=1 ENABLE_DATABASE=1 ENABLE_DATALIST=1 ENABLE_EVENTSOURCE=1 ENABLE_DOM_STORAGE=1 ENABLE_VIDEO=1 ENABLE_FULLSCREEN_API=1 ENABLE_XPATH=1 ENABLE_XSLT=1 ENABLE_WORKERS=1 ENABLE_SHARED_WORKERS=1 ENABLE_FILTERS=1 ENABLE_BLOB=1 make: execvp: echo: Argument list too long I can attach build log or env file if needed
Attach both please as generated by emerge when failing
Created attachment 276923 [details] build log for 1.4.1-r200
Created attachment 276927 [details] environment file for webkit-gtk 1.4.1-r200
I recently saw some instruction to add to Makefile.am that was supposed to make compilation work where it was expected to generate too long command lines. I'll have to search for it because I forgot how it was named :(.
(In reply to comment #51) > I recently saw some instruction to add to Makefile.am that was supposed to make > compilation work where it was expected to generate too long command lines. I'll > have to search for it because I forgot how it was named :(. Not sure if you were referring to use MAKEOVERRIDES in some way as shown in: http://www.gnu.org/software/make/manual/make.html#index-Arg-list-too-long-427 Maybe make maintainer could help on this :-/ (base-system...)
Is this still valid with 1.6.x?
(In reply to comment #53) > Is this still valid with 1.6.x? yep... as of net-libs/webkit-gtk-1.6.1-r300 >>> Source configured. >>> Compiling source in /var/tmp/portage/net-libs/webkit-gtk-1.6.1-r300/work/webkit-1.6.1 ... make -j5 XDG_DATA_HOME=/var/tmp/portage/net-libs/webkit-gtk-1.6.1-r300/temp/.local make: execvp: /bin/sh: Argument list too long make: *** [DerivedSources/webkit/WebKitDOMCSSRule.h] Error 127 * ERROR: net-libs/webkit-gtk-1.6.1-r300 failed (compile phase): * emake failed everything else being equal to *-r200 before.
gnome team, we need to find a solution for this long term issue, do you approve the usage of "env workaround", I couldn't find that option mentioned by Gilles to accept long command lines :(
(In reply to comment #55) > gnome team, we need to find a solution for this long term issue, do you approve > the usage of "env workaround", I couldn't find that option mentioned by Gilles > to accept long command lines :( The workaround that has consistently worked for me is to add the following judiciously before every call to emake, Xemake, and "default" in the install section: env - PATH="${PATH}" CHOST="${CHOST}" CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}" \ I consider that a hack, but until a more general solution is provided upstream it "just works" Hope that helps.
Upstream blames on our make: https://bugs.webkit.org/show_bug.cgi?id=62543#c2
(In reply to comment #57) > Upstream blames on our make: > https://bugs.webkit.org/show_bug.cgi?id=62543#c2 Webkit developers want us to use a patch that was refused by gnu make's upstream ('it has "special hack" written all over it')? Wonderful...
we already had that patch in make-3.81. it was dropped because it was supposed to be integrated into make-3.82.
i've committed make-3.82-r4 with a forward ported long-cmdline.patch if you want to see if that fixes things (it has no KEYWORDS atm)
Out of curiosity, why not use the "env - ..." ebuild trick to get the ebuilds working now, and remove that later when a suitable make-3.82-r*.ebuild that fixes the problem is marked as stable. This should get something working in the short term while the proper fix is being worked on upstream.
Well, we are a bit unsure about cleaning all environment and then trying to keep some set of variables as we maybe miss a needed one by error :/
Cleaning the environment is not the right solution. Let's try make 3.82-r4.
(In reply to comment #63) > Cleaning the environment is not the right solution. Let's try make 3.82-r4. I absolutely agree, but I think you missed my point -- the net-libs/webkit-gtk ebiulds have now been broken for *years*, and through how many revisions of the upstream code? So, is there some temporary solution (please read an ebuild that is not considered stable but is still useful enough to put into the tree)? That is all that I am asking for in the short term while we try to find a real fix.
unfortunately, i think you missed the counter point. test the fix *already in the tree* and report back.
(In reply to comment #65) > unfortunately, i think you missed the counter point. test the fix *already in > the tree* and report back. I just tried updating to the latest make (alluded to above - even though the keywords are commented out and it had to be built by hand) AND 3 different revisions of webkit-gtk from the tree and guess what -- it Still breaks... Like I mentioned before, I already tested all the stuff in the tree, what was mentioned here, and the fixes I got working over a year ago. After two years of having to hand patch this package every time an update comes out I'm tired enough of this that I am removing webkit-gtk as it is option on the two packages used in my system. Let me know if and when it really gets fixed.
Please provide updated build.log when failing with make-3.82-r4
Ok well I have placed the env line into /etc/portage/package.environment,& restarted the build. on shutdown of the original build the load factors for my x86_64 single core, 29.2 29.5 22.3 which as you can imagine was really stressing out the cpu. figures with the env change 1.30 6.5 13.4 1.52 2.46 8.71 1.27 1.30 1.85 1.40 1.32 1.32 over a period of an hour & I'm able todo other things as well. Geoff
comment #68 additional this is webkit-gtk-1.6.1-r300
(In reply to comment #69) > comment #68 additional this is webkit-gtk-1.6.1-r201 on my x86_64
Created attachment 294715 [details] make-3.82-r4.build.log attempt to build latest ebuild (webkit-gtk-1.6.1-r301) with the new (unstable) make. Maybe there is something useful in this too.
Created attachment 294717 [details] webkit-gtk-1.6.1-r301.build.log build attempt of webkit-gtk-1.6.1-r301 after updating to make-3.82-r4.
(In reply to comment #67) > Please provide updated build.log when failing with make-3.82-r4 done and log files attached. As a note, I'm packing up for a move and will not have time to play with any of this for several weeks at best. So, I am restripping theses off my system.
(In reply to comment #72) > Created attachment 294717 [details] > webkit-gtk-1.6.1-r301.build.log > > build attempt of webkit-gtk-1.6.1-r301 after updating to make-3.82-r4. Can you provide "emerge --info" also to be sure you are using proper make version?
"make -v" returns: GNU Make 3.82 Built for x86_64-pc-linux-gnu Copyright (C) 2010 Free Software Foundation, Inc. ... Since I was running sys-devel/make-3.82-r1 before and upgraded to sys-devel/make-3.82-r4 there is no way to know that I could think of to verify that I was really running the new one. I've now removed webkit from the use flags, removed , and regressed make back to 3.82.r1, but I will post the emerge --info file forthcomming
Created attachment 294787 [details] new emerge info
"emerge --info" shows the exact revision you are using: [...] sys-devel/make: 3.82-r1 [...] Then, you would need to update again to -r4, confirm with "emerge --info" you are using that one and try to reproduce. And, once it's 100% confirmed it still fails for you even with the patch, I can reopen webkit upstream report telling them the patch is not enough ;)
As I mentioned in my last post, you requested another emerge info after I had regressed make and removed webkit-gtk from my machine. It will probably be a a couple of weeks to a month before I can take the time to muck with this some more. I'm in the middle of a move. If I do not get back to you before the first of the year send me an email to remind me.
Created attachment 296199 [details] build webkit-gtk-1.6.1-r301 with sys-devel/make-3.82-r4 reinstalled make-3.82-r4 and attempted to rebuild latest versions of webkit-gtk -- still fails
Created attachment 296201 [details] build webkit-gtk-1.4.3-r300 with sys-devel/make-3.82-r4 attempt to build latest stable version of webkit-gtk with sys-devel/make-3.82-r4 -- still fails with env to long
Created attachment 296203 [details] latest emerge info including sys-devel/make-3.82-r4 the experimental make does not correct the problem with env to long error
(In reply to comment #78) > As I mentioned in my last post, you requested another emerge info after I had > regressed make and removed webkit-gtk from my machine. It will probably be a a > couple of weeks to a month before I can take the time to muck with this some > more. I'm in the middle of a move. If I do not get back to you before the > first of the year send me an email to remind me. OK. Just got settled into the new place and replicated the above scenario: updated to sys-devel/make-3.82-r4 attempt to build experimental webkit-gtk-1.6.1-r301 -- fails with env to long attempt to build latest stable webkit-gtk-1.4.3-r300 -- fails with env to long latest emerge --info attached. ps: sorry for the delay. Hope this is sufficient.
did you try to apply changes suggested in comment #15?
This happens to me with the latest ebuild (1.9.91-r300) from gnome-overlay again! CXX DerivedSources/WebCore/libWebCore_la-XPathGrammar.lo CXX DerivedSources/ANGLE/libWebCore_la-glslang.lo DerivedSources/ANGLE/glslang.cpp:2957:6: warning: "ANGLE_USE_NEW_PREPROCESSOR" is not defined [-Wundef] DerivedSources/ANGLE/glslang.cpp:3089:5: warning: "ANGLE_USE_NEW_PREPROCESSOR" is not defined [-Wundef] DerivedSources/ANGLE/glslang.cpp:3158:6: warning: "ANGLE_USE_NEW_PREPROCESSOR" is not defined [-Wundef] DerivedSources/ANGLE/glslang.cpp:3171:5: warning: "ANGLE_USE_NEW_PREPROCESSOR" is not defined [-Wundef] DerivedSources/ANGLE/glslang.cpp:3187:5: warning: "ANGLE_USE_NEW_PREPROCESSOR" is not defined [-Wundef] DerivedSources/ANGLE/glslang.cpp: In function 'int yylex(YYSTYPE*, yyscan_t)': DerivedSources/ANGLE/glslang.cpp:1134:30: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] DerivedSources/ANGLE/glslang.cpp: In function 'yy_buffer_state* yy_scan_bytes(const char*, yy_size_t, yyscan_t)': DerivedSources/ANGLE/glslang.cpp:2540:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] CXX DerivedSources/ANGLE/libWebCore_la-glslang_tab.lo make[1]: execvp: /bin/sh: Argument list too long make[1]: *** [libWebCore.la] Error 127
(In reply to comment #84) > This happens to me with the latest ebuild (1.9.91-r300) from gnome-overlay > again! Could you check whether `make` is installed from portage or overlay? You can do that by checking the output of the following command (assuming you have make-38.2-r4 installed): cat /var/db/pkg/sys-devel/make-3.82-r4/repository
# cat /var/db/pkg/sys-devel/make-3.82-r4/repository gentoo
(In reply to comment #86) > # cat /var/db/pkg/sys-devel/make-3.82-r4/repository > gentoo Ok, seems like portage version of make is still broken (I just confirmed it on my own machine). There's sys-devel/make-3.82-r4 also in GNOME overlay that seems to have a fix for that issue (but seems to have issues also with parallel-make). I'll to update the patches and put -r5 out into GNOME overlay. Meanwhile you could try out the -r4 in portage, in case you are feeling adventureous ;)
(In reply to comment #87) > (In reply to comment #86) > > # cat /var/db/pkg/sys-devel/make-3.82-r4/repository > > gentoo > > Ok, seems like portage version of make is still broken (I just confirmed it > on my own machine). > > There's sys-devel/make-3.82-r4 also in GNOME overlay that seems to have a > fix for that issue (but seems to have issues also with parallel-make). > > I'll to update the patches and put -r5 out into GNOME overlay. Meanwhile you > could try out the -r4 in portage, in case you are feeling adventureous ;) I pushed make-3.82-r5 to overlay, please try it out.
i dropped the patches that i had in the masked 3.82-r4 and added a bunch of various ones from upstream dealing with command line and parallel builds. maybe it makes a difference, maybe it doesn't.
(In reply to comment #89) > i dropped the patches that i had in the masked 3.82-r4 and added a bunch of > various ones from upstream dealing with command line and parallel builds. > maybe it makes a difference, maybe it doesn't. @vapier - apparently one extra patch [1] is still needed to get webkit-gtk to build. [1] http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=blob;f=sys-devel/make/files/make-3.82-long-cmdline-webkit.patch;h=685fdb704797ac3ff211861c8fe36c2329c054d1;hb=HEAD
(In reply to comment #90) that's the patch that was originally in 3.82-r4 and people said didn't work
(In reply to comment #91) > (In reply to comment #90) > > that's the patch that was originally in 3.82-r4 and people said didn't work That patch had been used by webkit-gtk developers for a long time: http://trac.webkit.org/browser/trunk/Tools/gtk/patches
(In reply to comment #92) that may be, but read this bug and the feedback people here have given
Ok. The latest version of the ebuild in the main portage tree (1.8.3-r-300) still breaks with the exact same behaviour. At this point the env hack no longer works for me. Yes, I have gone back and tried comment #15, and I have followed all the leads I can and tried verious versions of make and bash (actually I tried an exaustive permutation of all combinations and nothing works). At this point I have removed webkit-gtk from my system. In summary, I know that my environment is huge -- I run a highly experimental developmental system and test hard real-time kernels, do scientific visualiztion and processing, and research computer architectures. No matter how weird my system is, webkit-gtk is the only package out of 1231 installed on my server that ever caused me this problem. If you ever get this figured out let me know and I will test it, but I will no longer include it in my base packages.
*** Bug 463804 has been marked as a duplicate of this bug. ***
While doing some updates and experimentation I cam across this again. A haced version of 1.4.3-r390 (I called 1.4.3-r391 in my local repository) was the last one I got to work by cleaning the ENV and passing only what I needed in. That hack has not worked since. I never removed webkit-gtk from my system, and periodically I test updates to see if any of them work... The latest (webkit-gtk-2.0.4) gives the same results. For reference, I have tried make-3.82-r5 and reverted back to -r4 once I found it did not work. Also, doing a quick review I find that various people suggest upgrading the kernel above 2.6.32 (I'm running 3.7.10 currently, and am upgrading to 3.10.7), bash-4.2_p45, and automake-1.13.4... Currently I get the following error: make -j1 (CDPATH="${ZSH_VERSION+.}:" && cd . && autoheader) make: execvp: /bin/sh: Argument list too long make: *** [autotoolsconfig.h.in] Error 127 Let me know if you wish me to repost current logs or test new setups. Otherwise I am removing it from my system.
Hit this bug too on ARM
the problem is that we don't know how to solve it (apart of the "env" cleaning hacks)
(In reply to Pacho Ramos from comment #98) > the problem is that we don't know how to solve it (apart of the "env" > cleaning hacks) ahhh... ok. I will poke around some and see if I can find the other couple of projects that solved this problem and give porters to them. It will be after the first of the year at earliest before I would be able to scratch enough time togerther to attemt an actual fix. more later...
See bug 487444, GNU make 4.0 was released. Would be intresting to know if that solves any of this!
Are you still hitting this with 2.2.4 and make-3.82-r4 or newer?
(In reply to Pacho Ramos from comment #101) > Are you still hitting this with 2.2.4 and make-3.82-r4 or newer? Or 2.2.6
neither 2.2.5 nor 2.2.5-r200 work for me. Where is the 2.2.6 ebuild?
OK. I copied ebkit-gtk-2.2.5-r200.ebuild to ebkit-gtk-2.2.6.ebuild (in my local overlay), and using the resultant ebuild I get: ... /var/tmp/portage/net-libs/webkit-gtk-2.2.6/temp/environment: line 4618: RUBY=/usr/bin/ruby20: No such file or directory >>> Source configured. >>> Compiling source in /var/tmp/portage/net-libs/webkit-gtk-2.2.6/work/webkitgtk-2.2.6 ... make -j5 make: execvp: /bin/sh: Argument list too long make: *** [autotoolsconfig.h] Error 127 ... whixh is interesting because: > ls -l /usr/bin/ruby lrwxrwxrwx 1 root root 6 Jan 5 21:26 /usr/bin/ruby -> ruby20* so I think there is an issue with it looking for Ruby (which I have versions versions 18, 19, and 20 installed). Hope that helps...
Please post your current "emerge --info" then as looks like this is really hard to reproduce for us
Created attachment 373368 [details] current emerge info
Looks like it's not fully updated to stable (looks like you have a bit old binutils, kernel, linux-headers... Also: Timestamp of tree: Sun, 17 Feb 2013 02:15:01 +0000 More than one year old
Created attachment 373370 [details] the real current emerge info Sorry, I saved the emerge.info to /root instead of my home directory, and it JUST so happened that I had a very old file by the same name... Attached you will find the current one (and this time I checked the timestamp)
Maybe you could try make-4.0-r1, otherwise, I don't know how to solve this in any way :S
I just updated make: # make --version GNU Make 4.0 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. and then /var/tmp/portage/net-libs/webkit-gtk-2.2.5-r200/temp/environment: line 4629: RUBY=/usr/bin/ruby20: No such file or directory >>> Source configured. >>> Compiling source in /var/tmp/portage/net-libs/webkit-gtk-2.2.5-r200/work/webkitgtk-2.2.5 ... make -j5 /usr/bin/perl -I./Source/WebCore/bindings/scripts Source/WebCore/page/make_settings.pl --input ./Source/WebCore/page/Settings.in --outputDir "./DerivedSources/WebCore" make: execvp: /bin/sh: Argument list too long GNUmakefile:24267: recipe for target 'autotoolsconfig.h' failed make: *** [autotoolsconfig.h] Error 127 * ERROR: net-libs/webkit-gtk-2.2.5-r200::gentoo failed (compile phase): * emake failed ===================================== /var/tmp/portage/net-libs/webkit-gtk-2.2.6-r200/temp/environment: line 4798: RUBY=/usr/bin/ruby20: No such file or directory >>> Source configured. >>> Compiling source in /var/tmp/portage/net-libs/webkit-gtk-2.2.6-r200/work/webkitgtk-2.2.6 ... make -j5 /usr/bin/perl -I./Source/WebCore/bindings/scripts Source/WebCore/page/make_settings.pl --input ./Source/WebCore/page/Settings.in --outputDir "./DerivedSources/WebCore" make: execvp: /bin/sh: Argument list too long GNUmakefile:24273: recipe for target 'autotoolsconfig.h' failed make: *** [autotoolsconfig.h] Error 127 * ERROR: net-libs/webkit-gtk-2.2.6-r200::gentoo failed (compile phase): * emake failed ===================================== I also tried several other versions, but the results are all similar.
(In reply to Pacho Ramos from comment #109) > Maybe you could try make-4.0-r1, otherwise, I don't know how to solve this > in any way :S There's make-3.82-r5 in gnome-overlay that *should* have this bug fixed. It might be that make-4 didn't apply this patch upstream and it's not included in portage.
still no go... GNU Make 3.82 Built for x86_64-pc-linux-gnu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. -------- /var/tmp/portage/net-libs/webkit-gtk-2.2.6-r200/temp/environment: line 4798: RUBY=/usr/bin/ruby20: No such file or directory >>> Source configured. >>> Compiling source in /var/tmp/portage/net-libs/webkit-gtk-2.2.6-r200/work/webkitgtk-2.2.6 ... make -j5 /usr/bin/perl -I./Source/WebCore/bindings/scripts Source/WebCore/page/make_settings.pl --input ./Source/WebCore/page/Settings.in --outputDir "./DerivedSources/WebCore" make: execvp: /bin/sh: Argument list too long make: *** [DerivedSources/WebCore/InternalSettingsGenerated.idl] Error 127 * ERROR: net-libs/webkit-gtk-2.2.6-r200::gentoo failed (compile phase): * emake failed -------- /var/tmp/portage/net-libs/webkit-gtk-2.2.6/temp/environment: line 4801: RUBY=/usr/bin/ruby20: No such file or directory >>> Source configured. >>> Compiling source in /var/tmp/portage/net-libs/webkit-gtk-2.2.6/work/webkitgtk-2.2.6 ... make -j5 make: execvp: /bin/sh: Argument list too long make: *** [autotoolsconfig.h] Error 127 * ERROR: net-libs/webkit-gtk-2.2.6::gentoo failed (compile phase): * emake failed -------- /var/tmp/portage/net-libs/webkit-gtk-2.2.5-r200/temp/environment: line 4629: RUBY=/usr/bin/ruby20: No such file or directory >>> Source configured. >>> Compiling source in /var/tmp/portage/net-libs/webkit-gtk-2.2.5-r200/work/webkitgtk-2.2.5 ... make -j5 make: execvp: /bin/sh: Argument list too long make: *** [autotoolsconfig.h] Error 127 * ERROR: net-libs/webkit-gtk-2.2.5-r200::gentoo failed (compile phase): * emake failed =============== and I gave up there. As a note, the "RUBY=/usr/bin/ruby20: No such file or directory" still bothers me. I doubt that this would have something to do with it, but maybe... What would you like me to try next? It might take me a few days to get back to this... EBo --
I guess /bin/sh is "bash" in your system? Also, try building it with MAKEOPTS=-j1 and post the error with -j1
yes. my shell is bash. MAKEOPTS=-j1: /var/tmp/portage/net-libs/webkit-gtk-2.2.6-r200/temp/environment: line 4798: RUBY=/usr/bin/ruby20: No such file or directory >>> Source configured. >>> Compiling source in /var/tmp/portage/net-libs/webkit-gtk-2.2.6-r200/work/webkitgtk-2.2.6 ... make -j1 /usr/bin/perl -I./Source/WebCore/bindings/scripts Source/WebCore/page/make_settings.pl --input ./Source/WebCore/page/Settings.in --outputDir "./DerivedSources/WebCore" make: execvp: /bin/sh: Argument list too long make: *** [DerivedSources/WebCore/InternalSettingsGenerated.idl] Error 127 * ERROR: net-libs/webkit-gtk-2.2.6-r200::gentoo failed (compile phase): * emake failed is there something else I can try?
@gnome: I propose we close this ticket as newer make are available in tree and I haven't seen this problem be reported against webkit-2.4 and webkit-2.6 switched to cmake and does not show this problem as well.
Sorry for the late reply. THe request got burried under a mountian of emails while I was sick. It builds now. As a note, I uninstalled it from my system over a year ago because of hte problems it was causing, and tweaked the handful of tools which required it to remove the requirement.
(In reply to Gilles Dartiguelongue from comment #115) > @gnome: I propose we close this ticket as newer make are available in tree > and I haven't seen this problem be reported against webkit-2.4 and > webkit-2.6 switched to cmake and does not show this problem as well. 2.4 is still be used by several packages. Hit this bug today: emerge --info Portage 2.2.20 (python 2.7.10-final-0, default/linux/amd64/13.0/desktop/plasma/systemd, gcc-5.1.0, glibc-2.20-r2, 4.0.5 x86_64) ================================================================= System uname: Linux-4.0.5-x86_64-Intel-R-_Core-TM-_i7-3770K_CPU_@_3.50GHz-with-gentoo-2.2 KiB Mem: 16318868 total, 5733756 free KiB Swap: 16777212 total, 16777212 free sh bash 4.3_p39 ld GNU ld (Gentoo 2.25 p1.2) 2.25 ccache version 3.2.2 [disabled] app-shells/bash: 4.3_p39::gentoo dev-java/java-config: 2.2.0::gentoo dev-lang/perl: 5.20.2-r1::gentoo dev-lang/python: 2.7.10::gentoo, 3.2.5-r3::gentoo, 3.3.5-r1::gentoo, 3.4.3::gentoo dev-util/ccache: 3.2.2::gentoo dev-util/cmake: 3.2.3::gentoo dev-util/pkgconfig: 0.28-r3::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.17::gentoo sys-apps/sandbox: 2.6-r1::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r1::gentoo sys-devel/automake: 1.11.6-r1::gentoo, 1.12.6::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.25-r1::gentoo sys-devel/gcc: 4.8.2::gentoo, 4.9.2::gentoo, 5.1.0::gentoo sys-devel/gcc-config: 1.8::gentoo sys-devel/libtool: 2.4.6-r1::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 4.0::gentoo (virtual/os-headers) sys-libs/glibc: 2.20-r2::gentoo Repositories: gentoo location: /var/lib/layman/gentoo-x86 sync-cvs-repo: gentoo-x86 sync-type: cvs sync-uri: cvs://johu@cvs.gentoo.org:/var/cvsroot priority: -1000 johu location: /var/lib/layman/johu masters: gentoo priority: 50 kde location: /var/lib/layman/kde masters: gentoo priority: 50 qt location: /var/lib/layman/qt masters: gentoo priority: 50 steam-overlay location: /var/lib/layman/steam-overlay masters: gentoo priority: 50 Installed sets: @apps, @dev, @gentoo, @kdeapps ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe -ggdb" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/themes/oxygen-gtk/gtk-2.0 /usr/share/themes/oxygen-gtk/gtk-3.0 /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe -ggdb" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs clean-logs collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms sign split-log splitdebug strict test test-fail-continue unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="ftp://ftp.halifax.rwth-aachen.de/gentoo/ http://ftp.halifax.rwth-aachen.de/gentoo/ ftp://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/ http://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/" LANG="de_DE.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac acl acpi alsa amd64 avahi bash-completion bazaar berkdb bluetooth branding btrfs bzip2 cairo cdda cdr cli cracklib crypt cups cvs cxx dbus declarative designer dpi dri dts dvd dvdr egl emboss encode evdev exif fam firefox flac fortran gdbm gif git glamor gpg gpm iconv jpeg kde kipi lcms ldap libav libnotify mad mmx mmxext mng modules mp3 mp4 mpeg multilib mysql ncurses networkmanager nls nptl ogg opengl openmp otr pam pango pcre pdf phonon plasma png policykit ppds pulseaudio qml qt3support qt4 qt5 readline sdl semantic-desktop session slp spell sse sse2 ssl startup-notification subversion svg systemd tcpd telepathy tiff truetype udev udisks unicode upower usb v4l vim-syntax vorbis wayland widgets wxwidgets x264 xcb xcomposite xinerama xml xscreensaver xv xvid zeroconf zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="braindump flow karbon krita sheets stage words" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="emu efi-32 efi-64 pc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="de de_DE" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3 python_3_3" RUBY_TARGETS="ruby20 ruby21 ruby22" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
I am unsure about finally applying the env hack, @gnome team, any ideas? If we finally go with that, please look at: https://github.com/Sabayon/for-gentoo/blob/master/net-libs/webkit-gtk/webkit-gtk-1.6.1-r301.ebuild as it seems that *old* ebuild implemented that and found more variables that needed to be passed to not break things
Created attachment 405418 [details, diff] 1.patch This is a Ubuntu patch for fixing this kind of issue and that can be applied to make-4.1... maybe it should be tried. As a side note, as talked with Johu on IRC, the hacks from sabayon ebuild posted a comment before this are working ok for him (for the case this make patch neither works or cannot be applied for some reason)
(In reply to Pacho Ramos from comment #119) > Created attachment 405418 [details, diff] [details, diff] > 1.patch > > This is a Ubuntu patch for fixing this kind of issue and that can be applied > to make-4.1... maybe it should be tried. > > As a side note, as talked with Johu on IRC, the hacks from sabayon ebuild > posted a comment before this are working ok for him (for the case this make > patch neither works or cannot be applied for some reason) Were you able to finally test it?
