# [gelöst] wget: relocation error nach emerge -u world

## ereuter

Hallo,

ich wollte mal gentoo ausprobieren und habe es laut Installationsanleitung installiert - das hat auch einigermaßen funktioniert.

Aber als ich ein emerge -u world machte um das System auf einen aktuellen Stand zu bekommen, wurde das System gleich fast unbrauchbar gemacht. Ich kann nämlich kein wget ausfürhen und damit auch nichts emergen bzw. ich muss alles händisch aus dem Internet kopieren.

Folgende Fehlermeldung erhalte ich nach der Eingabe von wget:

wget: relocation error: /lib/libpthread.so.0: symbol __vdso_clock_gettime, version GLIBC_PRIVATE not defined in file libc.so.6 with link tim reference

Zu meinem System: Das ganze läuft auf einem Athlon 64 und ich habe natürlich die 64-Bit-Version genommen.

CFLAGS = "-march=athlon64 -O2 -pipe"

USE = "mmx sse sse2 -gnome qt4 -eds -evo amd64"

Auszug aus emerge --info

Portage 2.1.6.7 (default/linux/amd64/2008.0, gcc-4.1.2, glibc-2.8_p20080602-r1, 2.6.27-gentoo-r8 x86_64)

System uname: Linux-2.6.27-gentoo-r8-x86_64-AMD_Athlon-tm-_64_Processor_3200+-with-glibc2.2.5

Leider habe ich im Internet keine Informationen dazu gefunden. Irgendwie kommt mir das uname mit glibc2.2.5 spanisch vor, ich habe den Kernel aber schon neu kompiliert (mit genkernel) und glibc und wget mit Abhängigkeiten neu kompiliert - der Fehler hat sich jedoch nicht beseitigen lassen.

Hat jemand einen Hinweis für mich, was ich falsch gemacht habe, und wie ich das wieder hinbekommen kann?

Beste Grüße

ElisabethLast edited by ereuter on Tue Mar 31, 2009 6:31 am; edited 1 time in total

----------

## Max Steel

Hierbei hilft allermeistens ein revdep-rebuild aus dem Paket gentoolkit, oder ein emerge @preserved-rebuild mit portage-2.2

Wenn du portage-1.6 installiert und gentoolkit nicht installiert hast würde ich dir ein emerge -a =wget-<aktuellePaketversion> (rausfindbar durch emerge --search wget oder eix wget (2teres definitiv schneller)).

Der Fehler ist relativ einfach, es bedeutet nur das durch ein wget gegen eine lib gelinkt ist die nach einem update nicht mehr verfügbar ist, da hilft ein einfaches rebuilden von wget ^^

Ansonsten, Herzlich Willkommen bei Gentoo und im Forum.

Edith: Hmm hätt genauer lesen sollen, sorry, dann wirst du damit vermutlich nicht weit kommen...

Kannst du mal den kompletten emerge --info output hier posten?

----------

## Polynomial-C

Bitte poste mal die Ausgabe von den folgenden zwei Befehlen hier rein: 

```
emerge -qpv glibc gcc

emerge --info
```

Solange wget nicht funktioniert kannst du ja ersatzweise mal net-misc/axel installieren. Am Ende des emerge-Vorgangs bekommst du dann auch noch gesagt, was du in deine /etc/make.conf eintragen mußt, damit portage axel statt wget verwendet. Wenn du wget wieder in Ordnung bekommen hast, kannst du das ja dann wieder rückgängig machen.

----------

## ereuter

Vielen Dank für die Hilfe.

revdep-rebuild sagt: Dynamic linking on your system is consistent... All done

```
emerge -qpv glibc gcc
```

  liefert

```
[ebuild   R   ] sys-libs/glibc-2.8_p20080602-r1  USE="(multilib) nls -debug -gd -glibc-omitfp (-hardened) -profile (-selinux) -vanilla"

[ebuild  NS   ] sys-devel/gcc-4.3.2-r3 [4.1.2] USE="fortran mudflap (multilib) nlsopenmp (-altivec) -bootstrap -build -doc (-fixed-point) -gcj -gtk (-hardened) -ip28 -ip32r10k -libffi -multislot (-n32) (-n64) -nocxx -nopie -objc -objc++ -objc-gc -test -vanilla"
```

und 

```
emerge --info
```

 liefert

```
Portage 2.1.6.7 (default/linux/amd64/2008.0, gcc-4.1.2, glibc-2.8_p20080602-r1, 2.6.27-gentoo-r8 x86_64)                                                              

=================================================================                  

System uname: Linux-2.6.27-gentoo-r8-x86_64-AMD_Athlon-tm-_64_Processor_3200+-with-glibc2.2.5                                                                         

Timestamp of tree: Mon, 30 Mar 2009 05:45:01 +0000                                 

app-shells/bash:     3.2_p39                                                       

dev-lang/python:     2.4.4-r13, 2.5.2-r7                                           

dev-python/pycrypto: 2.0.1-r6                                                      

sys-apps/baselayout: 1.12.11.1                                                     

sys-apps/sandbox:    1.2.18.1-r2                                                   

sys-devel/autoconf:  2.63                                                          

sys-devel/automake:  1.10.2                                                        

sys-devel/binutils:  2.18-r3                                                       

sys-devel/gcc-config: 1.4.0-r4                                                     

sys-devel/libtool:   1.5.26                                                        

virtual/os-headers:  2.6.27-r2                                                     

ACCEPT_KEYWORDS="amd64"                                                            

CBUILD="x86_64-pc-linux-gnu"                                                       

CFLAGS="-march=athlon64 -O2 -pipe"                                                 

CHOST="x86_64-pc-linux-gnu"                                                        

CONFIG_PROTECT="/etc"                                                              

CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/terminfo /etc/udev/rules.d"                                                                 

CXXFLAGS="-O2 -pipe"                                                               

DISTDIR="/usr/portage/distfiles"                                                   

FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch"                                                        

GENTOO_MIRRORS="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ "                 

LDFLAGS="-Wl,-O1"                                                                  

MAKEOPTS="-j2"                                                                     

PKGDIR="/usr/portage/packages"                                                     

PORTAGE_CONFIGROOT="/"                                                             

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

USE="acl amd64 berkdb bzip2 cli cracklib crypt cups dri fortran gdbm gpm iconv ipv6 isdnlog midi mmx mudflap multilib ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection session spl sse sse2 ssl sysfs tcpd unicode xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbmauthz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo"

Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

```

Zu axel: Ich habe es mit axel anstatt wget hinbekommen. Falls noch jemand das selbe Problem hat, hier die Vorgehensweise:

1. Unmaskieren für die 64-Bit-Version

2. ebuild /usr/portage/net-misc/axel/axel-[Version].ebuild diggest  (ansonsten komt ein Fehler dass axel maskiert ist, weil korrupt)

3. in der make.conf nicht den Vorschlag von axel eintragen sondern:

```
FETCHCOMMAND="/usr/bin/axel -n 1 -a -o ${DISTDIR}/\${FILE} \${URI}"

RESUMECOMMAND="$FETCHCOMMAND}"
```

Das -n 1 kann man wahrscheinlich weglassen.

Beste Grüße

Elisabeth

----------

## Polynomial-C

 *ereuter wrote:*   

> 2. ebuild /usr/portage/net-misc/axel/axel-[Version].ebuild diggest  (ansonsten komt ein Fehler dass axel maskiert ist, weil korrupt)

 

Seltsam, das Problem hatte ich nicht, als ich testweise axel installiert habe. Mach mal bitte ein 

```
emerge --sync
```

und schaue, ob das Problem dann immer noch besteht. Falls ja, überprüfe mal bitte deine Festplatte, weil diese dann mit großer Wahrscheinlichkeit Defekte aufweist.

Zu deinen weiteren Angaben: Du hast das "vanilla" USE flag nicht gesetzt, das ist schonmal gut. Wenn man sich dein "emerge --info" anschaut, sieht auch alles in Ordnung aus. Du könntest noch 

```
CXXFAGS="${CFLAGS}"
```

 in deine /etc/make.conf eintragen, dann würden auch C++ Programme mit -march=athlon64 kompiliert.

 *ereuter wrote:*   

> Irgendwie kommt mir das uname mit glibc2.2.5 spanisch vor

 Muß es nicht, das ist seit portage-2.1.6 offenbar "Standard" (bitte frag mich nicht, warum). Bei mir wird das gleiche angezeigt: 

```
System uname: Linux-2.6.27.21-x86_64-Intel-R-_Pentium-R-_4_CPU_3.00GHz-with-glibc2.2.5
```

Falls niemand eine bessere Lösung zu dem Problem bieten kann, empfehle ich mal das gesamte System neu zu kompilieren: 

```
emerge -e system && emerge -e world
```

Das doppelte Kompilieren der Systempakete hat den Zweck, die toolchain definitiv vor allen anderen Paketen aus dem worldfile zu kompilieren.

----------

## ereuter

Hallo,

ich habe jetzt noch einmal ein emerge --sync und nach dem unmaskieren von amd64 in axel-2.3-r1 erhalte ich wieder die gleiche Meldung:

```
Calculating dependencies - * Digest verification failed:

 * /usr/portage/net-misc/axel/axel-2.3-r1.ebuild

 * Reason: Filesize does not match recorded size

 * Got: 1568

 * Expected: 1569

... done!

!!! All ebuilds that could satisfy "net-misc/axel" have been masked.

!!! One of the following masked packages is required to complete your request:

- net-misc/axel-2.3-r1 (masked by: corruption)

- net-misc/axel-1.1 (masked by: ~amd64 keyword)

For more information, see the MASKED PACKAGES section in the emerge

man page or refer to the Gentoo Handbook.

```

Ich kann mir nicht vorstellen, dass das die Schuld der Festplatte ist. 

ich habe jetzt ein emerge -e system u. emerge -e world ausgeführt und hoffe, dass das das Problem mit wget behebt.

Beste Grüße

Elisabeth

----------

## Polynomial-C

```
zeromancer:~ # ls -l /usr/portage/net-misc/axel/axel-2.3-r1.ebuild

-rw-r--r-- 1 portage portage 1569 Feb  7 11:28 /usr/portage/net-misc/axel/axel-2.3-r1.ebuild

zeromancer:~ # emerge -av axel

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N    ] net-misc/axel-2.3-r1  USE="-debug -kde nls" 44 kB

Total: 1 package (1 new), Size of downloads: 44 kB

Would you like to merge these packages? [Yes/No]
```

Es muß nicht zwingend an der Festplatte liegen, allerdings verwundert es schon, daß der ebuild bei dir als "corrupt" angezeigt wird. Vor allem fehlt der Datei anscheinend nur ein Byte.

----------

## ereuter

Hallo nocheinmal,

ich bin mittlerweile draufgekommen, warum der Fehler mit Digest verification failed gekommen ist und möchte es hier die Ursache posten - damit andere Anfänger nicht das selbe Problem bekommen:

Ich habe das unmaskieren falsch gemacht - nämlich durch editieren der axel-ebuild-Datei. Dadurch ändert sich natürlich die Größe der Datei und somit ist die Fehlermeldung verständlich.

Deshalb an alle, die auch auf diese Weise unmaskieren: Macht es besser über /etc/portage/package.keywords. Da habt ihr auch nicht das Problem, dass beim nächsten sync die ebuild-Datei wieder überschrieben wird.

Beste Grüße

Elisabeth

----------

## 69719

Beim nächsten mal einfach das Handbuch lesen, es wurde ja nicht umsonst erstellt  :Wink: 

http://www.gentoo.org/doc/de/handbook/handbook-x86.xml?part=3&chap=3#doc_chap3

----------

## ereuter

Hallo,

das Neukompilieren hat bezüglich meinem wget-Problem keine Verbesserung gebracht. Auch das Ausweichen auf andere Versionen als 1.11.1 war umsonst. Zusätzlich tritt das Problem auch bei svn auf:

```
svn: relocation error: /usr/lib64/libc.so.6: symbol _dl_tls_get_addr_soft, versionGLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
```

Damit wird das neue System immer mehr unbrauchbar, zumal auch kde4 wohl nicht richtig will - schon eines der ersten Pakete konnte nicht kompiliert werden: dev-db/sqlite-3.6.11

```
x86_64-pc-linux-gnu-gcc -march=athlon64 -O2 -pipe -DSQLITE_OS_UNIX=1 -I. -I./src -D_HAVE_SQLITE_CONFIG_H -DNDEBUG -DSQLITE_ALLOW_XTHREAD_CONNECT=1 -DSQLITE_THREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -Wl,-O1 -DHAVE_READLINE=1 -I/usr/include/readline -o .libs/sqlite3 ./src/shell.c  ./.libs/libsqlite3.so -lreadline -lpthread  -Wl,--rpath -Wl,/usr/lib64                              

/usr/lib64/libdl.so.2: undefined reference to `_dl_tls_get_addr_soft@GLIBC_PRIVATE'

collect2: ld returned 1 exit status                                                

make: *** [sqlite3] Error 1                                                        

 *                                                                                 

 * ERROR: dev-db/sqlite-3.6.11 failed.                                             

 * Call stack:                                                                     

 *               ebuild.sh, line   49:  Called src_compile                         

 *             environment, line 3232:  Called die                                 

 * The specific snippet of code:                                                   

 *       emake TCLLIBDIR="/usr/$(get_libdir)/${P}" || die "emake failed"           

 *  The die message:                                                               

 *   emake failed                                                                  

 *

 * If you need support, post the topmost build error, and the call stack if relevant.

 * A complete build log is located at '/var/tmp/portage/dev-db/sqlite-3.6.11/temp/build.log'.

 * The ebuild environment file is located at '/var/tmp/portage/dev-db/sqlite-3.6.11/temp/environment'.

 *

```

Ich habe mich da vorerst einmal damit beholfen, dass ich in den USE-Variablen -sqlite hinzugefügt habe und schaue mal, wie weit ich bei KDE komme.

Habe ich da irgendwo was grundsätzlich falsch gemacht, oder die amd64-Version generell etwas unausgereifter? Leider kann ich nicht auf eine 32-Bit-Version ausweichen, weil ich für 8GB RAM platz haben muss.

Ich habe das kde4-overlay meiner Meinung nach streng nach Vorschrift als empfohlenen Weg gemacht - einfach emerge kde4 hat ja leider nicht funktioniert  :Sad: 

Beste Grüße

Elisabeth

----------

## mv

Die libdl.so.2 aus Deiner glibc sollte in /lib64 liegen: 

```
equery files glibc
```

 sollte das anzeigen, bzw. falls das nicht geht: 

```
cat /var/db/pkg/sys-libs/glibc*/CONTENTS
```

Wenn das korrekt ist, ist Dein Problem die Datei /usr/lib64/libdl.so.2, die vermutlich zu irgendeiner anderen Version der glibc gehört, die nicht mehr bei Dir auf dem System ist. Da offensichtlich diese statt der korrekten benutzt wird, kann es nicht funktionieren. Natürlich kannst Du die Datei einfach löschen. Es ist allerdings zu vermuten, dass wenn Du eine solche "fehlerhafte" Bibliothek hast, sich noch mehr solcher cruft auf Deinem System angesammelt hat, den Du löschen solltest. Es geisterten mal verschiedene "findcruft"-Scripte herum, die alle Files finden, die zu keinem der */CONTENTS-Files gehören (und die nicht zu einer "Blacklist" von Files gehören, von denen bekannt ist, dass sie erst zur Laufzeit erzeugt werden). Falls Du mit dem derzeit Forum-eingeschränkten Google diese Scripte finden kannst, würde ich sie mal installieren und damit zumindest /lib* und /usr/lib* und deren Unterdirectories gründlich aufräumen.

----------

## ereuter

Das mit den libs war genau der richtige Tipp - vielen Dank.

Ich habe alle Dateien in /usr/lib* gelöscht, die aus dem Vorjahr bez. noch älter waren - schließlich habe ich ja das ganze System oft genug neu kompiliert so dass allle Dateiien neu sein müssten - jetzt funkioniert alles wieder tadellos - ich hoffe es bleibt so.

Beste Grüße

Elisabeth

----------

