Summary: | x11-libs/openmotif-2.3.3 with USE=examples: uil segfaults or aborts with "Severe: internal error" during install phase | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Stephen Lewis <lewis+gentoo> |
Component: | [OLD] Library | Assignee: | Ulrich Müller <ulm> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | bjoern.michaelsen, jcdemay, phajdan.jr |
Priority: | Normal | Keywords: | REGRESSION |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
full build.log
Patch for openmotif-2.3.3.ebuild |
Description
Stephen Lewis
2011-02-21 06:42:07 UTC
Created attachment 263251 [details]
full build.log
Does it still fail if you remove sandbox from FEATURES? Looks like it changed the error message but still fails in the same place, # FEATURES="-sandbox" emerge --verbose openmotif # tail -35 /var/tmp/portage/x11-libs/openmotif-2.3.3/temp/build.log make[1]: Entering directory `/var/tmp/portage/x11-libs/openmotif-2.3.3/work/openmotif-2.3.3/demos/programs' Making install-data in airport make[2]: Entering directory `/var/tmp/portage/x11-libs/openmotif-2.3.3/work/openmotif-2.3.3/demos/programs/airport' test -z "/usr/share/Xm/airport" || /bin/mkdir -p "/var/tmp/portage/x11-libs/openmotif-2.3.3/image//usr/share/Xm/airport" /usr/bin/install -c -m 644 main.c dragsource.c dropsite.c airport.h dragsource.h dropsite.h main.h Imakefile XmdAirport.ad README '/var/tmp/portage/x11-libs/openmotif-2.3.3/image//usr/share/Xm/airport' make[2]: Leaving directory `/var/tmp/portage/x11-libs/openmotif-2.3.3/work/openmotif-2.3.3/demos/programs/airport' Making install-data in animate make[2]: Entering directory `/var/tmp/portage/x11-libs/openmotif-2.3.3/work/openmotif-2.3.3/demos/programs/animate' ../../../clients/uil/uil -o dog.uid dog.uil -I./../../../clients/uil -I../../../clients/uil ../../../clients/uil/uil -o plane.uid plane.uil -I./../../../clients/uil -I../../../clients/uil ../../../clients/uil/uil -o superman.uid superman.uil -I./../../../clients/uil -I../../../clients/uil ../../../clients/uil/uil -o xmanimate.uid xmanimate.uil -I./../../../clients/uil -I../../../clients/uil Severe: internal error - submit defect report make[2]: *** [xmanimate.uid] Error 1 make[2]: Leaving directory `/var/tmp/portage/x11-libs/openmotif-2.3.3/work/openmotif-2.3.3/demos/programs/animate' make[1]: *** [install-data-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/x11-libs/openmotif-2.3.3/work/openmotif-2.3.3/demos/programs' make: *** [install-data-recursive] Error 1 make: Leaving directory `/var/tmp/portage/x11-libs/openmotif-2.3.3/work/openmotif-2.3.3/demos' emake failed * ERROR: x11-libs/openmotif-2.3.3 failed: * installation of demos failed * * Call stack: * ebuild.sh, line 56: Called src_install * environment, line 3279: Called die * The specific snippet of code: * emake -j1 -C demos DESTDIR="${D}" install-data || die "installation of demos failed"; * * If you need support, post the output of 'emerge --info =x11-libs/openmotif-2.3.3', * the complete build log and the output of 'emerge -pqv =x11-libs/openmotif-2.3.3'. * The complete build log is located at '/var/tmp/portage/x11-libs/openmotif-2.3.3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/x11-libs/openmotif-2.3.3/temp/environment'. * S: '/var/tmp/portage/x11-libs/openmotif-2.3.3/work/openmotif-2.3.3' This looks vaguely similar to bug 312719. Unfortunately, I cannot reproduce the problem here (on amd64 though). I agree it does seem to be the same bug as 312719 and I am mystified but here are a few more findings. First, I do not think it is a Gentoo problem, I think it is upstream. I can get similar results using the original tarball. It appears to be a bug in the 'uil' compiler and is either related to the stack, or possibly environment variables. I was able to get the package to emerge successfully by typing the EXACT line which fails from within 'make' (as reported in 312719) for each failure that occurs during the emerge, so if I cd to the directory where the error occurred and type 'make -n' I get this: animate # make -n ../../../clients/uil/uil -o xmanimate.uid xmanimate.uil -I./../../../clients/uil -I../../../clients/uil If I now type 'make' it fails but if I copy/paste above command it works!!! It even works if I type '$(make -n)' So 'uil' can be induced to fail depending upon the environment from which it was invoked. Commandline - OK, from 'make' - NOT OK. This is also true for each subsequent failure in: $(work)/openmotif-2.3.3/demos/programs/animate $(work)/openmotif-2.3.3/demos/programs/hellomotif $(work)/openmotif-2.3.3/demos/programs/hellomotifi18n after which the rest compile and install correctly. While trying various combinations of environment and stack I discovered a way to make the emerge proceed all the way to the end without any failures but am at a loss to explain why this might work. If I use 'ulimit' to increase the stack size there is no change. # ulimit -s unlimited - make still fails as before BUT if I reduce the limit back to '8192' the default then 'make' works, ie 'uil' no longer fails. This is true even if I do not increase the stack first. Merely using the command 'ulimit -s 8192' before emerging openmotif causes the emerge to be successful. even though 8192 is the default. It makes little sense to me but might help someone else figure it out... I face the very same issue and I confirm everything Stephen Lewis said except that for me it happens on my x86 system. However, it does not on my amd64 system which make.conf is identical except for CHOST and -march. *** Bug 312719 has been marked as a duplicate of this bug. *** *** Bug 397521 has been marked as a duplicate of this bug. *** Created attachment 297853 [details, diff]
Patch for openmotif-2.3.3.ebuild
Sorry for the long hiatus.
This could be a parser issue. openmotif-2.3.2 came with parsers pre-built with byacc, whereas 2.3.3 changed to bison.
Please test if applying attached patch to the ebuild fixes the problem.
(In reply to comment #9) > Please test if applying attached patch to the ebuild fixes the problem. I've committed this as openmotif-2.3.3-r1. Please test. (In reply to comment #10) > (In reply to comment #9) > > Please test if applying attached patch to the ebuild fixes the problem. > > I've committed this as openmotif-2.3.3-r1. > Please test. Now I can't reproduce even with openmotif-2.3.3, weird. (In reply to comment #10) > (In reply to comment #9) > > Please test if applying attached patch to the ebuild fixes the problem. > > I've committed this as openmotif-2.3.3-r1. > Please test. Now I can't reproduce even with openmotif-2.3.3, weird. (In reply to comment #9) > Created attachment 297853 [details, diff] [details, diff] > Patch for openmotif-2.3.3.ebuild > > Sorry for the long hiatus. > > This could be a parser issue. openmotif-2.3.2 came with parsers pre-built with > byacc, whereas 2.3.3 changed to bison. > > Please test if applying attached patch to the ebuild fixes the problem. Sorry for delay, I was out of town last week... The bug no longer manifests for me either... I can successfully emerge both 2.3.3 and 2.3.3-r1 *with* USE="examples" with no error Note however that many things have changed since bug was reported. Versions of 'make' and 'gcc' and kernel have all changed. My vote would be to leave 2.3.3 as is and mark bug as OBSOLETE unless it is seen again, Stephen Lewis (In reply to comment #13) > The bug no longer manifests for me either... > I can successfully emerge both 2.3.3 and 2.3.3-r1 *with* USE="examples" with > no error Good. Thanks for testing. > Note however that many things have changed since bug was reported. Versions > of 'make' and 'gcc' and kernel have all changed. Yes, I'm aware of this. OTOH, there was never a problem with 2.3.2, but only with 2.3.3. The source code in the relevant tools/wml and clients/uil subdirectories is identical in both versions. The only thing that is different is the parser generator used, which was changed from byacc to bison -y. Then there's the following comment in configure.ac, and I believe that it was put there for a reason: dnl AC_PROG_YACC dnl Do this the old fashioned way. 'bison -y' doesn't cut it AC_CHECK_PROGS(YACC, byacc, yacc) > My vote would be to leave 2.3.3 as is and mark bug as OBSOLETE unless it is > seen again, Closing as WORKSFORME. |