fixes for silly build scripts of upstream version: 0) parallel build permanently fail (even w/ enabled dependency tracking, maybe because of --enable-silent-rules I have in EXTRA_ECONF as well) due incorrect usage of BUILT_SOURCES feature of automake. unfortunately my fixes still not allow to generate a bunch of sources in parallel (cuz insane^W developers wanted to build libWTF using it) but everything else (libs) can be build in parallel (yeah, even w/ dependency tracking turned OFF) 1) also here is a fix for nasty warning about redefinition of _FORTIFY_SOURCE when build w/ >=gcc-4.8 2) also added a fix for configure w/ ruby21 as the only enabled RUBY_TARGETS Reproducible: Always now I can successfully build this package w/ EXTRA_ECONF='--disable-dependency-traking --enable-silent-rules' and w/ `-j4` in my make options
Created attachment 369492 [details, diff] patch for ebuild w/ 3 fixes
Created attachment 369494 [details, diff] patch for insane build scripts to apply before configure
Created attachment 369496 [details, diff] patch for insane build scripts to apply before configure
(In reply to Alex Turbov from comment #0) > fixes for silly build scripts of upstream version: > 0) parallel build permanently fail (even w/ enabled dependency tracking, > maybe because of --enable-silent-rules I have in EXTRA_ECONF as well) due > incorrect usage of BUILT_SOURCES feature of automake. unfortunately my fixes > still not allow to generate a bunch of sources in parallel (cuz insane^W > developers wanted to build libWTF using it) but everything else (libs) can > be build in parallel (yeah, even w/ dependency tracking turned OFF) I don't suffer this parallel build issue, maybe because I don't force --enable-silent-rules. But I see you "fix" this building all-built-sources-local with -j1 and, then, I doubt what option is better: 1. Build sources-local with -j1 to allow --enable-silent-rules 2. Build all in parallel without allowing silent rules Personally, I would still prefer the second option as I think I can live without silent-rules for this case (also, we don't want silent-rules as discussed time ago and as eapi5 will force, see bug 429308) > 1) also here is a fix for nasty warning about redefinition of > _FORTIFY_SOURCE when build w/ >=gcc-4.8 Could you report this to upstream for not need to carry this forever? -> bugs.webkit.org > 2) also added a fix for configure w/ ruby21 as the only enabled RUBY_TARGETS > > The same :) Thanks
(In reply to Pacho Ramos from comment #4) > (In reply to Alex Turbov from comment #0) > > fixes for silly build scripts of upstream version: > > 0) parallel build permanently fail (even w/ enabled dependency tracking, > > maybe because of --enable-silent-rules I have in EXTRA_ECONF as well) due > > incorrect usage of BUILT_SOURCES feature of automake. unfortunately my fixes > > still not allow to generate a bunch of sources in parallel (cuz insane^W > > developers wanted to build libWTF using it) but everything else (libs) can > > be build in parallel (yeah, even w/ dependency tracking turned OFF) > > I don't suffer this parallel build issue, maybe because I don't force > --enable-silent-rules. But I see you "fix" this building > all-built-sources-local with -j1 and, then, I doubt what option is better: > 1. Build sources-local with -j1 to allow --enable-silent-rules `all-built-sources-local' is a target (just) to generate all files mentioned in automakes' BUILT_SOURCES variable. unfortunately crazy upstream devs build a small lib at this moment as well, it is why this stage can't be parallel (due not all required files are generated yet). And `--enable-dependency-tracking' option just work, because before build everything, it generates all that files (in a single thread as well, because running from ./configure). But later it leads to generation of useless, for a single time build, *.d files (w/ -MD -MP -MF compiler options), which are consume CPU, disk I/O and time (multiplying to a number of files compiled and .d files size, it will be quite noticeable I guess). My fix (which is a real fix, btw) allows to compile this package w/o enabled dependency tracking (as well as w/ --enable-silent-rules which dramatically reduce amount of useless info, printed while compiling, which is also reduce compilation time! (because printing so much text to a console is far from fast operation, especially to a graphical one)). so when `all-built-sources-local' completed, everything else (the major part) will be build in parallel (w/o wasting resources)... > 2. Build all in parallel without allowing silent rules again, my patch do not prevent parallel build! > Personally, I would still prefer the second option as I think I can live > without silent-rules for this case (also, we don't want silent-rules as > discussed time ago and as eapi5 will force, see bug 429308) silent rules is a part of the problem: the bigger disadvantage is inability to disable dependency tracking when it definitely wasting of resources... > > > 1) also here is a fix for nasty warning about redefinition of > > _FORTIFY_SOURCE when build w/ >=gcc-4.8 > > Could you report this to upstream for not need to carry this forever? -> > bugs.webkit.org can you? %) > > > 2) also added a fix for configure w/ ruby21 as the only enabled RUBY_TARGETS > > > > > > The same :) what "the same"??
I fixed the ruby21 stuff, sorry for that. I'll review the rest later.
(In reply to Alex Turbov from comment #5) [...] > `all-built-sources-local' is a target (just) to generate all files mentioned > in automakes' BUILT_SOURCES variable. unfortunately crazy upstream devs > build a small lib at this moment as well, it is why this stage can't be > parallel (due not all required files are generated yet). And > `--enable-dependency-tracking' option just work, because before build > everything, it generates all that files (in a single thread as well, because > running from ./configure). But later it leads to generation of useless, for > a single time build, *.d files (w/ -MD -MP -MF compiler options), which are > consume CPU, disk I/O and time (multiplying to a number of files compiled > and .d files size, it will be quite noticeable I guess). My fix (which is a > real fix, btw) allows to compile this package w/o enabled dependency > tracking (as well as w/ --enable-silent-rules which dramatically reduce > amount of useless info, printed while compiling, which is also reduce > compilation time! (because printing so much text to a console is far from > fast operation, especially to a graphical one)). > > so when `all-built-sources-local' completed, everything else (the major > part) will be build in parallel (w/o wasting resources)... > Thanks for the explanation :) [...] > > > 1) also here is a fix for nasty warning about redefinition of > > > _FORTIFY_SOURCE when build w/ >=gcc-4.8 > > > > Could you report this to upstream for not need to carry this forever? -> > > bugs.webkit.org > > can you? %) Yeah, but I usually prefer people providing the patches to report directly as they will know better what to modify if upstream wants to modify it in some way :/ > > > > > > 2) also added a fix for configure w/ ruby21 as the only enabled RUBY_TARGETS > > > > > > > > > > The same :) > > what "the same"?? Sorry, my fault ;)
Is there anything pending for 2.4.4? Related with parallel build issues I doubt upstream will care due they moving to cmake for next cycle, but the fix for gcc-4.8 could have been included there (or made obsolete)
I can't waste my time for doing patches that do not go into the tree...
I've read the bug report and really don't understand how to resolve the emerge problem. I'm using ruby (* dev-lang/ruby 2.1.2) and rubygems (7) along with a ruby java. I really don't want to upgrade to gcc. I've done everything I could think of to resolve this problem. I don't understand because http://packages.gentoo.org/package/net-libs/webkit-gtk indicates it's stable. Please throw me a spoon fed bone. erivedSources/JavaScriptCore/LLIntDesiredOffsets.h /usr/lib64/ruby/2.1.0/rubygems.rb:15:in `require': cannot load such file -- rubygems/compatibility (LoadError) from /usr/lib64/ruby/2.1.0/rubygems.rb:15:in `<top (required)>' from <internal:gem_prelude>:1:in `require' from <internal:gem_prelude>:1:in `<compiled>' make: *** [DerivedSources/JavaScriptCore/LLIntDesiredOffsets.h] Error 1 * ERROR: net-libs/webkit-gtk-2.4.4-r200::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=net-libs/webkit-gtk-2.4.4-r200::gentoo'`, * the complete build log and the output of `emerge -pqv '=net-libs/webkit-gtk-2.4.4-r200::gentoo'`. * The complete build log is located at '/var/tmp/portage/net-libs/webkit-gtk-2.4.4-r200/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-libs/webkit-gtk-2.4.4-r200/temp/environment'. * Working directory: '/var/tmp/portage/net-libs/webkit-gtk-2.4.4-r200/work/webkitgtk-2.4.4' * S: '/var/tmp/portage/net-libs/webkit-gtk-2.4.4-r200/work/webkitgtk-2.4.4' >>> Failed to emerge net-libs/webkit-gtk-2.4.4-r200, Log file: >>> '/var/tmp/portage/net-libs/webkit-gtk-2.4.4-r200/temp/build.log' * Messages for package net-libs/webkit-gtk-2.4.4-r200: * ERROR: net-libs/webkit-gtk-2.4.4-r200::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=net-libs/webkit-gtk-2.4.4-r200::gentoo'`, * the complete build log and the output of `emerge -pqv '=net-libs/webkit-gtk-2.4.4-r200::gentoo'`. * The complete build log is located at '/var/tmp/portage/net-libs/webkit-gtk-2.4.4-r200/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-libs/webkit-gtk-2.4.4-r200/temp/environment'. * Working directory: '/var/tmp/portage/net-libs/webkit-gtk-2.4.4-r200/work/webkitgtk-2.4.4' * S: '/var/tmp/portage/net-libs/webkit-gtk-2.4.4-r200/work/webkitgtk-2.4.4'
closing as original bugs/patches are obsolete. For next time sending one issue per bug will surely help :/
