Summary: | dev-libs/glib-2.20.2 fails to build, "/usr/bin: file not recognized: Is a directory" | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | brent <brent.saner> |
Component: | [OLD] Core system | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | donahue95, fturco, gentoo, idevelop, ikelos, jaak, kostik.russia, michael.ralston, posting, SebastianLuther, tibor.vago, tokiclover, yopyop |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build log
build environment file new build.log new environment build file config.log from reproduction emerge.log for both unsuccessful and successful emerges; dependency reference |
Description
brent
2009-05-31 06:13:27 UTC
Created attachment 193038 [details]
build log
Please attach /var/tmp/portage/dev-libs/glib-2.20.2/temp/environment. Created attachment 193042 [details] build environment file (In reply to comment #2) > Please attach /var/tmp/portage/dev-libs/glib-2.20.2/temp/environment. > you know, i was debating with myself whether you'd need it or not. :) didn't want to clutter the report if it was unnecessary. here ya go! hey sebastian and the rest of the bug team, i think i may have figured it out for you. i'm 90% positive it's somewhere in the USE flags and/or the /etc/make.profile i had set (../usr/portage/profiles/default/linux/amd64/2008.0). i tried a pristine install, same repos, etc. but this time i used a vanilla make.conf and i never set an /etc/make.profile symlink.... and wouldn't you know it? it emerged FINE. however, i still want to leave this as "ASSIGNED" so whomever wants to look through it can.. i'm going to do some more testing, see if it breaks later on when i re-set the make.profile smylink. i'll keep you posted if it does. whoops- quick correction. profile was ../usr/portage/profiles/default/linux/amd64/2008.0/desktop (however, the parent file exists so it'd link upwards, if i'm not mistaken)... so i'm pretty sure it's somewhere in the USE flags i set in the make.conf: avahi bash-completion cleartype dga directfb fbcon ggi glitz gnutls ibm java jbig jpeg2k justify kerberos libcaca lzo multislot mysql nas nsplugin php postgresql samba smbkrb5passwd toolbar tools utils vim-syntax xinetd zeroconf It's probably something in your env, but I doubt it's useflags/profile. Attach config.log. (In reply to comment #6) > It's probably something in your env, > but I doubt it's useflags/profile. > > Attach config.log. > ahh darn it. i scrapped the install and started over, i'm afraid. anyways, i'm assuming user error on this part because i cen't seem to duplicate it now, even after switching to the desktop profile as i suspected. Since i no longer have the associated build logs, et. al. i'm marking this as "RESOLVED: NEEDINFO" in case someone else bumps into it. well, good(?) news. i got it to reproduce on a vanilla install now. i'll attach the new build.log, environment, and config.log Created attachment 193072 [details]
new build.log
Created attachment 193074 [details]
new environment build file
Created attachment 193076 [details]
config.log from reproduction
hey, a thought just occurred- i'm using ext4 for my /, would that have any impact? i wouldn't think it would, but the fact that glib has an xattr USE flag AND it spits out: /usr/bin: file not recognized: Is a directory makes me suspicious. ....yeah. it builds fine in a fresh chroot environment on another host using ext3. it makes no sense, and i don't think it's really ext4 that's causing it, but at this point who knows? Out of curiosity, what's the content of your root user's PATH variable? (In reply to comment #14) > Out of curiosity, what's the content of your root user's PATH variable? > hmm, didn't append or remove from it, and i always env-update and source /etc/profile after i chroot in. i use sysresccd for installs, though, not the gentoo disc.. i have the old, broken install tarred up at the moment and i'm about to leave for a couple days, but when i come back i'll untar it and chroot in and see if i can reproduce on the different host. i was able to get it to compile (and can recompile it without fail, changing the use flags also doesn't break it) on the fresh install, however.. i'll attach my emerge.log just in case it's a dependency issue. you can see it fail on line 643, 1031, 1081, and then it exits/compiles successfully at line 1766 (i believe i killed that one before it started), 1778, and 1789. i THINK it was perhaps cairo or one of the dependencies it pulled in that "fixed" things, but it works fine now.. Created attachment 193239 [details]
emerge.log for both unsuccessful and successful emerges; dependency reference
It appears as though you have a path variable set, and it's also set as a space separated variable, whereas PATH variables are in general a colon separated variable (for example PATH="/sbin:/usr/sbin:/bin:/usr/bin"). The errors you've posted are the reverse of your path variable, although I can't see why they're being included. My guess is a libtool issue (given that they're not passed in to the libtool call), so it's probably from a different package that all your other packages try to include (using libtool). Could you please run "grep -ir path /usr/lib/*.la" and "grep -ir path /etc/env.d/*", then post the results here? Finally, please do attach your root user's environment, it will help us determine whether this bad path variable is present in just portage's environment, or also in the root user's... Comment on attachment 193239 [details]
emerge.log for both unsuccessful and successful emerges; dependency reference
You were asked to post information about the failing system. Showing emerge.log really won't do, I'm afraid.
hey, sorry for the late reply. i'm 100% sure i've narrowed it to a SystemRescueCD issue, as the error is unable to reproduced inside the actuall install or a chroot from another gentoo host. which is a bit weird because i would always env-update and source /etc/profile after a chroot from the CD, but i guess there's some funniness there. using the beta arch of the cd, anyways, though, so.. no surprise. when i get the chance i'll forward this bug to them and reopen if after further investigation it turns out i'm wrong, but at this point it's the only constant difference. thank you for your help, everyone. I can confirm this with glib-2.18.4-r1 on SystemRescueCd-1.2.1 *** Bug 275983 has been marked as a duplicate of this bug. *** Hi, I confirm, same problem with syrescd 1.2.1. So how can i install gentoo with amd64 and ext4 support ? The autobuild installcds have ext4 support. Try: http://gentoo.osuosl.org/releases/amd64/autobuilds/20090625/install-amd64-minimal-20090625.iso export path= did it for me today while building a new system (In reply to comment #24) > export path= > > did it for me today while building a new system > Thanks, $ unset path helps me too. I've hit this issue as well and it affects other packages as well. I've noticed that sysrescuecd uses zsh by default and that even after chrooting, SHELL is set to zsh. I couldn't see anything obvious in PATH, but unsetting it allowed portage to merge each package that failed. (In reply to comment #26) > I've hit this issue as well and it affects other packages as well. > I've noticed that sysrescuecd uses zsh by default and that even after > chrooting, SHELL is set to zsh. I couldn't see anything obvious in PATH, but > unsetting it allowed portage to merge each package that failed. > Hey, I hit this issue just now too. Another approach is to tweak the chroot command like this: # SHELL=/bin/bash chroot /mnt/gentoo /bin/bash *** Bug 294742 has been marked as a duplicate of this bug. *** Many many thanks for this excellent bug report, which just saved me hours of frustration. I have posted a "heads-up" about this (admittedly odd) env bug on the Funtoo list; people who are bootstrapping a GPT-partitioned or btrfs-root system might run into it. *** Bug 310281 has been marked as a duplicate of this bug. *** I too had this issue using sysrescuecd. But using just SHELL=/bin/bash didn't solve it. I used: chroot /mnt/gentoo /usr/sbin/env -i /bin/bash This wipes the environment before starting bash. I too had this issue using sysrescuecd. But using just SHELL=/bin/bash didn't solve it. I used: chroot /mnt/gentoo /usr/sbin/env -i /bin/bash This wipes the environment before starting bash. *** Bug 284480 has been marked as a duplicate of this bug. *** *** Bug 399733 has been marked as a duplicate of this bug. *** *** Bug 410375 has been marked as a duplicate of this bug. *** *** Bug 413019 has been marked as a duplicate of this bug. *** *** Bug 444036 has been marked as a duplicate of this bug. *** *** Bug 460914 has been marked as a duplicate of this bug. *** *** Bug 484114 has been marked as a duplicate of this bug. *** |