While emerging pkgconfig 0.22 it will compile fine then give me a QA notice during the install_qa_check. Below is the error, the code seems to compile fine, at least it completes. * QA Notice: Package has poor programming practices which may compile * fine but exhibit random runtime failures. * gstrfuncs.c:675: warning: implicit declaration of function `strsignal' * QA Notice: Package has poor programming practices which may compile * but will almost certainly crash on 64bit architectures. * Function `strsignal' implicitly converted to pointer at gstrfuncs.c:675 * * ERROR: dev-util/pkgconfig-0.22 failed. * Call stack: * misc-functions.sh, line 653: Called install_qa_check * misc-functions.sh, line 397: Called die * * this code is not 64bit clean * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/home/jolexa/portage/linux-64/var/tmp/portage/dev-util/pkgconfig-0.22/temp/build.log'. * !!! install_qa_check failed; exiting. * Messages for package dev-util/pkgconfig-0.22: * * ERROR: dev-util/pkgconfig-0.22 failed. * Call stack: * misc-functions.sh, line 653: Called install_qa_check * misc-functions.sh, line 397: Called die * * this code is not 64bit clean * If you need support, post the topmost build error, and the call stack if relevant. Reproducible: Always Steps to Reproduce: bash-3.00$ emerge --info !!! Problem with sandbox binary. Disabling... Portage 2.2.00.7724-prefix (default-prefix/linux/amd64, gcc-3.4.6, unavailable, 2.6.9-55.ELsmp x86_64) ================================================================= System uname: 2.6.9-55.ELsmp x86_64 Intel(R) Xeon(TM) CPU 3.60GHz Timestamp of tree: Wed, 12 Sep 2007 13:36:24 +0000 app-shells/bash: 3.2_p17-r1 dev-lang/python: 2.4.4-r04.2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo" DISTDIR="/home/jolexa/portage/linux-64/usr/portage/distfiles" EPREFIX="/home/jolexa/portage/linux-64" FEATURES="collision-protect distlocks metadata-transfer sfperms unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-L/home/jolexa/portage/linux-64/usr/lib64 -Wl,-rpath=/home/jolexa/portage/linux-64/usr/lib64 -L/home/jolexa/portage/linux-64/lib64 -Wl,-rpath=/home/jolexa/portage/linux-64/lib64" PKGDIR="/home/jolexa/portage/linux-64/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/home/jolexa/portage/linux-64/var/tmp" PORTDIR="/home/jolexa/portage/linux-64/usr/portage" SYNC="svn+http://overlays.gentoo.org/svn/proj/alt/trunk/prefix-overlay" USE="amd64 cracklib iconv midi mudflap ncurses openmp prefix readline ssl zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" Unset: CFLAGS, CTARGET, CXXFLAGS, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY I'm using portage as part of the prefix overlay so this is a new(er) version of portage. It seems that the install_qa_check function is checking for implicit pointers and then dieing if its on a 64bit machine.
FEATURES="stricter" is not intended for end users. *** This bug has been marked as a duplicate of bug 166763 ***
Jakub, stricter is not set, take a look at my FEATURES. This is a problem with the source code I think.
And we need two bugs for the same issue exactly why? (Complain to prefix folks about this being fatal by default). *** This bug has been marked as a duplicate of bug 166763 ***
I have no clue why this is fatal by default, but it is correct to be fatal, if you read the error message. The patch to this error should be just to include <signal.h> in the offending file somewhere.
assigning to alt@gentoo.org per grobian's personal email.
Jeremy, what I find worrying, is that you have LDFLAGS set, whereas your CFLAGS is unset. I'd expect the other way around, and in particular don't like the value of your LDFLAGS. What's in there may cause this bug.
(In reply to comment #6) > Jeremy, what I find worrying, is that you have LDFLAGS set, whereas your CFLAGS > is unset. I'd expect the other way around, and in particular don't like the > value of your LDFLAGS. What's in there may cause this bug. > Hmm, I thought I had CFLAGS set, I will double check that value and try again when I am able to and get back to you. As for the LDFLAGS, I just followed the linux bootstap guide however I took out the bash expansion because it wasn't expanding right and I was too lasy to manually expand it.
Same results with the LDFLAGS expanded out: LDFLAGS="-L/home/jolexa/portage/linux-64/usr/lib64 -L/home/jolexa/portage/linux-64/usr/lib -Wl,-rpath=/home/jolexa/portage/linux-64/usr/lib64 -Wl,-rpath=/home/jolexa/portage/linux-64/usr/lib -L/home/jolexa/portage/linux-64/lib64 -L/home/jolexa/portage/linux-64/lib -Wl,-rpath=/home/jolexa/portage/linux-64/lib64 -Wl,-rpath=/home/jolexa/portage/linux-64/lib" CFLAGS is not set on purpose. Still bootstrapping the system. CPPFLAGS is set as: CPPFLAGS=-I/home/jolexa/portage/linux-64/usr/include Suggestions on changing the LDFLAGS? I'm not very familar with them. Thanks.
I see you are in the bootstrapping phase. It may be problematic here because you use a compiler which is not under our control. What phase of the bootstrapping are you?
(In reply to comment #9) > you use a compiler which is not under our control. Ahh, right. Fixed this issue by emerging gcc 4.2.0. Sorry for all the havok - I didn't know that this would cause an issue. Closing as "INVALID"
An additional note: I witnessed this when a user mistakenly used the developer profile, which pulled in FEATURES="stricter" Switching to a desktop profile fixed it for him.