| 1 |
Moin, |
| 2 |
|
| 3 |
On Wed, 08 Mar 2006 05:07:07 +0100 Jan Girlich <vollkorn@×××××××.de> |
| 4 |
wrote: |
| 5 |
|
| 6 |
> Da ich mit der uclibc schon Probleme hatte [3] und pam_ldap und |
| 7 |
> nss_ldap die glibc in den Abhängigkeiten haben, dachte ich mir |
| 8 |
> einfach auf die glibc zu wechseln. |
| 9 |
> |
| 10 |
> Meine Vorstellung von dem Wechsel sieht so aus: |
| 11 |
> 1. emerge glibc |
| 12 |
> 2. CHOST="armeb-softfloat-linux-uclibc" ändern in |
| 13 |
> CHOST="armeb-softfloat-linux-gnu" |
| 14 |
> 3. emerge world |
| 15 |
> |
| 16 |
> Dazu muss ich aber anmerken, dass ich fast gar nichts über die |
| 17 |
> toolchain weiß. |
| 18 |
|
| 19 |
Genau die wirst du dir damit auch zerschießen. gcc, binutils & Co |
| 20 |
laufen nach dem "emerge glibc" nämlich nicht mehr. |
| 21 |
|
| 22 |
> Das Kompilieren der glibc schlägt fehl. Ist das ein prinzipieller |
| 23 |
> Fehler aufgrund meiner Vorgehensweise? Oder sollte mein Plan so |
| 24 |
> funktionieren? Was habe ich hier nicht bedacht? |
| 25 |
|
| 26 |
Hm, warum das Kompilieren fehlschlägt, weiß ich auch nicht. Dein Auszug |
| 27 |
sieht so aus, als würde evtl. was falsches aus dem laufenden System mit |
| 28 |
eingelinkt. Allerdings kann das am CHOST liegen, genaugenommen ist das |
| 29 |
Kompilieren der glibc ja quasi ein Cross-Compile. Aber du zerschießt |
| 30 |
dir damit eh das System, also lieber gleich lassen... |
| 31 |
|
| 32 |
Der Weg uclibc->glibc geht mindestens über eine komplette neue |
| 33 |
Toolchain. Im Falle von Gentoo würde ich mir also gleich ein |
| 34 |
glibc-stage nehmen und nochmal anfangen. Um ein "emerge -e world" wärst |
| 35 |
du eh nicht drum herum gekommen. |
| 36 |
|
| 37 |
-hwh |
| 38 |
|
| 39 |
-- |
| 40 |
gentoo-user-de@g.o mailing list |
Archives