Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 300867 - net-libs/webkit-gtk crash: make argument list is too long
Summary: net-libs/webkit-gtk crash: make argument list is too long
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL: https://bugs.webkit.org/show_bug.cgi?...
Whiteboard:
Keywords: NeedPatch
: 308669 463804 (view as bug list)
Depends on: 301116
Blocks: 469558
  Show dependency tree
 
Reported: 2010-01-13 18:03 UTC by Alexander Vershilov (RETIRED)
Modified: 2015-11-15 14:31 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge info (emerge-info,4.01 KB, text/plain)
2010-01-13 18:04 UTC, Alexander Vershilov (RETIRED)
Details
full build log (build.log,16.12 KB, text/plain)
2010-01-13 19:17 UTC, Alexander Vershilov (RETIRED)
Details
emerge info (emerge_info,5.23 KB, text/plain)
2011-01-05 15:06 UTC, John (EBo) David
Details
build log for 1.4.1-r200 (build.log,18.32 KB, text/plain)
2011-06-13 15:24 UTC, Alexander Vershilov (RETIRED)
Details
environment file for webkit-gtk 1.4.1-r200 (environment,119.38 KB, application/octet-stream)
2011-06-13 15:26 UTC, Alexander Vershilov (RETIRED)
Details
make-3.82-r4.build.log (make-3.82-r4.build.log,22.67 KB, text/plain)
2011-12-04 14:06 UTC, John (EBo) David
Details
webkit-gtk-1.6.1-r301.build.log (webkit-gtk-1.6.1-r301.build.log,19.97 KB, text/plain)
2011-12-04 14:07 UTC, John (EBo) David
Details
new emerge info (emerge.info,5.38 KB, text/plain)
2011-12-04 20:44 UTC, John (EBo) David
Details
build webkit-gtk-1.6.1-r301 with sys-devel/make-3.82-r4 (webkit-gtk-1.6.1-r301.build_log,19.61 KB, text/plain)
2011-12-18 06:16 UTC, John (EBo) David
Details
build webkit-gtk-1.4.3-r300 with sys-devel/make-3.82-r4 (webkit-gtk-1.4.3-r300.build_log,18.94 KB, text/plain)
2011-12-18 06:18 UTC, John (EBo) David
Details
latest emerge info including sys-devel/make-3.82-r4 (emerge_info,5.38 KB, text/plain)
2011-12-18 06:20 UTC, John (EBo) David
Details
current emerge info (emerge.info,5.24 KB, application/x-info)
2014-03-23 22:23 UTC, John (EBo) David
Details
the real current emerge info (emerge.info,5.68 KB, application/x-info)
2014-03-23 22:56 UTC, John (EBo) David
Details
1.patch (1.patch,3.98 KB, patch)
2015-06-20 14:09 UTC, Pacho Ramos
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Vershilov (RETIRED) gentoo-dev 2010-01-13 18:03:30 UTC
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
Comment 1 Alexander Vershilov (RETIRED) gentoo-dev 2010-01-13 18:04:24 UTC
Created attachment 216384 [details]
emerge info
Comment 2 Rafał Mużyło 2010-01-13 18:49:24 UTC
Attach full build log.
Comment 3 Alexander Vershilov (RETIRED) gentoo-dev 2010-01-13 19:17:26 UTC
Created attachment 216392 [details]
full build log
Comment 4 Gilles Dartiguelongue gentoo-dev 2010-01-14 11:00:06 UTC
what is your /bin/sh linking to ?
Comment 5 Alexander Vershilov (RETIRED) gentoo-dev 2010-01-14 11:42:38 UTC
(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. 
Comment 6 Alexander Vershilov (RETIRED) gentoo-dev 2010-01-16 15:36:02 UTC
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.
Comment 7 Priit Laes (IRC: plaes) 2010-02-25 14:58:56 UTC
Could you now try again as sys-devel/make now comes with the patch that should fix the argument list too long issue.
Comment 8 Alexander Vershilov (RETIRED) gentoo-dev 2010-02-25 20:44:18 UTC
(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?
Comment 9 Priit Laes (IRC: plaes) 2010-02-26 05:42:40 UTC
(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.
Comment 10 Pacho Ramos gentoo-dev 2010-03-11 16:05:19 UTC
*** Bug 308669 has been marked as a duplicate of this bug. ***
Comment 11 John (EBo) David 2010-05-15 13:51:03 UTC
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.

Comment 12 Pacho Ramos gentoo-dev 2010-06-18 16:08:56 UTC
Do you suffer the same with 1.2.1?
Comment 13 John (EBo) David 2010-06-19 03:38:44 UTC
yep.  It still fails.
Comment 14 Pacho Ramos gentoo-dev 2010-06-19 11:19:19 UTC
CCing "make" maintainers to try to clarify this a bit :-/
Comment 15 SpanKY gentoo-dev 2010-06-21 00:44:24 UTC
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
Comment 16 jujubickoille 2010-07-18 22:14:05 UTC
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
Comment 17 John (EBo) David 2010-07-18 22:25:20 UTC
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?

Comment 18 jujubickoille 2010-07-19 04:51:25 UTC
(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
Comment 19 Pacho Ramos gentoo-dev 2010-07-19 18:13:38 UTC
Does webkitgtk compile ok when compiling it manually on your home for example? (./configure && make)
Comment 20 Alexander Vershilov (RETIRED) gentoo-dev 2010-07-19 18:36:09 UTC
> 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.
Comment 21 Pacho Ramos gentoo-dev 2010-07-19 18:40:18 UTC
(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
Comment 22 Zac Medico gentoo-dev 2010-07-19 23:35:50 UTC
(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.
Comment 23 Pacho Ramos gentoo-dev 2010-07-20 16:35:15 UTC
(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? :-/ 
Comment 24 Priit Laes (IRC: plaes) 2010-07-20 16:40:51 UTC
(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
Comment 25 Pacho Ramos gentoo-dev 2010-07-20 17:03:32 UTC
But looks like "more reduction" is still required :-(
Comment 26 Zac Medico gentoo-dev 2010-07-20 23:44:23 UTC
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.
Comment 27 John (EBo) David 2010-07-23 05:04:05 UTC
is there a new version of the ebuilds for testing?  The one updated last week is still busted.
Comment 28 Nikolaj Šujskij 2010-12-23 12:20:48 UTC
Could the issue be fixed in changes due to https://bugs.gentoo.org/show_bug.cgi?id=343249 ?
Comment 29 Gilles Dartiguelongue gentoo-dev 2010-12-23 13:04:59 UTC
most likely not.
Comment 30 Pacho Ramos gentoo-dev 2011-01-04 21:59:13 UTC
Are you still able to reproduce with 1.2.6? In that case, please try changes suggested in comment #15
Comment 31 John (EBo) David 2011-01-04 22:22:58 UTC
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.  
Comment 32 Pacho Ramos gentoo-dev 2011-01-05 10:47:07 UTC
I added it some hours ago ;-)
Comment 33 John (EBo) David 2011-01-05 15:03:40 UTC
>>> 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.
Comment 34 John (EBo) David 2011-01-05 15:06:01 UTC
Created attachment 258932 [details]
emerge info
Comment 35 John (EBo) David 2011-01-10 15:06:28 UTC
There was an update to the 1.2.6 ebuild today (Jan 10, 2011).  It still dies with the "Argument list too long" error
Comment 36 Pacho Ramos gentoo-dev 2011-01-11 13:27:52 UTC
Maybe people hits this when compiling using emerge instead of manually compiling because makefiles are regenerated due eautoreconf, could you try skipping eautoreconf?
Comment 37 Pacho Ramos gentoo-dev 2011-01-27 18:32:44 UTC
(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?
Comment 38 John (EBo) David 2011-01-28 01:40:16 UTC
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 --
Comment 39 John (EBo) David 2011-01-28 03:05:31 UTC
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.
Comment 40 Pacho Ramos gentoo-dev 2011-01-28 11:33:41 UTC
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 :-/
Comment 41 John (EBo) David 2011-01-28 13:45:05 UTC
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.
Comment 42 Zac Medico gentoo-dev 2011-01-29 20:54:59 UTC
(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?
Comment 43 John (EBo) David 2011-01-29 21:24:15 UTC
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.
Comment 44 Alexander Vershilov (RETIRED) gentoo-dev 2011-01-29 21:56:24 UTC
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. 
Comment 45 John (EBo) David 2011-01-29 22:07:34 UTC
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?
Comment 46 Pacho Ramos gentoo-dev 2011-06-13 14:20:56 UTC
Please retry with 1.4.1-r200
Comment 47 Alexander Vershilov (RETIRED) gentoo-dev 2011-06-13 15:04:49 UTC
(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
Comment 48 Pacho Ramos gentoo-dev 2011-06-13 15:12:16 UTC
Attach both please as generated by emerge when failing
Comment 49 Alexander Vershilov (RETIRED) gentoo-dev 2011-06-13 15:24:32 UTC
Created attachment 276923 [details]
build log for 1.4.1-r200
Comment 50 Alexander Vershilov (RETIRED) gentoo-dev 2011-06-13 15:26:25 UTC
Created attachment 276927 [details]
environment file for webkit-gtk 1.4.1-r200
Comment 51 Gilles Dartiguelongue gentoo-dev 2011-06-14 08:57:00 UTC
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 :(.
Comment 52 Pacho Ramos gentoo-dev 2011-06-19 10:43:18 UTC
(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...)
Comment 53 Pacho Ramos gentoo-dev 2011-11-21 23:48:34 UTC
Is this still valid with 1.6.x?
Comment 54 John (EBo) David 2011-11-22 03:06:32 UTC
(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.
Comment 55 Pacho Ramos gentoo-dev 2011-11-29 13:27:21 UTC
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 :(
Comment 56 John (EBo) David 2011-11-30 05:39:56 UTC
(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.
Comment 57 Pacho Ramos gentoo-dev 2011-12-02 21:20:35 UTC
Upstream blames on our make:
https://bugs.webkit.org/show_bug.cgi?id=62543#c2
Comment 58 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-12-02 23:07:44 UTC
(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...
Comment 59 SpanKY gentoo-dev 2011-12-03 00:01:47 UTC
we already had that patch in make-3.81.  it was dropped because it was supposed to be integrated into make-3.82.
Comment 60 SpanKY gentoo-dev 2011-12-03 00:57:27 UTC
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)
Comment 61 John (EBo) David 2011-12-03 02:57:19 UTC
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.
Comment 62 Pacho Ramos gentoo-dev 2011-12-03 11:47:38 UTC
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 :/
Comment 63 Fabian Groffen gentoo-dev 2011-12-03 12:40:36 UTC
Cleaning the environment is not the right solution.  Let's try make 3.82-r4.
Comment 64 John (EBo) David 2011-12-03 19:33:08 UTC
(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.
Comment 65 SpanKY gentoo-dev 2011-12-04 05:19:29 UTC
unfortunately, i think you missed the counter point.  test the fix *already in the tree* and report back.
Comment 66 John (EBo) David 2011-12-04 05:53:06 UTC
(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.
Comment 67 Pacho Ramos gentoo-dev 2011-12-04 09:03:54 UTC
Please provide updated build.log when failing with make-3.82-r4
Comment 68 Geoff Madden 2011-12-04 09:40:28 UTC
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 69 Geoff Madden 2011-12-04 09:43:02 UTC
comment  #68 additional this is webkit-gtk-1.6.1-r300
Comment 70 Geoff Madden 2011-12-04 09:50:09 UTC
(In reply to comment #69)
> comment  #68 additional this is webkit-gtk-1.6.1-r201 on my x86_64
Comment 71 John (EBo) David 2011-12-04 14:06:26 UTC
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.
Comment 72 John (EBo) David 2011-12-04 14:07:56 UTC
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.
Comment 73 John (EBo) David 2011-12-04 14:11:10 UTC
(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.
Comment 74 Pacho Ramos gentoo-dev 2011-12-04 19:14:58 UTC
(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?
Comment 75 John (EBo) David 2011-12-04 20:43:41 UTC
"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
Comment 76 John (EBo) David 2011-12-04 20:44:48 UTC
Created attachment 294787 [details]
new emerge info
Comment 77 Pacho Ramos gentoo-dev 2011-12-05 11:31:50 UTC
"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 ;)
Comment 78 John (EBo) David 2011-12-05 12:47:49 UTC
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.
Comment 79 John (EBo) David 2011-12-18 06:16:55 UTC
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
Comment 80 John (EBo) David 2011-12-18 06:18:39 UTC
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
Comment 81 John (EBo) David 2011-12-18 06:20:15 UTC
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
Comment 82 John (EBo) David 2011-12-18 06:24:49 UTC
(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.
Comment 83 Pacho Ramos gentoo-dev 2012-01-04 10:55:20 UTC
did you try to apply changes suggested in comment #15?
Comment 84 Flo Gravo 2012-10-10 09:53:26 UTC
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
Comment 85 Priit Laes (IRC: plaes) 2012-10-10 10:22:17 UTC
(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
Comment 86 Flo Gravo 2012-10-10 11:44:19 UTC
# cat /var/db/pkg/sys-devel/make-3.82-r4/repository 
gentoo
Comment 87 Priit Laes (IRC: plaes) 2012-10-10 11:57:22 UTC
(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 ;)
Comment 88 Priit Laes (IRC: plaes) 2012-10-10 14:26:52 UTC
(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.
Comment 89 SpanKY gentoo-dev 2012-10-11 05:12:56 UTC
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.
Comment 90 Priit Laes (IRC: plaes) 2012-10-11 06:27:04 UTC
(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
Comment 91 SpanKY gentoo-dev 2012-10-11 15:42:46 UTC
(In reply to comment #90)

that's the patch that was originally in 3.82-r4 and people said didn't work
Comment 92 Priit Laes (IRC: plaes) 2012-10-11 17:02:54 UTC
(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
Comment 93 SpanKY gentoo-dev 2012-10-12 18:46:29 UTC
(In reply to comment #92)

that may be, but read this bug and the feedback people here have given
Comment 94 John (EBo) David 2012-10-22 08:31:31 UTC
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.
Comment 95 Pacho Ramos gentoo-dev 2013-03-30 15:12:14 UTC
*** Bug 463804 has been marked as a duplicate of this bug. ***
Comment 96 John (EBo) David 2013-09-09 00:27:17 UTC
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.
Comment 97 Sergey Popov gentoo-dev 2013-09-19 08:46:46 UTC
Hit this bug too on ARM
Comment 98 Pacho Ramos gentoo-dev 2013-09-19 19:50:21 UTC
the problem is that we don't know how to solve it (apart of the "env" cleaning hacks)
Comment 99 John (EBo) David 2013-09-19 20:02:45 UTC
(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...
Comment 100 Samuli Suominen (RETIRED) gentoo-dev 2013-10-09 17:14:24 UTC
See bug 487444, GNU make 4.0 was released. Would be intresting to know if that solves any of this!
Comment 101 Pacho Ramos gentoo-dev 2014-02-02 14:01:05 UTC
Are you still hitting this with 2.2.4 and make-3.82-r4 or newer?
Comment 102 Pacho Ramos gentoo-dev 2014-03-23 15:37:33 UTC
(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
Comment 103 John (EBo) David 2014-03-23 20:17:15 UTC
neither 2.2.5 nor 2.2.5-r200 work for me.  Where is the 2.2.6 ebuild?
Comment 104 John (EBo) David 2014-03-23 20:28:12 UTC
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...
Comment 105 Pacho Ramos gentoo-dev 2014-03-23 22:06:37 UTC
Please post your current "emerge --info" then as looks like this is really hard to reproduce for us
Comment 106 John (EBo) David 2014-03-23 22:23:34 UTC
Created attachment 373368 [details]
current emerge info
Comment 107 Pacho Ramos gentoo-dev 2014-03-23 22:41:09 UTC
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
Comment 108 John (EBo) David 2014-03-23 22:56:39 UTC
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)
Comment 109 Pacho Ramos gentoo-dev 2014-03-24 21:08:28 UTC
Maybe you could try make-4.0-r1, otherwise, I don't know how to solve this in any way :S
Comment 110 John (EBo) David 2014-03-25 02:36:23 UTC
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.
Comment 111 Priit Laes (IRC: plaes) 2014-03-25 06:29:31 UTC
(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.
Comment 112 John (EBo) David 2014-03-25 06:57:52 UTC
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 --
Comment 113 Pacho Ramos gentoo-dev 2014-03-25 07:07:14 UTC
I guess /bin/sh is "bash" in your system? Also, try building it with MAKEOPTS=-j1 and post the error with -j1
Comment 114 John (EBo) David 2014-03-25 07:15:19 UTC
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?
Comment 115 Gilles Dartiguelongue gentoo-dev 2015-05-01 11:05:35 UTC
@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.
Comment 116 John (EBo) David 2015-05-07 20:48:38 UTC
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.
Comment 117 Johannes Huber gentoo-dev 2015-06-20 11:01:01 UTC
(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
Comment 118 Pacho Ramos gentoo-dev 2015-06-20 11:50:18 UTC
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
Comment 119 Pacho Ramos gentoo-dev 2015-06-20 14:09:20 UTC
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)
Comment 120 Pacho Ramos gentoo-dev 2015-07-13 10:19:28 UTC
(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?