[gentoo-amd64] [gentoo-user] Collisions when compiling glibc-2.5-r3 and r4 on amd64

[gentoo-amd64] [gentoo-user] Collisions when compiling glibc-2.5-r3 and r4 on amd64

[Marc Joliet]

[-- Attachment #1.1: Type: text/plain, Size: 3011 bytes --]

[As posted to gentoo-user, along with small corrections and updates!]

Hi List,

I didn't find any bug report matching my experience. This appears to be
the closest match: http://bugs.gentoo.org/show_bug.cgi?id=145749. I
thought I'd ask about it here first, before reporting a bug, in the
event of PEBKAC.

I updated linux-headers today to the current stable, 2.6.21, and the
messages recommend a recompile of the system libc, in this case glibc.
When it wants to merge the compiled glibc, I get this:

[------------------------------------------------------------]

>>> Completed installing glibc-2.5-r4
into /var/tmp/portage/sys-libs/glibc-2.5-r4/image/

ecompressdir: bzip2 -9 usr/share/man
ecompressdir: bzip2 -9 /usr/share/info
making executable: usr/lib32/libc.so
making executable: usr/lib32/libpthread.so
making executable: usr/lib64/libc.so
making executable: usr/lib64/libpthread.so
* checking 2373 files for package collisions
1000 files checked ...
2000 files checked ...
existing file /lib is not owned by this package
* This package is blocked because it wants to overwrite
* files belonging to other packages (see messages above).
* If you have no clue what this is all about report it
* as a bug for this package on http://bugs.gentoo.org

package sys-libs/glibc-2.5-r4 NOT merged


Searching all installed packages for file collisions...
Press Ctrl-C to Stop

 * x11-drivers/nvidia-drivers-1.0.9746-r1:

     '/lib'

 * sys-boot/grub-0.97-r3:

     '/lib'

 * media-sound/alsa-firmware-1.0.14_rc2-r1:

     '/lib'

 * media-sound/alsa-driver-1.0.14_rc2-r1:

     '/lib'

 * sys-fs/udev-104-r12:

     '/lib'

 * sys-fs/cryptsetup-luks-1.0.4-r3:

     '/lib'

 * sys-fs/device-mapper-1.02.19:

     '/lib'

 * sys-fs/lvm2-2.02.10:

     '/lib'

 * media-libs/libgphoto2-2.2.1-r1:

     '/lib'

 * sys-apps/hal-0.5.9-r1:

     '/lib'

 * net-analyzer/macchanger-1.5.0-r1:

     '/lib'

marcec marcec # 

[------------------------------------------------------------]

Is there a 'clean' work around? The only option I found is to set
COLLISION_IGNORE="/lib" in make.conf. That seems to do the trick insofar
that glibc merges. For "emerge --info" see attachment.

Apparently, from what I read, the collision-protect[1] option is
supposed to ignore directories. Since this was asked in other reports I
found while searching for info: /lib is not a symlink, rather /lib64 is
a symlink to /lib. Out of curiosity: when would /lib ever be a symlink?

Note that I will not have my email available for a few days starting
tonight (Sunday). I'm sending my PC via mail to my home for the summer
holidays, versus it staying in my dorm room. Yes I know of VNC, but I
didn't find the time to set it up.

Any help greatly appreciated!
-- 
Marc Joliet

[1] I only semi-recently (a few weeks ago) set the collision-protect
option, and until now, glibc is the only package to complain.

-- 
Marc Joliet

[-- Attachment #1.2: emerge-info.txt --]
[-- Type: text/plain, Size: 4246 bytes --]

Portage 2.1.2.9 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.5-r3, 2.6.20-gentoo-r8 x86_64)
=================================================================
System uname: 2.6.20-gentoo-r8 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
Gentoo Base System release 1.12.9
Timestamp of tree: Sat, 14 Jul 2007 21:00:01 +0000
distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
dev-java/java-config: 1.3.7, 2.0.33-r1
dev-lang/python:     2.3.5-r3, 2.4.4-r4
dev-python/pycrypto: 2.0.1-r5
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
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/binutils:  2.17
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.23b
virtual/os-headers:  2.6.21
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=athlon64 -pipe -msse3"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/share/config/kdm /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/qmail/alias /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-O2 -march=athlon64 -pipe -msse3"
DISTDIR="/usr/portage/distfiles"
FEATURES="collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict userpriv usersandbox"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LANG="de_DE.UTF-8"
LC_ALL="de_DE.UTF-8"
LINGUAS="en de it fr ru pl"
MAKEOPTS="-s -j3"
PKGDIR="/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="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local/layman/pro-audio /usr/portage/local/layman/science /usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow 3dnowext 7zip X a52 aac aalib accessibility acl acpi ada alsa amd64 artswrappersuid asterisk audiofile avahi berkdb bitmap-fonts blas bluetooth bzip2 cairo caps cdda cdr cjk cli cracklib crypt css cups dbus dga djvu dri dssi dts dv dvb dvd dvdr dvdread dvi eds encode evo exif fat ffmpeg firefox flac foomaticdb fortran fuse gcj gdbm gif gimpprint glitz glut gnokii gnutls gphoto2 gpm gtk hal hfs iconv ieee1394 imlib ipod ipv6 irda isdnlog jack java jfs joystick jpeg jpeg2k kde kdehiddenvisibility kdgraphics kerberos kig-scripting kipi ladspa lapack lcd lcms ldap libcaca libg++ libsamplerate live lm_sensors logitech-mouse mad matroska mbrola midi mikmod mmx mmxext modplug mono mozcalendar moznocompose moznoirc moznomail mp3 mpeg mudflap musepack musicbrainz nautilus ncurses nls nntp nptl nptlonly nsplugin ntfs nvidia ogg openexr opengl openmp pam pam_chroot pam_timestamp pcmcia pcre pdf perforce perl php png postgres povray ppds pppd pwdb python qt3 qt4 quicktime rdesktop readline reflection reiser4 reiserfs remote rtsp ruby samba scanner sdl session shout skins slang sms sndfile soundtouch speedo speex spell spl sql sqlite sse sse2 ssl stats stream subversion svg symlink tcpd theora threads tiff timidity truetype truetype-fonts type1-fonts unicode usb v4l v4l2 vcd visualization vlm vorbis wxwindows xcomposite xfs xine xinerama xml xorg xpm xprint xscreensaver xv xvid xvmc zeroconf zlib" ALSA_CARDS="ice1724 hda-intel usb-audio" 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="evdev keyboard mouse joystick vmmouse void" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en de it fr ru pl" USERLAND="GNU" VIDEO_CARDS="dummy fbdev nv nvidia v4l vesa vga vmware"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: [gentoo-user] Collisions when compiling glibc-2.5-r3 and r4 on amd64

[Duncan]

Marc Joliet <marcec@gmx.de> posted
1184460910.24252.59.camel@marcec.huntemann.uni-oldenburg.de, excerpted
below, on  Sun, 15 Jul 2007 02:55:10 +0200:

> making executable: usr/lib32/libc.so
> making executable: usr/lib32/libpthread.so making executable:
> usr/lib64/libc.so
> making executable: usr/lib64/libpthread.so 
> * checking 2373 files for package collisions [...]
> existing file /lib is not owned by this package 
> * This package is blocked because it wants to overwrite
> * files belonging to other packages (see messages above).
> * If you have no clue what this is all about report it
> * as a bug for this package on http://bugs.gentoo.org
> 
> package sys-libs/glibc-2.5-r4 NOT merged
> 
> 
> Searching all installed packages for file collisions... Press Ctrl-C to
> Stop
> 
>  * x11-drivers/nvidia-drivers-1.0.9746-r1:
> 
>      '/lib'

[snip]
 
> Is there a 'clean' work around? The only option I found is to set
> COLLISION_IGNORE="/lib" in make.conf. That seems to do the trick insofar
> that glibc merges. For "emerge --info" see attachment.
> 
> Apparently, from what I read, the collision-protect[1] option is
> supposed to ignore directories. Since this was asked in other reports I
> found while searching for info: /lib is not a symlink, rather /lib64 is
> a symlink to /lib. Out of curiosity: when would /lib ever be a symlink?

It's probably a portage bug, confusion due to lib64 being a symlink to 
lib for amd64.  The thing is, not a lot of folks run collision-protect, 
and while many devs do, in a lot of cases they aren't running stable, but 
~arch.  Thus, they'll have long since moved past that version of portage, 
and may not have caught the issue (tho packages /are/ supposed to be 
tested on stable with collision-protect on, before stabilizing)

Have you seen http://bugs.gentoo.org/show_bug.cgi?id=80846 (which is 
linked from the bug you mentioned)?  It looks like either that bug or a 
special case very similar to that bug.  What portage are you running?  Is 
it the 2.1.2 series past the -pre1 mentioned in that bug?  Is portage 
updated to the latest stable on your system?

Beyond that, you'll need to let the experts tell you.  It's close enough 
to 80846 to be a dup, but if you are running portage 2.1.2 or later, 
according to that, it /should/ be fixed, so maybe it's a corner case that 
was missed, or... I don't know!

As for symlinks and lib/lib64, Gentoo/amd64 has gone both ways over the 
years.  Some release stage tarballs had lib64 -> lib, others lib -> 
lib64.  FWIW, here's what I have here/now:

$ls -d -l /lib /lib64
lrwxrwxrwx  1 root root    5 2007-05-22 23:49 /lib -> lib64/
drwxr-xr-x 10 root root 4376 2007-07-13 10:17 /lib64/

FWIW, my /usr location symlink points in the same direction as well.  
However, that's because when I switched off multilib, I tried running the 
two as separate dirs.  It didn't quite work, however, because a few 
ebuilds install to lib64 but call or install scripts that call the app in 
(hardcoded) lib, or the reverse, so they can't be separate dirs, or the 
system will be expecting it in one and not finding it, because it's in 
the other.  So, once I figured out it wouldn't work, I resymlinked them, 
and it was easiest to cp from lib to lib64, then delete lib and make it a 
symlink, so that's what I did.  IDR what it was before, or know which way 
the current release stage tarballs set it up.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: [gentoo-user] Collisions when compiling glibc-2.5-r3 and r4 on amd64

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 5157 bytes --]

Am Sonntag, den 15.07.2007, 10:23 +0000 schrieb Duncan:
> Marc Joliet <marcec@gmx.de> posted
> 1184460910.24252.59.camel@marcec.huntemann.uni-oldenburg.de, excerpted
> below, on  Sun, 15 Jul 2007 02:55:10 +0200:
> 
> > making executable: usr/lib32/libc.so
> > making executable: usr/lib32/libpthread.so making executable:
> > usr/lib64/libc.so
> > making executable: usr/lib64/libpthread.so 
> > * checking 2373 files for package collisions [...]
> > existing file /lib is not owned by this package 
> > * This package is blocked because it wants to overwrite
> > * files belonging to other packages (see messages above).
> > * If you have no clue what this is all about report it
> > * as a bug for this package on http://bugs.gentoo.org
> > 
> > package sys-libs/glibc-2.5-r4 NOT merged
> > 
> > 
> > Searching all installed packages for file collisions... Press Ctrl-C to
> > Stop
> > 
> >  * x11-drivers/nvidia-drivers-1.0.9746-r1:
> > 
> >      '/lib'
> 
> [snip]
>  
> > Is there a 'clean' work around? The only option I found is to set
> > COLLISION_IGNORE="/lib" in make.conf. That seems to do the trick insofar
> > that glibc merges. For "emerge --info" see attachment.
> > 
> > Apparently, from what I read, the collision-protect[1] option is
> > supposed to ignore directories. Since this was asked in other reports I
> > found while searching for info: /lib is not a symlink, rather /lib64 is
> > a symlink to /lib. Out of curiosity: when would /lib ever be a symlink?
> 
> It's probably a portage bug, confusion due to lib64 being a symlink to 
> lib for amd64.  The thing is, not a lot of folks run collision-protect, 
> and while many devs do, in a lot of cases they aren't running stable, but 
> ~arch.  Thus, they'll have long since moved past that version of portage, 
> and may not have caught the issue (tho packages /are/ supposed to be 
> tested on stable with collision-protect on, before stabilizing)

I only activated it because I also run games and I recall it being
recommended to activate it when using 3rd party binaries.

> Have you seen http://bugs.gentoo.org/show_bug.cgi?id=80846 (which is 
> linked from the bug you mentioned)?  It looks like either that bug or a 
> special case very similar to that bug.  What portage are you running?  Is 
> it the 2.1.2 series past the -pre1 mentioned in that bug?  Is portage 
> updated to the latest stable on your system?

No, I haven't seen it. Though I can't tell if it may be related, plus
the bug is marked "resolved fixed", so I assume it still is. Though I am
confused as to how a collision in glibc could have been missed. That's
why I thought it may be an error on my account, or a broken file
somewhere (and the likes).

Also, I am very up to date. I run a cron-job every day at 23:00 to sync
and then manually update. So I have the most recent stable of everything
I have, along with a select few applications as ~amd64 and exactly 3
packages unmasked (ut99 related packages).

> Beyond that, you'll need to let the experts tell you.  It's close enough 
> to 80846 to be a dup, but if you are running portage 2.1.2 or later, 
> according to that, it /should/ be fixed, so maybe it's a corner case that 
> was missed, or... I don't know!

Me neither :-|.

> As for symlinks and lib/lib64, Gentoo/amd64 has gone both ways over the 
> years.  Some release stage tarballs had lib64 -> lib, others lib -> 
> lib64.  FWIW, here's what I have here/now:
> 
> $ls -d -l /lib /lib64
> lrwxrwxrwx  1 root root    5 2007-05-22 23:49 /lib -> lib64/
> drwxr-xr-x 10 root root 4376 2007-07-13 10:17 /lib64/
> 
> FWIW, my /usr location symlink points in the same direction as well.  
> However, that's because when I switched off multilib, I tried running the 
> two as separate dirs.  It didn't quite work, however, because a few 
> ebuilds install to lib64 but call or install scripts that call the app in 
> (hardcoded) lib, or the reverse, so they can't be separate dirs, or the 
> system will be expecting it in one and not finding it, because it's in 
> the other.  So, once I figured out it wouldn't work, I resymlinked them, 
> and it was easiest to cp from lib to lib64, then delete lib and make it a 
> symlink, so that's what I did.  IDR what it was before, or know which way 
> the current release stage tarballs set it up.

Thanks for the info. Sorry to say, but my gentoo install was originally
Sabayon. However, I moved to stable arch and removed the Sabayon
overlay. So my system seems to be pure gentoo now, with only a few
remnants of Sabayon: the boot splash, for instance, and the fact that
Sabayon per default creates all file systems on a logical volume. I'll
have to make some corrections to my fs setup sometime, like move /boot
off the volume and make a separate /home partition. Blegh.

> -- 
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
> 

Thanks for the help, I guess this means it ought to be reported as a
bug.
-- 
Marc Joliet

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: [gentoo-user] Collisions when compiling glibc-2.5-r3 and r4 on amd64

[Duncan]

Marc Joliet <marcec@gmx.de> posted
1184510146.11699.33.camel@marcec.huntemann.uni-oldenburg.de, excerpted
below, on  Sun, 15 Jul 2007 16:35:46 +0200:

> I only activated [collision-protect] because I also run games and I
> recall it being recommended to activate it when using 3rd party
> binaries.

Makes a lot of sense.  My /personal/ feelings on binary-only... well, 
just look at my sig.  So I don't have that particular problem, but 
collision-protect makes a lot of sense if folks /do/ choose to install 
that sort of thing. 
 
>> Have you seen http://bugs.gentoo.org/show_bug.cgi?id=80846 (which is
>> linked from the bug you mentioned)?  It looks like either that bug or a
>> special case very similar to that bug.  What portage are you running? 
>> Is it the 2.1.2 series past the -pre1 mentioned in that bug?  Is
>> portage updated to the latest stable on your system?
> 
> No, I haven't seen it. Though I can't tell if it may be related, plus
> the bug is marked "resolved fixed", so I assume it still is. Though I am
> confused as to how a collision in glibc could have been missed. That's
> why I thought it may be an error on my account, or a broken file
> somewhere (and the likes).

Well, resolved-fixed means there's an ebuild with the fix available, but 
whether it has reached stable or not is an entirely different question.  
Additionally, regressions aren't entirely unheard of.  Occasionally, some 
bugs reappear, for various reasons, and must be squashed once again.

Of course, as I said, I'm not sure if this is exactly the same bug or 
simply related...  There are also various complexities with collision-
protect as the bug explains.  I'm not entirely sure there's a proper 
solution to all of them at the same time, which then implies that "hack" 
solutions like simply exempting specific files, may be necessary.  
However, I'm far from expert enough to know if this is such a case, and 
the fact that it's occurring on a package as basic as glibc... yes, it 
needs to be filed as a bug and /something/ fixed, even if it's ultimately 
just a hack.

> Also, I am very up to date. I run a cron-job every day at 23:00 to sync
> and then manually update. So I have the most recent stable of everything
> I have, along with a select few applications as ~amd64 and exactly 3
> packages unmasked (ut99 related packages).

Well, there's also the whole "--deep" thing.  Without --deep added to 
your updates, portage updates stuff in your world file (or specifically 
listed as system by your profile), but not necessarily "deep" 
dependencies thereof.  For example, portage is part of system so it'd be 
updated in any case, but it depends on python.  python would only be 
updated if you specify --deep, if portage (or some other package) 
specifies that it needs something newer than you have merged, or when the 
particular version you have merged gets masked or removed from the 
tree.  /Normally/, outdated dependencies are caught and the ebuild 
updated to require newer versions if necessary, but newer versions do 
often include bug fixes for corner cases, and sometimes those corner 
cases aren't always caught.

Here, I just use --deep on my emerge --update world runs as a matter of 
course, so I know I always have the latest unmasked versions available.  
It does avoid problems on occasion, but the tradeoff is that sometimes 
updating those deep dependencies forces a recompile of other things (what 
revdep-rebuild is designed to catch), so there's rather more compiling to 
be done than there would be if I didn't choose to use --deep.

So it's up to you.  More compiling with --deep, or less compiling, but 
chasing down the occasional additional bug, if you don't use --deep.

Anyway, as you can see, there's more to the question of whether you are 
up to date, than the question on its surface would imply.

(Oh, in case you were wondering, my meatspace friends too have learned to 
ask someone else if they want a simple answer.  If they ask me, 10 
minutes after they've generally lost interest because all they wanted was 
a simple 2 second general case yes/no, I'm still explaining all the 
special-case caveats and exceptions to the general rule, when they occur 
and why, and what can be done to avoid the corner case or ameliorate the 
situation when it does occur.  =8^\  At least on newsgroups and lists, 
there's opportunity for a variety of responses, so folks can pick the one 
they want, detailed or not.  Mine are generally the latter. =8^] )

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list