# die Power vom großen (Win-)Rechner nutzen, kein distcc

## slick

Folgendes Szenario:

Wir haben einen kleinen Gentoo-Rechner auf dem umfangreiche Compilierungsarbeiten durchzuführen sind und würden gern den leistungsstarken Spiele-Rechner von Oma  dafür nutzen, welcher auch im häuslichen LAN hängt. Auch haben wir ggf. alle benötigten Pakete bereits mit emerge -f heruntergeladen, da ich hier auf ggf. nötige Konfiguration für Internet nicht eingehen will.

Hinweis: Die hier beschriebenen Einstellungen eignen sich nicht für die Verwendung in unsicheren LANs, da hier auf das Thema Sicherheit nicht eingegangen wird.

Hinweis: Das hier beschriebene Verfahren eignet sich nur für Rechner welche die gleiche Architektur haben. Also wenn z.B. beide x86 sind. Hier sollte jedoch beachtet werden das bei verschiedenen Prozessoren (z.B. AMD vs. Intel) keine zu harten Optimierungen gewählt werden können, da der Code ja auf beiden Maschinen laufen muss. Meist wird es sich jedoch in diesem Szenario um einen "alten" und einen "neuen" Rechner handeln, wo die Optimierung für den "alten" Rechner auf dem "neuen" lauffähig sein sollte. 

Wir benötigen dazu:

1 Tageskarte für den Zoo

1 Knoppix-CD

diese Anleitung

Als erstes müssen wir Oma loswerden. Wir schenken Ihr die Tageskarte für den Zoo und sind ihr behilflich das Haus zu verlassen. So, sturmfreie Bude und los gehts. Wir werfen die Knoppix-CD in Oma's Super-Rechner (in nachfolgendem auch SUPER genannt) und booten von selbiger. Da wir die grafische Oberfläche nicht benötigen booten wir am boot-prompt mit der Eingabe

```
knoppix 2
```

Dadurch bootet SUPER nur im Textmodus. Wir konfigurieren mit Hilfe von 

```
netcardconfig
```

unsere Netzwerkkarte. So weit, so gut.

Weiter am kleinen Gentoo-Rechner, im folgenden auch MINI genannt. Wir werden jetzt am MINI eine NFS-Server aufsetzen, dazu benötigen wir die NFS-Unterstützung im Kernel, siehe File systems -->Network File Systems --> <*>NFS file system support und <*>NFS server support und die nfs-utils

```
emerge nfs-utils
```

Wir editieren die Datei /etc/exports wie folgt:

/etc/exports

```
/         192.168.0.1(rw,async,no_root_squash)

/boot     192.168.0.1(rw,async,no_root_squash)
```

Hierbei ist die IP von SUPER zu setzen.  Die o.g. exports ist passend für eine Standard-Gentoo Installation gemäß Handbuch. Jede unter MINI gemountete Partition sollte durch eine entsprechende Zeile mit ihrem jeweiligen mountpoint eingetragen werden. 

Die ist daduch zu erklären das der NFS-Server nur jeweils das "Eltern-Dateisystem" exportiert, aber nicht die darin gemounteten Dateisysteme. Aus diesem Grund müssen diese extra exportiert werden.

Hinweis: Es existiert zwar die nohide Option, von welcher aber in der manpage von exports abgeraten wird. Deswegen kommt selbige hier nicht zum Einsatz.

Wir starten den NFS-Server mit

```
/etc/init.d/nfs start
```

und gehen wieder an SUPER. Wir erstellen uns ein Verzeichnis und mounten die exportieren Partitionen von MINI sowie proc 

```
/etc/init.d/portmap start

/etc/init.d/nfs-common start

mkdir /lokal

mount 192.168.0.2:/ /lokal

mount 192.168.0.2:/boot /lokal/boot

mount -t proc proc /lokal/proc

```

Hierbei ist als IP die IP von MINI zu verwenden. 

Hinweis: Wer beim Kompilieren Probleme hat sollte beim mounten die NFS-Optionen probieren die BuLLy weiter unten gepostet hat. 

Optional (1.)

Um das entpacken/kompilieren zu beschleunigen sollten /tmp und vor allem /var/tmp lokal auf SUPER verwendet werden. 

Vorraussetzung für dieses Optional (1.): Unser Windows befindet sich hierbei auf einer FAT-Partition (NTFS auf eigene Gefahr!) und es handelt sich um ein von Knoppix gebootetes System, gemäß dieser HowTo.

Wir mounten die Windows-Partition (hda1) und erzeugen uns eine große leere Datei, optimal min. 2GB, wenn möglich und entsprechend Platz auf der Windowspartition entsprechend größer.

```
mkdir /win

mount /dev/hda1 /win

dd if=/dev/zero of=/win/tmpfile count=1 seek=1999 bs=1M
```

Wir formatieren diese Datei als ext2-Dateisystem und mounten sie als lokales /tmp

```
mke2fs /win/tmpfile

mount -o loop /win/tmpfile /tmp
```

Nun binden wir das noch in die spätere chroot-Umgebung ein

```
mount -o bind /tmp /lokal/tmp

mount -o bind /tmp /lokal/var/tmp
```

Optional (2.)

Sollte es sich bei SUPER um einen Gentoo-Rechner handeln und die Anleitung wurde nur "grob" beachtet (also für Leute die sich auskennen) bestehen folgende Möglicheiten:

Optional (2.1)

Hier können /tmp und /var/tmp direkt eingebunden werden, da diese vermutlich schon entsprechend passend sind

```
mount -o bind /tmp /lokal/var/tmp

mount -o bind /tmp /lokal/tmp
```

Optional (2.2)

Wer die distfiles schon alle auf SUPER liegen hat kann diese ebenfalls mit einbinden.

```
mount -o bind /usr/portage/distfiles /lokal/usr/portage/distfiles
```

Optional (2.3)

Wer den Portagetree von SUPER benutzen möchte kann diesen analog wie oben mounten und sollte dann im chroot auf jeden Fall zuerst ein emerge metadata anstoßen.

--Ende Optionales--

Jetzt haben wir unser komplettes Dateisystem von MINI unter /lokal liegen und brauchen es nurnoch chrooten und schon kanns losgehen.

```
chroot /lokal

env-update 

source /etc/profile
```

Jetzt können wir die Rechnerpower von SUPER nutzen um auf MINI fleissig zu installieren.

Sind wir fertig, rebooten wir SUPER sauber und stoppen auf MINI den NFS-Server. Vorsichtshalber sollten wir auch die Zeilen in /etc/exports auskommentieren. Nicht vergessen die Knoppix-CD aus Omas Rechner wieder zu entfernen. Oma wundert sich sonst... apropos Oma.. nix hin wie zum Zoo und sie abholen...

Feedback welcome.Last edited by slick on Sun Oct 02, 2005 2:52 pm; edited 15 times in total

----------

## Sas

Ich hätte jetzt zwar ein HowTo für distcc unter Windows erwartet, aber das ist auch gut. Grüß deine Oma von mir  :Wink: 

----------

## slick

Titel überarbeitet  :Wink: 

----------

## _hephaistos_

@Sas: gute idee -> das distcc mit windows werde ich mir mal anschauen. kann ich wenigstens im windows online bleiben -> weil media player is nach wie vor der einzige, der meinen lieblingssender (https://forums.gentoo.org/viewtopic.php?t=185234&highlight=media+streaming) abspielen kann  :Smile: 

ciao

----------

## superuser

Danke fuer die Tutorial  :Smile: 

----------

## nic0000

Sehr cool!

Habe gerade meinen alten 366mhz p2 laptop mit einem 2,4Ghz "gemacht".

danke

----------

## BuLLy

Wie lang hat das gedauert?

Ging es viel schneller als ohne?

Hab gestern auch versucht über nfs mein 466 MHz Mininotebook zu installieren,

aber das entpacken der einzelnen Pakete hat ewig gedauert, so dass es nicht wirklich schneller war.

gruß

BuLLy

----------

## slick

Um das entpacken/kompilieren zu beschleunigen sollte man /var/tmp local ablegen statt über nfs zu benutzen. Also vor dem chroot noch folgendes ausführen:

```
mount -o bind /var/tmp /lokal/var/tmp

mount -o bind /tmp /lokal/tmp
```

Ich ergänz das mal oben.

EDIT: Ok, ganz so einfach wars nun doch nicht, weil ja Knoppix kein entsprechend großes /tmp hat. Habe mal versucht es oben entsprechend darzustellen. Ich verwende meist ein anderes Gentoo-System als "SUPER" wo ein einfaches bind-mounten von /tmp und /var/tmp ausreicht.

----------

## nic0000

Hi

 *BuLLy wrote:*   

> Wie lang hat das gedauert?
> 
> Ging es viel schneller als ohne?

 

```
 # genlop -t xorg-x11

 * x11-base/xorg-x11

     Wed Aug  3 00:26:50 2005 >>> x11-base/xorg-x11-6.8.2-r2

       merge time: 3 hours, 32 minutes and 27 seconds.

     Tue Sep 27 09:20:35 2005 >>> x11-base/xorg-x11-6.8.2-r4

       merge time: 1 hour, 3 minutes and 10 seconds.

```

und 

```
 # genlop -t glibc

 * sys-libs/glibc

     Fri Aug  5 17:07:48 2005 >>> sys-libs/glibc-2.3.5

       merge time: 2 hours, 59 minutes and 31 seconds.

     Tue Sep 27 07:49:57 2005 >>> sys-libs/glibc-2.3.5-r1

       merge time: 36 minutes and 35 seconds.

```

und noch

```

genlop -t mozilla-firefox

 * www-client/mozilla-firefox

     Fri Aug  5 08:43:11 2005 >>> www-client/mozilla-firefox-1.0.6-r2

       merge time: 3 hours, 24 minutes and 22 seconds.

     Tue Sep 27 13:07:36 2005 >>> www-client/mozilla-firefox-1.0.6-r7

       merge time: 1 hour, 8 minutes and 41 seconds.

```

und jetzt mal etwas kleines

```

 # genlop -t kismet

 * net-wireless/kismet

     Fri Aug  5 10:05:39 2005 >>> net-wireless/kismet-2005.06.1

       merge time: 17 minutes and 59 seconds.

     Tue Sep 27 13:11:41 2005 >>> net-wireless/kismet-2005.08.1

       merge time: 4 minutes and 5 seconds.

```

Das muss ich jetzt nicht kommentieren, oder?   :Very Happy: 

 *BuLLy wrote:*   

> Hab gestern auch versucht über nfs mein 466 MHz Mininotebook zu installieren,
> 
> aber das entpacken der einzelnen Pakete hat ewig gedauert, so dass es nicht wirklich schneller war.

 

Kann ich nicht so nicht bestätigen. Klingt für mich als hättest du portmap nicht eingeschaltet. Ohne Portmap sind Zugriffe über NFS eine Qual.

viel Erfolg

Die oben gezeigten Ergebnisse sind ohne lokalen /tmp  und /var/tmp erreicht worden. Ich werde mal bei der nächsten Gelegenheit auch diese Variante ausprobieren und die Ergebnisse dann mal hier posten. 

@slick

Wirklich sehr gute Sache das. Respekt!

nico

----------

## BuLLy

Die Sache mit dem Tmp werde ich gleich mal ausprobieren....

Portmap war an. Vielleicht muss ich es einfach nur nochmal ausprobieren...

EDIT: Hab es jetzt nochmal probiert. Habe auch /var/tmp und /tmp gemountet, jedoch bricht die Installation beim ersten Punkt (Portage) beim bootstrapen ab. Hab mal im Forum geschaut und hier eine mögliche Lösung entdeckt.

Ich werde die genannten Optionen gleich mal ausprobieren und nachher berichten.

EDIT2: Es scheint zu funktionieren. Jedenfalls hat beim bootstrap portage nicht mehr wegen Locks geweint.  :Wink: 

Ich möchte mich nochmal wegen der schnellen Antworten bedanken. So macht das echt Spass.

gruß

BuLLy

----------

## nic0000

 *BuLLy wrote:*   

> 
> 
> Ich möchte mich nochmal wegen der schnellen Antworten bedanken. So macht das echt Spass.

 

You welcome.

Wenn die "geholfenen" auch Ihre Erfahrungen und Lösungswege in den Thread posten macht das schnelle Antworten ja auch spaß.  :Wink: 

grüße 

nico

----------

## magicteddy

Moin,

vielen Dank für Deine Anleitung, ich installiere gerade Gentoo auf dem Notebook meiner Frau.

Dein Posting hatte ein perfektes Timimg!

Es ist doch ein kleiner Unterschied ob ich auf einem P3, 1 Ghz 256MB Ram oder einem P4 3Ghz mit 1GB Ram compiliere  :Very Happy:  .

-andreas

----------

## slick

 *magicteddy wrote:*   

> Dein Posting hatte ein perfektes Timimg!

 

Das HowTo ist von August 04  :Wink:   :Cool: 

----------

## magicteddy

 *slick wrote:*   

>  *magicteddy wrote:*   Dein Posting hatte ein perfektes Timimg! 
> 
> Das HowTo ist von August 04  

 

Stimmt   :Very Happy: , sollte ich doch mal zum Optiker gehen?

nic0000 hats aus der Versenkung geholt, dem gilt natürlich auch mein Dank.

Damit der "Kleine" auch etwas zu tun hat habe ich ihm auch ein wenig Arbeit verpaßt,

Sachen die sowieso installiert werden darf er schon mal fetchen. Somit braucht der Große nicht auf die Downloads warten und der Kleine macht inzwischen keine Dummheiten  :Razz:  .

```
emerge -avf PAKETNAME
```

-andreas

----------

## BuLLy

Die Stage-1-Installation hat wunderbar geklappt.

Ich hab nachträglich nochmal versucht mit den oben genannten nfs-Einstellungen zu kompilieren, das schlägt jedoch fehl.

Ich muss die folgenden Einstellungen nehmen, die ich im oben genannten Thread gefunden hatte.

/etc/exports

```
/       192.168.1.0/24(sync,rw,no_root_squash)
```

mount des ganzen:

```
mount -t nfs 192.168.1.20:/ /mnt/gentoo/ -o auto,rw,hard,intr,nolock 
```

Trotzdem funktioniert das sehr gut.

Ich werde nachher mal ein paar Geschwindigkeitunterschiede Posten.

gruß

BuLLy

----------

## BuLLy

Hier die versprochenen emerge-Zeiten:

Die Zeiten stimmen nicht, bei meinem Großen Rechner ging die Uhr nach...  :Wink: 

```
# genlop -t mc

 * app-misc/mc

     Sun Oct  2 16:37:44 2005 >>> app-misc/mc-4.6.0-r14

       merge time: 10 minutes and 12 seconds.

     Sun Oct  2 13:40:33 2005 >>> app-misc/mc-4.6.0-r14

       merge time: 5 minutes and 57 seconds.

```

```
 # genlop -t samba

 * net-fs/samba

     Sun Oct  2 16:11:33 2005 >>> net-fs/samba-3.0.14a-r2

       merge time: 41 minutes and 6 seconds.

     Sun Oct  2 13:57:26 2005 >>> net-fs/samba-3.0.14a-r2

       merge time: 13 minutes and 14 seconds.

```

Man sieht also, es lohnt sich wirklich...

Und damit man nicht immer die Befehle zum mounten, etc eingeben muss, erstellt man schnell ein kleines miniscript:

```
#!/bin/bash

/etc/init.d/portmap start

ssh 192.168.1.20 /etc/init.d/nfs start

mount -t nfs 192.168.1.20:/ /lokal -o auto,rw,hard,intr,nolock

mount -t proc proc /lokal/proc

mount -o bind /tmp /lokal/tmp

mount -o bind /tmp /lokal/var/tmp

chroot /lokal /bin/bash
```

Leider klappt es noch nicht, dass das env-update und source /etc/profile auch von script ausgeführt werden.

gruß

BuLLy

----------

## nic0000

 *BuLLy wrote:*   

> 
> 
> Leider klappt es noch nicht, dass das env-update und source /etc/profile auch von script ausgeführt werden.

 

Ich habe dein Skript leicht abgewandelt und jetzt geht auch mehr automatisch 

```
#!/bin/bash

MINI_IP="charon"

MINI_FS="/mnt/gentoo"

MINI_COM_1="emerge sync"

MINI_COM_2="emerge world -uDN -pv"

MINI_COM_3="emerge world -uDN"

MINI_COM_4=""

/etc/init.d/portmap start

ssh  $MINI_IP /etc/init.d/nfs start

mkdir -p $MINI_FS

mount -t nfs $MINI_IP:/ $MINI_FS -o auto,rw,hard,intr,nolock

mount -t proc proc /$MINI_FS/proc

mount -o bind /tmp /$MINI_FS/tmp

mount -o bind /tmp /$MINI_FS/var/tmp

echo -en "env-update \nsource /etc/profile \n$MINI_COM_1 \n$MINI_COM_ 2 \n$MINI_COM_3 \n$MINI_COM_4" | chroot /$MINI_FS /bin/bash
```

----------

## Abroxa

Sehr nettes Tutorial!

Eine Frage bzw. Anmerkung habe ich noch: Du sagst, die Architekturen der beiden Rechner müssen die selben sein. Das mag stimmen, aber die einzelnen Binaries können von SUPER (zB Athlon) doch mit der make.conf von MINI (zB Pentium1) auf das System optimiert werden. SUPER ist ja nur der Komilierknecht und könnte rein theoretisch doch auch Dinge kompilieren, die er selbst gar nicht ausführen kann. Oder irre ich da?

EDIT: Ich merke, ich irre gewaltig. Einfach ignorieren diesen Post  :Smile: 

Gruß

----------

## nic0000

 *Abroxa wrote:*   

> SUPER ist ja nur der Komilierknecht und könnte rein theoretisch doch auch Dinge kompilieren, die er selbst gar nicht ausführen kann.

 Das ist auch ein Gedanke der mich beschäftigt. Da ich auch mit der NSLU (arm) oder auch WRT54Gx (mips) zu tun hatte, hatte ich das auch gedacht, aaaber ich glaube (ich weiß es nicht sicher), daß dazu etwas mehr als nur der gcc nötig ist. Soll heissen, das auch andere Teile gebraucht werden um total unabhängig crosskompillieren zu können. Wo da die grenzen weiß ich aber nicht denn selbst littleendian zu bigendian und umgekehrt soll gehen.

Zu meinen Erfahrungen, es geht in der Regel problemlos von neueren Prozessor für einen älteren zu kompillieren solange man Intel und AMD nicht mischt. Wobei solange die Erweiterungen (MMX, SSE, usw.) auf beiden Systemen vorhanden sind dies trotzdem geht. Da hat der AMD natürlich die Oberhand, denn während hier alle Erweiterungen von Intel Lizensiert werden, verweigert Intel alle Erweiterungen der Konkurenz (3Dnow!, etc.). Bei 64bit habe ich keine Idee.

Ich habe nur ein Sorgenkind hier, das ist mein Laptop (p2 366mhz) und den habe ich früher mit einem AMD TB 900 dann AMD 4 1200 und jetzt P4 2600. Das geht alles problemlos dank Slick's Anleitung.  :Wink: 

----------

## slick

 *nic0000 wrote:*   

> Bei 64bit habe ich keine Idee.

 

Ich hätte da eine. Also man kann doch z.b. bei amd64 den mplayer chrooten wegen den Codecs. Warum sollte das nicht auch mit einer remote gemounteten Shell gehen? Sicher etwas performanceverlust aber sollte theoretisch funktionieren. Freue mich auf die Ergebnisse eurer diesbezüglichen Experimente  :Wink: 

----------

## nic0000

 *slick wrote:*   

> Ich hätte da eine. Also man kann doch z.b. bei amd64 den mplayer chrooten wegen den Codecs. Warum sollte das nicht auch mit einer remote gemounteten Shell gehen? Sicher etwas performanceverlust aber sollte theoretisch funktionieren

 

Das kling klug...

 *slick wrote:*   

> Freue mich auf die Ergebnisse eurer diesbezüglichen Experimente 

 Da muss ich leider passen, denn das einzige System was bei mir 64bit hat ist mein Server im Rechenzentrum  :Sad: 

Aber bestimmt weiß der Slick selbst hier einen Rat  :Wink: 

----------

## slick

 *nic0000 wrote:*   

> Aber bestimmt weiß der Slick selbst hier einen Rat 

 

Rat kann man das nicht nennen, aber Ideen  :Wink: 

Also als Vorwort sollte ich ergänzen das es sich praktisch nicht lohnen wird, es sei denn Du hängst daheim auch an einer richtig dicken Leitung und die Wege zum Rechenzentrum sind kurz, aber theoretisch sollte es gehen. Also wenn Du es probieren möchtest sorge dafür das Du möglichst vieles von lokal (/var/tmp, ... ) mountest und mache Dich auf Wartezeiten gefasst.

Das einzige für was Du sorgen mußt ist ist im Prinzip das Du NFS-Freigaben Deines Heimrechners im RZ mounten kannst. Da würde sich z.B. OpenVPN anbieten oder aber Du baust in einer SSH-Session zum RZ-Rechner einen reversen Tunnel auf und mountest NFS über TCP. Der Rest dann wie im lokalen LAN. Könntest aber auch mal sshfs o.ä. probieren, keine Ahnung ob das klappt, aber ist ja eigentlich transparent.

Ansonsten gibt es noch die Möglichkeit, bei entsprechend Plattenplatz, einfach ein x86 stage3 auf der amd64 auszupacken und dort im chroot mit buildpkg bzw. buildpkgonly zu arbeiten. Dann mußt Du das nur per Apache freigeben und den RZ-Rechner als Binhost einstellen. Das würde ich evt. sogar zuerst probieren, denn klappt das dann klappts auch mit dem Remote-Mount. Evt. ist das sogar sinnvoller, da Du Dir ständig alle Pakete vorkompilieren kannst.

----------

## nic0000

 *slick wrote:*   

> Rat kann man das nicht nennen, aber Ideen 

 Das habe ich befürchtet  :Wink: 

Mein Server fährt keine Multilib usw. Macht das was aus? Müsste eigentlich nicht wenn ich ein 32bit chroot aufbaue oder?

----------

## slick

 *nic0000 wrote:*   

> Mein Server fährt keine Multilib usw. Macht das was aus? Müsste eigentlich nicht wenn ich ein 32bit chroot aufbaue oder?

 

Keine Ahnung, fahre (noch) kein 64 Bit (sondern verteile nur Ideen dazu  :Wink: ), aber liest sich relativ einfach: http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2

----------

## sewulba

Vielleicht hilft mein Beitrag ein wenig Klarheit reinzubekommen bzw. daraus schlau zu werden.  Ich werde es auf jeden Fall nicht ganz.

Bevor ich nun dieses HowTo probiert habe. Besser gesagt bin gerade dabei. Habe ich die SCSI-Platte meine Dual Pentium Pro in meinen "Server" Quad Xeon (x86_64) gesteckt. Ganz normal in in diesem System gechrootet und darauf dann mein PPro-System mit den CFLAGS="-Os -march=pentiumpro -pipe -fomit-frame-pointer" auf dem Xeon übersetzt.

Ich habe auf dem x86_64er-System kein Multilib laufen. Ist 100% nicht in diesem GCC. 

Es gab überhaupt keine Probleme, außer mit dem Kernel. Da wollte er, bzw. hat er einen x86_64 gemacht. Ich weiss nur noch, dass auch nur ein Paket Probleme gemacht hat. Wenn ich mich recht entsinne, war es was mit KDE. Ist schon 2 Monate her. Weiss es leider nicht mehr genau!

Es ist also mit Sicherheit über NFS auch möcglich auf x86_64 für x86 ohne Multilib zu kompilieren. Hatte allerdings keine Stage1 gemacht, sondern nur Stage2! Hat sich nicht wirklich gelohnt für mich. Denn es gibt ja ein Stage2-i686. i686 ist ja wohl PentiumPro.

Mich würde interessieren, ob es bei Euch genauso, oder so ähnlich aussieht/aussah wie bei mir. Das System war bootbar, nur für den Kernel und dem einen Paket habe ich damals das System nochmal direkt chrooten müssen!

Gruss SeW   :Wink: 

----------

## nic0000

 *sewulba wrote:*   

> Da wollte er, bzw. hat er einen x86_64 gemacht.

 Da gibt es einen Trick in dem man dem "make" eine andere CHOST und noch etwas vorstellt. Bin gerade auf dem Weg, aber ich gucke heute Abend mal danach.

----------

## sewulba

 *nic0000 wrote:*   

>  *sewulba wrote:*   Da wollte er, bzw. hat er einen x86_64 gemacht. Da gibt es einen Trick in dem man dem "make" eine andere CHOST und noch etwas vorstellt. Bin gerade auf dem Weg, aber ich gucke heute Abend mal danach.

 

Das wäre super!

Ich gehe davon aus, da ich ja proc vom x86-64er System genommen habe, dass er sich da irgendwas rausgezogen hat, dass er dann nen Kernel für x86_64 machen wollte und hat!

SeW

----------

## nic0000

 *sewulba wrote:*   

> Ich gehe davon aus, da ich ja proc vom x86-64er System genommen habe, dass er sich da irgendwas rausgezogen hat, dass er dann nen Kernel für x86_64 machen wollte und hat!

 Ich habe zwar keine echte Ahnung aber ich glaube er holt sich das einfach aus dem aktuellen Kernel. 

```
uname -m
```

Ich habe leider da nichts in meinen Aufzeichnungen gefunden aber ich glaube das es so gehen müsste:

```
make ARCH="x86" CHOST="i686-pc-linux-gnu"
```

Die CFLAGS setzt es, glaube ich, selbst.

Ansonsten bisschen rumprobieren oder mal einen der Klügeren hier im Board fragen. Bin nicht so der C Held  :Sad: 

----------

## slick

Habe gerade per Zufall auch was gefunden: http://gentoo-wiki.com/HOWTO_Compile_on_another_computer

 *Quote:*   

> FIX: to compile kernel for i386 on x86_64 just append ARCH=i386 when you configure and compile your kernel: 
> 
> ```
> make menuconfig ARCH=i386
> 
> ...

 

----------

## nic0000

Moin!

In der letzten Zeit ist es mir des öfteren passiert das ich beim updaten über diese Methode am Ende _kein_ funktionierendes System hatte. Ich finde es bisschen strange, denn vorher hat das immer geklappt. Ich vermute ganz leise das eventuell sich mit dem gcc-4.1.1.x etwas geändert hat. 

Als erstes hat ein update für ein p2 auf einen athlonXP nicht funktioniert. Da dachte ich noch: "OK, auf AMD für Intel, bestimmt nicht unproblematisch" aber jetzt habe ich auf einen P4 für P3 und athlonXP für k6-2 upgedated und das hat früher immer geklappt. Früher habe ich auf diesen Maschinen sogar gechrooted und Systeme komplett vorbereitet. Jetzt klappt das auch nicht mehr. In beiden Fällen bekomme ich "Ungültiger Maschinenbefehl" oder reihenweise etwas mit "Symbol" wenn ich die Programme anstarte welche von SUPER gebaut wurden oder wenn ich den chroot den Kernel machen will. Ganz so als wenn die CHOST beim bau übergangen worden währe.

gcc-4.1.1-r3

glibc-2.5-r2

linux-headers-2.6.17-r2

----------

## peterpeterson

Hallo

ich wollte mich mit dem Lob anschliessen und auf _SeW_'s frage antworten.

Ich habe gerade mit einem Pentium D 3.20GHz einen Via C3 Samuel 2 fertig gemacht.

gcc, glibc und kernel habe ich local kompilert.

updates, apache2, mysql, postfix, cyrus-imap, perl, etc. (kein X)

Ã¼ber den grossen.

Lustigerweise habe ich nebenbei auf einem anderen Via C3 gerade ein gentoo

up-ge-date-t, der fÃ¼r die glibc genauso lange brauchte, wie der andere fÃ¼r die

gesamte Installation.  :Wink: 

cu tim

----------

## pieter_parker

hey.. noch ein p(i)eter mit auch einem c3 ^^

slick, super anleitung! danke

bevor ich mir eins meiner systeme zerlege .. sind das einzelfaelle bei euch gewesen oder sollte man generel kernel, glibc .. gcc lokal und nicht von "super" bauen lassen? wenn.. warum..

----------

## sewulba

Ich hatte eine andere Idee mittlerweile.

Ich habe im x86_64 ein linux32-Chroot gemacht und wollte mit diesem chroot meine x86er-Kiste chrooten und dann drauf zu kompilieren. Ging megamäßig schief! env-update und dann ging nix mehr.

Mein Tipp lasst es sein. Nebenbei bemerkt!

Sewulba  :Wink: 

----------

## raven88

Hallo,

ich habe auf einem Athlon-XP den gcc 4.1.2 für einen Pentium I kompiliert.

Taktik ist ein Binary zu erstellen und dies auf dem Zielhost zu entpacken.

Auf dem Kompilierknecht:

```

USE="-gtk" CHOST="i486-pc-linux-gnu" CFLAGS="-O2 -march=i486 -pipe" emerge -aB gcc

mount zielhost:/ /whatever

cp /usr/portage/packages/All/gcc-4.1.2.tbz2 /whatever/usr/portage/packages/All

```

Auf dem Zielhost

```

emerge -aK gcc

source /etc/profile

env-update

```

Jetzt wäre es natürlich cool, wenn man das ganze automatiseren könnte. (Benötigte packages, USEflags des Zielhosts auslesen, etc...)

----------

## musv

Tipp: 

Das Voranstellen von ARCH="x86" CHOST="i686-pc-linux-gnu" wurde oben schon mal genannt. Ich hatte jetzt das Problem, dass zwar die meisten Pakete im chroot compiliert haben, OpenOffice allerdings nacht allen Regeln der Kunst gescheitert ist. Siehe dazu hier:

https://bugs.gentoo.org/show_bug.cgi?id=255183

Problem:

Irgendwie findet OpenOffice trotz chroot die eigentliche Architektur des compilierenden Rechners raus und scheitert daran.

Fehlermeldung:

```
ERROR: Error 65280 occurred while making

/var/tmp/portage/app-office/openoffice-3.0.0/work/ooo/build/ooo300-m9/bridges/source/cpp_uno/gcc3_linux_x86-64
```

Lösung: 

```
setarch i686

emerge openoffice
```

----------

## slick

Habe es übrigens jetzt mal ausprobiert. Mit einem 

```
linux32 chroot /gentoo32 /bin/bash
```

konnte ich auf einem 64 Bit System problemlos in ein (CPU kompatibles) 32 Bit System wechseln und darin kompilieren. Die nötigen Verzeichnisse sollten hierfür gemountet sein (vergl. 32Bit Chroot Guide  - Listing 3.2)

----------

