When building which-2.19 (unstable) with readline-5.2_p7 (stable) we got the following error message: xmalloc.h:29:31: error: readline/rlstdc.h: No such file or directory make[2]: *** [tilde.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/sys-apps/which-2.19/work/which-2.19/tilde' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sys-apps/which-2.19/work/which-2.19' make: *** [all] Error 2 If using the unstable release of readline-5.2_p12-r1 it compiles without problem. Reproducible: Always Steps to Reproduce: 1. If using stable: ACCEPT_KEYWORDS="~amd64" which-2.19 2. If using unstable AND you did not updated readline: emerge which 3. If using unstable and you updated readline before you should't be reading this ;-). Actual Results: =sys-apps/which-2.19 fails to merge due compilation errors. Expected Results: Compilation successfull and package merged. This problem is simple, but if you are installing from a stage-1 you must take care of updating readline before going to stage-3 (just before emerge -e system).
When I said if you're compiling from a stage-1 I want to say: If you are compiling from a stage-1 *using* an *unstable* arch (~amd64 for me).
Created attachment 141652 [details] Updated which-2.19.ebuild I know that this is trivial to fix, but I uploaded a which-2.19.ebuild with DEPEND updated. Just for self-training :).
Comment on attachment 141652 [details] Updated which-2.19.ebuild please do not post entire ebuilds as they are hard to read to figure out what you've actually changed ... post diffs instead
readline-5.2_p7 provides readline/rlstdc.h ... as does readline-5.1 and readline-4.3 and ... whatever the reason for your failure, it isnt a DEPEND issue since you're building from a stage1, you'll have to figure it out and get back to us
I have done some research about this. After decompressing the stage1-amd64-2007.0.tar.bz2 I look for readline header files: machine ~ # find /home/username/gentoo -name "readline*" machine ~ # As you can see there is no readline by default in stage1 nor bootstrap.sh installs it. Another check to ensure that: machine ~ # ROOT=/home/username/gentoo emerge -pv readline These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sys-libs/readline-5.2_p12-r1 to /home/username/gentoo/ 2,018 kB Total: 1 package (1 new), Size of downloads: 2,018 kB machine ~ # Since which-2.19 readline is required before compile this version: machine ~ # mkdir which machine ~ # tar zxf /usr/portage/distfiles/which-2.16.tar.gz -C which machine ~ # tar zxf /usr/portage/distfiles/which-2.19.tar.gz -C which machine ~ # cg rlstdc which/* 0 which/which-2.19/tilde/xmalloc.h 27 # include "rlstdc.h" 1 which/which-2.19/tilde/xmalloc.h 29 # include <readline/rlstdc.h> machine ~ # I hope this helps.
last i checked, stage1 installs are not supported ... if it breaks, you get to fix it final word is of course up to the release team
I don't think you'll get any argument from us, unless it blocks us building stages later on down the line, of course :P
Hi, this comment is only for reference. If you're currently building a ~keyworded stage3 with catalyst, you must take care of this bug due it will happend to you.
Confirm, I still have this problem installing gentoo from stage1 on x86 compatible VIA C7. I have just manualy emerged readline and now which is emerged correctly. This should be fixed, because I could waste the night of compilation if I have not noticed that my remote installation has stoped. People just use emerge -e system and think that there should be no problem during ~6h of installation/compilation. You will log on and see that for most of the time there was nothing done because at the some beginning there was error. It has been reported in January, now we have March.
Peter, as you might not have noticed, this bug is not going to be fixed. We do not support stage1 installations.
Hi, only for clarification but: Shouldn't this be fixed to avoid compilation errors while using catalyst? Those who wants to make a stage3 fall into this error too.
*** Bug 213224 has been marked as a duplicate of this bug. ***
As reported in bug 213224, the which-2.19 build failure is causing a failure in catalyst when building stages using a stable x86 profile.
This bug is now happenning building stable x86 catalyst profiles. Drobbins asked about reopen this in the duplicated bug entry.
The rlstdc.h include appears to be extraneous. I have tried removing it and which appears to build fine. This needs more testing to ensure it builds in all environments, and has not been tested inside catalyst. See attached which-2.19-r1.ebuild and which-readline-fix.patch. Also note that a rev bump should probably not be done as this appears to be purely a build fix (did a rev bump locally only for testing purposes)
Created attachment 146047 [details] new ebuild that applies build fix
Created attachment 146049 [details, diff] remove reference to rlstdc.h - seems to fix things.
in tree as sys-apps/which-2.19-r1, not closing since this is assigned to release.
erm. I didn't actually intend to revbump it since it's a build fix. it's actually sys-apps/which-2.19
Well, really this should have stayed RESOLVED and the other should have just been RESOLVED-FIXED. I'm marking this as "FIXED" since it's fixed in the tree. Again, we don't support stage1 installation, and a build failure for catalyst isn't the release team's "bug" but one in the package, which has already been fixed... so again... FIXED.
please properly document patches before putting them in the tree has anyone sent this to the which maintainer ?
Yes, it has been sent upstream to the which maintainer and he had already received an identical patch from someone else: "" This was already sent to me by someone else, and has already been committed to SVN. It will be in 2.20 -- though it can take years before I release that :p - Show quoted text - On Thu, Mar 13, 2008 at 12:55:04PM -0600, Daniel Robbins wrote: > Hi Carlo, > > I have created a patch for which-2.19 that removes an unnecessary > dependency on readline for compilation. > > While nearly all Linux systems have readline installed, this > unnecessary dependency on readline can create problems when > "bootstrapping" or building up a Linux OS from scratch, during which > time readline might not yet be installed. > > I thought the best course of action was remove the readline dependency > - please consider integrating this into your source tree. > > This fix resolves the following Gentoo bugs, which also provide detail > of how the issue was breaking Gentoo's distro build process: > > http://bugs.gentoo.org/show_bug.cgi?id=207151 > http://bugs.gentoo.org/show_bug.cgi?id=213224 > > Best Regards, > > > Daniel Robbins -- Carlo Wood <carlo@alinoe.com> ""
thanks
