dev-lang/gnat-3.45 emerge gnat fails due to a script error if the account's default shell (typically root) is not a bourne shell (e.g. tcsh). Workaround (not to be confused with a fix of the problem): (setenv SHELL /bin/sh ; emerge gnat) Reproducible: Always Steps to Reproduce: 1. set shell of root account to /bin/tcsh 2. login (or change SHELL environment variable) 3. emerge gnat Actual Results: [...] constructing ../fixinc.sh for i686-pc-linux-gnu to run on i686-pc-linux-gnu make TARGETS=oneprocess SHELL="/bin/tcsh" CC="/var/tmp/portage/dev-lang/gnat-3.45/work/usr/bin/gcc" CFLAGS=" -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE" LDFLAGS="" LIBERTY="/var/tmp/portage/dev-lang/gnat-3.45/work/build/gcc/../libiberty/libiberty.a" install-bin make[3]: Entering directory `/var/tmp/portage/dev-lang/gnat-3.45/work/build/gcc/fixinc' /bin/tcsh /var/tmp/portage/dev-lang/gnat-3.45/work/gcc-3.4.5/gcc/fixinc/genfixes machname.h SHELL=/bin/sh: Command not found. export: Command not found. if: Expression Syntax. make[3]: *** [machname.h] Error 1 make[3]: Leaving directory `/var/tmp/portage/dev-lang/gnat-3.45/work/build/gcc/fixinc' make[2]: *** [fixinc.sh] Error 2 make[2]: Leaving directory `/var/tmp/portage/dev-lang/gnat-3.45/work/build/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/var/tmp/portage/dev-lang/gnat-3.45/work/build/gcc' make: *** [bootstrap] Error 2 !!! ERROR: dev-lang/gnat-3.45 failed. Call stack: ebuild.sh, line 1614: Called dyn_compile ebuild.sh, line 971: Called qa_call 'src_compile' environment, line 3314: Called src_compile gnat-3.45.ebuild, line 120: Called die !!! bootstrap failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/dev-lang/gnat-3.45/temp/build.log'. It is possible that an emerge of other packages from a C shell will fail as well. I have seen some script related errors when I did an emerge world recently, but due to lack of time I "fixed" the issue by ditching packages and focusing on those packages which are most important to me.
Having a C-shell variant as the default shell of your root account will cause all sorts of problems. The assumption that the root shell is sh is far too widespread to consider changing it, or to consider supporting anything else. This is not GNAT-specific - the gcc build will fall over in any number of places, if SHELL does not support Bourne shell syntax and semantics. I would expect any number of other packages will also fail.
Also, you shouldn't be installing the dev-lang/gnat. Please use gnat-gcc or gnat-gpl instead (they even can be installed in parallel). This will likely not so anything about this shell issue, but at least you will be using the supported compiler. Sorry about this confusion. I was sure dev-lang/gnat was already masked (and most of it is, it is only this version that has not been yet) as all its dependants were already upgraded to use new style gnat compilers. Apparently this one have slipped while I was "down" with this recent accident thing I had. I will mask it now. George
Which standard or rule specifies that the account used to run emerge has to use a bourne shell? AFAIK there is no such rule, and THERE SHOULD BE NO SUCH REQUIREMENT. Fix the package, please. Suggesting that people should use the MASKED packages gnat-gcc and gnat-gpl does not help.
No. We do not support having anything but a POSIX sh-compatible shell as the root shell. As such, having a non-compatible shell is an invalid configuration from our point of view. If you really want applications to support alternative incompatible shells, take it upstream.
(In reply to comment #4) > No. We do not support having anything but a POSIX sh-compatible shell as the > root shell. As such, having a non-compatible shell is an invalid configuration > from our point of view. > > If you really want applications to support alternative incompatible shells, > take it upstream. The ebuild procedure of dev-lang/gnat-3.45 is broken. It uses the value of the SHELL environment variable as path of the shell to process a script, instead of the bourne shell that would be needed for that particular script. This is an elementary bug in dev-lang/gnat-3.45. It is just wrong to assume that SHELL contains a path to a specific shell. If you need to interprete a script with sh, then call "sh" to do the job. Neither emerge nor ebuild check that the shell (SHELL environment variable) is a bourne shell. And the documentation does not list this as requirement either. In fact the manual page of emerge gives some hints for the use with a bourne shell as AN EXAMPLE and not as requirement. "Note that in many shells you will need [...]" "For example, env USE="-X -gnome" emerge mc will emerge mc with those USE settings (on Bourne-compatible shells you may omit the env part)."
(In reply to comment #3) > Suggesting that people should use the MASKED packages gnat-gcc and gnat-gpl > does not help. What are you talking about? Neither of those are masked. None have been marker stable yet though, but this is mostly because I did not receive enough test reports or requests to mark them stable. However none are in package mask. dev-lang/gnat, on the other hand, has known problems and has not been worked on for ages. The support for it has been dropped over a year ago and most of its versions were package masked a few month ago. This version should have been p-masked as well at least a month ago, although this has slipped by my omission. I just rectified this. Now *all* versions of dev-ang/gnat are p-masked. Please use gnat-gcc (the FSF version) or gnat-gpl (the AdaCore's) these are working much better (multilib support, proper installaition procedure, does not collide with gcc, even potentially, lots of other improvements. Most importantly, they are supported.) If you wish them marked stable, please then try one of those compilers and remind me about stabilization. I'll file the appropriate bug with our arch teams. Also note: none of the libs/packages under dev-ada will work with dev-lang/gnat, even if you unmask it and comment out dependency blocks - they expect a different structure supported by new gnat ebuilds. So, old style gnat is a dead end in any case. You will not be able to use anything with it, nor install either of other gnat compilers in parallel (that is known to cause problems). You can take a look at bugs ##111340 and 137268 for more info (and long discussions that preceded all this). As for the bash/tcsh issue, Gentoo officially supports only bash as an admin shell. Other stuff may work, however is not guaranteed to do so. dev-lang/gnat ebuild may have been doing stupid stuff in that regard, however that was not the only bad/stupid thing. The whole package has been significantly reworked (into split gnat-gcc and gnat-gpl packages) and old ebuilds will not be resurrected. I just recently cleaned the three enough to finally pull this one out. As of today all versions of dev-lang/gnat are p-masked pending removal in one month, as per usual policy. George
After an emerge-webrsync this afternoon, I still find * dev-lang/gnat Latest version available: 3.45 Latest version installed: 3.45 Size of files: 49,680 kB Homepage: http://www.gnat.com/ Description: GNAT Ada Compiler License: GMGPL * dev-lang/gnat-gcc [ Masked ] Latest version available: 4.1.2 Latest version installed: [ Not Installed ] Size of files: 64,852 kB Homepage: http://gcc.gnu.org/ Description: GNAT Ada Compiler - gcc version License: GMGPL * dev-lang/gnat-gpl [ Masked ] Latest version available: 3.4.6.2006-r1 Latest version installed: [ Not Installed ] Size of files: 52,463 kB Homepage: https://libre2.adacore.com/ Description: GNAT Ada Compiler - AdaCore GPL version License: GPL-2 I would be more than happy to switch to gnat-gcc or gnat-gpl. But I find that they are masked. Are the version numbers of gnat-gcc and gnat-gpl comparable? Is gnat-gcc 4.1.2 really newer than gnat-gpl 3.4.6.2006-r1? If ebuild really requires a POSIX-compatible shell, then it should call bash --posix EXPLICITLY and not rely on the "right" value in SHELL. I could also use another account instead of root, with TCSH as default. Ebuild should use the right shell if it needs a specific one (and we insist on using broken ebuild scripts).
I guess you are operating on a strictly stable profile? Portage then will give the report of that kind. I'd suggest using something like eix to look at available packages - in addition to listing more detailed information about package state it also performs searhes much faster :). In this case, you see gnat-gcc and gnat-gpl as masked only because there were no versions of them marked stable so far (primarily because I did not receive corresponding requests yet). However they are not masked in a strict sense - that is being in package mask or masked by profile or somehow otherwise "hardmasked". They are merely "in the testing", which means fully functional and should not cause any trouble. Unfortunately the way portage reports package status in such searches seems a bit confusing. >Are the version numbers of gnat-gcc and gnat-gpl comparable? Is gnat-gcc 4.1.2 >really newer than gnat-gpl 3.4.6.2006-r1? They key is like this: 1st three numbers represent gcc backend. That is gnat-gcc-4.1.2 is based on gcc-4.1 (specifically this is the same 4.1.2 version) and gnat-gpl on gcc-3.4.6. In the case of gnat-gcc this is all there is, plus Gentoo specific release number. In the case of ACT's gnat their release number is added at the end (as they have chosen to use a rather arbitrary naming scheme, we decided to supply gcc backend version to unify gnat versioning in portage. Still, I guess 2006 is better than ACT's internal numbers, like 5.0.xxx). In terms of supported features, these two should be more or less equivalent on Ada 2005 features (gnat-gpl may still be more feature-rich). ACT promised to soon release the 2007 version (the -pro is already out, they are apparently readying to tag gpl version soon). Then it will contain the most complete support of Ada 2005 features, to be picked up by gnat-gcc shortly thereafter. In general it is not trivial to relate these compilers in that respect. For this reason we provide both of them so that users can select which one they want. Libs will be automatically built for all installed gnat's btw, so you can really have them in parallel and switch on the fly. >After an emerge-webrsync this afternoon I just masked dev-lang/gnat about an hour ago. It takes half an hour for changes to propagate to master rsync, then some time to be picked up by mirrors and then webrsync lags behind that. I guess it is updated once a day or may be just a few times. So, you should see this change in webrsync tomorrow I guess.. However the change is solely masking gnat. Marking gnat-gcc/gnat-gpl stable has to go through arch teams and will take some time. Nonetheless you can (and should) use these compilers. Simply add dev-lang/gnat-gcc ~arch dev-lang/gnat-gpl ~arch to /etc/portage/package.keywords to let portage pick testing version of these packages on emerge/search (substitute x86 or amd64 or whatever your arch is instead of arch above. Although only these two and ppc are supported as of now). You can do the same for other Ada packages that you will want to use. Don't forget to send me test reports and stabilization requests then! (filing a bug in a usual way, assign directly to ada@g.o) I'll forward it to our arch teams and we'll get them marked stable soon afterwards. George
George, thanks for your nice reply! Yes, I do use a stable profile. Isn't that what Ada stands for? :) BTW app-admin/eselect-gnat also shows up as "masked" in a stable profile. dev-lang/gnat-gcc-4.1.2 emerge'd just fine (although "masked"), even with SHELL=/bin/tcsh set. Very nice, thanks! I still think that ebuild should *explicitly* set the environment variable SHELL and invoke a POSIX-compliant shell, if by policy all ebuild scripts *implicitly* require a POSIX-compliant shell. A note in the manual pages would be nice. An application should not malfunction just because a user decides to use a specific default shell. Imagine if one application enforces the use of a Bourne shell, another one requires a POSIX shell, and a third one only functions when called from a C shell. That would be quite confusing and has absolutely nothing to do with root being a special account (besides that Gentoo works just fine with root's shell set to TCSH, thanks). Perhaps this issue should be filed as bug in ebuild and then this one marked as resolved. Comments? OT: Any comment about the best debugger for Ada developers on Gentoo, maybe at http://forums.gentoo.org/viewtopic-t-557476.html ?
(In reply to comment #9) > George, thanks for your nice reply! Yea, sorry, the previous one came a bit heated, although that was triggered by your screaming in prior comments ;). > Yes, I do use a stable profile. Isn't that what Ada stands for? :) Yes, Ada has that perception of being the most orthodox language :). However these are the Gentoo markings we are talking about and they are simply meant to track the state of the ebuild, not as much the package itself (although there clearly is correlation). > BTW app-admin/eselect-gnat also shows up as "masked" in a stable profile. Sorry, forgot about this one - you would need to add it too. You can do the same for all the other packages that are "in testing" that you would want to use (look under dev-ada). Some of them are hardmasked (probably 2 or 3, I am about to remove those), as there were some problems with updating those and I did not get much requests for them, however the majority have a new version that would work with new compilers. > dev-lang/gnat-gcc-4.1.2 emerge'd just fine (although "masked"), even with > SHELL=/bin/tcsh set. Very nice, thanks! Ok, good to know. Do you want me to request stabilization of gnat compilers and some libs? However there may be a problem, see below. I had some thought about this shell script situation, so here goes: > I still think that ebuild should *explicitly* set the environment variable > SHELL and invoke a POSIX-compliant shell, if by policy all ebuild scripts > *implicitly* require a POSIX-compliant shell. Well, that should not be necessary. portage directly calls bash to process ebulds (may be except when evaluating dependencies in new versions, although it did it even then in all the versions I know about), so this should not be a problem in general, as the ebuild sees only bash and should have a limited access to your environment. However with some trickery it may be possible to get to your root shell, although stuff like that is already discoraged anyway. The situation with that ebuild is however different. By the lines that you posted I see that this "breach" happens deep inside the build procedure, under control of the gcc's own building scripts. I am pretty sure this is another case of that "environment leaking" that I had to fight many times with gnat (but also with gpc - a Pascal frontend to gcc, and I suspect similar stuff may happen with gcc, when trying to crosscompile for example, etc.). These leaks were "plugged" in the new style gnat eclass (and thus ebuilds using it), however I am afraid not completely. There still is one outstanding bug (#139241) where similar stuff happens and which I cannot yet trace :( (that is another blocker for marking gnat stable btw). Well, this is what you get when trying to support system related stuff on disparately configured systems. > An application should not malfunction just because a user decides to use a [skipped] > resolved. Comments? See above. Normally this should not happen, however sometimes some "leaks" can happen. In this case this had to do with gcc being a massively complex beast designed to support pretty much any platform as thus having a very complex building circuitry. Something we have no control over, other than trying our best to isolate resulting environment leaks.. As for bringing up the issue, you may try, however 1. as you see, the situation is not that simple. 2. I am pretty sure that you will face the arguments similar to "why would you need to run something not bash-alike as root. You may use whatever you want as a user, however as an admin you are supposed to use the tools provided. This is the purpose of distribution after all". If you wish a discussion on how Gentoo can provide another choice, go ahead, although in the end the resolution would likely be "if you want it so badly, submit patches" ;) > OT: Any comment about the best debugger for Ada developers on Gentoo, maybe at > http://forums.gentoo.org/viewtopic-t-557476.html ? Ok, I'll try to take a look at that. George
