The cyrus-sasl-1.5.27 ebuild fails mysteriously on some of my machines. The more "barebones" the machine, the more likely the probability of failure. I have seen this before on other machines, but when I tried again a few days later (after upgrading some other stuff), it would compile. Well, since it just bit me again, and I don't find any bug report related to it, here is mine: This is with portage 1.8.8; my USE variables are: USE="slang readline gpm berkdb gdbm tcpd pam libwww ssl nls mitshm perl python" The machine is pretty much up2date. NB: I don't care for cyrus-sasl, but the postfix ebuild insists on installing it (aside from the one I hacked not to use it) Oh, and this is the error: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/local/include -Wall -W -mcpu=i586 -march=i586 -O3 -pipe -Wp,-MD,.deps/common.pp -c common.c -fPIC -DPIC -o .libs/common.lo common.c: In function `_sasl_getconfpath': common.c:659: `SASL_CONF_PATH_ENV_VAR' undeclared (first use in this function) common.c:659: (Each undeclared identifier is reported only once common.c:659: for each function it appears in.) common.c:661: `CONFIGDIR' undeclared (first use in this function) make[2]: *** [common.lo] Error 1 make[2]: Leaving directory `/var/tmp/portage/cyrus-sasl-1.5.27/work/cyrus-sasl-1.5.27/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/cyrus-sasl-1.5.27/work/cyrus-sasl-1.5.27' make: *** [all-recursive-am] Error 2 !!! ERROR: The ebuild did not complete successfully. !!! Function src_compile, Line 29, Exitcode 2 !!! compile problem !!! emerge aborting on /usr/portage/dev-libs/cyrus-sasl/cyrus-sasl-1.5.27.ebuild . Could it have anything to do with the fact that for (by now unknown reasons), I have glibc-2.2.4-r9 installed, but kernel-headers 2.4.17-r3. (Don't ask me how I ended up with this combination). Nevertheless, I fail to see what this could have to do with the compile error.
does it fail mysteriously at *exactly* the same place every time?
I don't know *exactly*, but I think so. It is reproducible *exactly* on the machine I am having the problem (and that is after rebooting several times for completely unrelated reasons -- making sure that an about to be server comes up OK after a planned/unplanned reboot; i.e., services get started in the right order etc. So, I personally exclude Sig11 or that type of thing problems!! Now, I can't remember exactly whether it's the same type of error I had on the previous set of machines. It certainly feels similar; one of the first files after the ./configure step bombs, some missing "environment" variable. On these latter machines the problem somehow vanished, and so I didn't follow up on it. The one thing I remember is that the last time the problem definitely only occurred in the gentoo(?) patched version; this I can reproduce. A tar -xzvf ; ./configure ; make by hand compiles without error (for what that is worth) Sorry that I'm not of much help. Would an account on the "affected" machine help?
I had the same problem building this ebuild. The error messages I got were the same. I was doing: emerge postfix fetchmail and, looking at the comments above I found that I had both: sys-kernel/linux-headers-2.4.16 and sys-kernel/linux-headers-2.4.17-r5 installed. I unmerged sys-kernel/linux-headers-2.4.16 and everything then built fine.
Reassigning to woodchip, since he's familiar with this problem.
*** Bug 1820 has been marked as a duplicate of this bug. ***
hi! could you fellas please trying installing the -r1 version of this ebuild. i think azarah and jhudson have worked out a fix for it please let me know how it works out, so that i can close this bug report. thank you.
1.5.27-r1 just built on a rather bare bones machine (similar to the one I encountered the problem with) without problems. But to be honest, I had been assuming that the bug was fixed since 1.5.27 (not r1) built on yet another similar machine about a week ago. So, I don't know what you fixed, but it seems to me that the original problem was less a problem of the ebuild itself rather than of other things in the system that were present (or not present)... Stefan
this is now fixed in -r1. it was a build problem. thankfully azarah is an auto* guru ;-)
