Created attachment 384890 [details] emerge --info output During the install step the build attempts to link with -lgedit, libgedit.so is installed in /usr/lib/gedit by the package, however it has not been installed at this point. ar cru /usr/lib/libgedit.a fixes the problem (note: in root, not in the image/ sandbox). I deduce the install step will only work if gedit is already installed.
Created attachment 384892 [details] complete build log
Created attachment 384894 [details] environment
Created attachment 384896 [details] emerge -pqv output [ebuild N ] app-editors/gedit-3.12.2 USE="introspection python spell {-test} -zeitgeist" PYTHON_TARGETS="python3_3 (-python3_2)"
Are you able to reproduce? It could be a parallel install problem (using MAKEOPTS="-j1" would workaround it)
It may be a parallel build problem, however the work round I gave caused the failing link step to succeed, so the -lgedit on that link line is apparently unnecessary (since an empty static library doesn't result in missing symbols!) Here's what I did: 1) I tried to "emerge gnome" several times, it failed at gedit each time although, because of the //make several new packages got added each time. 2) Eventually I managed to emerge everything except gedit and gnome-core-apps. 3) Using ebuild I attempted to run the "install" step using the WORKDIR from the last failing run; the "install" failed again. 4) I did a "touch /usr/lib/gedit/libgedit.a" and re-ran install. It failed again but this time it reported a corrupt (zero length) libgedit.a. 5) I used "ar cru" instead and "install" succeeded. 6) I ran "qmerge" then finished with "emerge gnome". 7) I re-ran "ebuild install" on the gedit WORKDIR and it succeeded. 8) I filed this bug. 9) This morning (I still have the WORKDIR) I checked "ebuild install" again and it still works. 10) I moved libgedit.so (the file that is actually installed) to Xlibgedit.so, re-ran "ebuild install" *AND* it still worked. So this does, indeed, suggest the problem is exposed by the //make (-j5 -l1; it's a Raspbery Pi running distcc). I'll investigate some more to see if a complete "emerge unmerge" re-introduces the issue.
So now I did: $ emerge uninstall gedit $ rm /var/tmp/portage/app-editors/gedit-3.12.2/.installed $ ebuild gedit-3.12.2 install and it works "just fine". The only change from the previous reproducible failure system (it happened maybe 10 times before I came up with the ar crc fix) is that I completed the gnome installation; specifically I installed empathy and totem by emerge --oneshot, I still had the problem, then I completed emerge gnome which gave me gnome-core-apps and gnome. Since that very last step I haven't been able to repro the problem. I'll attach the build.log from the succeeding install (BTW, I think the previous attached 'complete build log' is actually just from ebuild install because ebuild does not append to the build log.)
Created attachment 384942 [details] build.log from successful ebuild install This is temp/build.log after ebuild install, previous build.log was deleted before running ebuild.
Created attachment 384944 [details] build.log from failed ebuild install step This is the part of "complete build.log" corresponding to the failed install step (from the end) for comparision with succeed-build.log
If you run kdiff3 on fail-build.log, succeed-build.log you can see that the problem does seem to be a changed order of the relink of libdocinfo.so with respect to other components. In both cases the relink of libdocinfo.so follows the install of libgedit.so in the log file, but in the success case a whole load of "byte compiles" seem to be going on in parallel. Nevertheless I still assert that the actual bug is a spurious dependency of the relink of libdocinfo.so on -lgedit.
I ran into same problem with new system build up from stage 3 to gnome-light. Workaround helped.
*** Bug 556218 has been marked as a duplicate of this bug. ***
At least with 3.16.3 it looks to work (also when there is no gedit installed in the system before)
(In reply to Pacho Ramos from comment #12) > At least with 3.16.3 it looks to work (also when there is no gedit installed > in the system before)
Created attachment 528958 [details] app-editors/gedit-3.22.1 build log This bug is over 3 years old and is marked RESOLVED - which I guess makes it a prime candidate for me to run into today. Re-emerging with MAKEOPTS="-j1" did work around it successfully, so I guess that means the root-cause parallel make failure still exists...?
Created attachment 528960 [details] emerge --info
It's not *really* a parallel build problem; the issue is that docinfo.so spuriously includes -lgedit on the link line when it doesn't actually *need* it. So the spurious -lgedit introduces an unnecessary dependency (on the installation of libgedit) which is not present in the make system. Since it can only happen once (before libgedit is installed in root for the first time) changing the whole build to be single-threaded is not the right work round; just create the (empty) library in root. Resolving it as "unconfirmed" or as "test-request" is, of course, wrong; if the maintainer doesn't want to fix it just resolve it as "wontfix" and document the work round. John Bowler
