From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1DyaO2-0006ab-4W for garchives@archives.gentoo.org; Fri, 29 Jul 2005 19:19:14 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j6TJH90m028319; Fri, 29 Jul 2005 19:17:09 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j6TJH8vb026415 for ; Fri, 29 Jul 2005 19:17:08 GMT Received: from mx0.vr-web.de ([195.200.35.198]) by smtp.gentoo.org with esmtp (Exim 4.43) id 1DyaMf-0003Sf-9g for gentoo-user-de@lists.gentoo.org; Fri, 29 Jul 2005 19:17:49 +0000 Received: from mx0.vr-web.de (vrwf103.vrweb.de [::ffff:192.168.27.6]) by mx0.vr-web.de with esmtp; Fri, 29 Jul 2005 21:17:49 +0200 id 00047E21.42EA80DD.00004653 Received: from kiwi.vr-web.de (pD9F86501.dip0.t-ipconnect.de [::ffff:217.248.101.1]) by mx0.vr-web.de with esmtp; Fri, 29 Jul 2005 21:17:46 +0200 id 00053E09.42EA80DB.00001A8A Received: from localhost ([127.0.0.1]) by kiwi (192.168.0.1) with news-to-mail ; Fri, 29 Jul 2005 21:16:08 +0200 To: gentoo-user-de@lists.gentoo.org Message-ID: Date: Fri, 29 Jul 2005 21:16:07 +0200 From: Thomas Schweikle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.7.8) Gecko/20050511 Hamster-Pg/1.24.1.0 X-Accept-Language: de, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user-de@gentoo.org Reply-to: gentoo-user-de@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: [gentoo-user-de] Re: Installation fuer "low end" System auf "besserem" System vorbereiten? References: <42E7F342.1030605@mid.email-server.info> <20050728155236.7494a6f3@galadriel.intern.dahlmann.net> <42EA50F4.2050306@mid.email-server.info> <20050729201355.25931298@galadriel.intern.dahlmann.net> In-Reply-To: <20050729201355.25931298@galadriel.intern.dahlmann.net> X-BitDefender-Scanner: Clean, Agent: BitDefender Courier MTA Agent 1.6.2 on vrwebmail X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.49.0 X-MIME-Autoconverted: from quoted-printable to 8bit by robin.gentoo.org id j6TJH8vb026415 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id j6TJH91K028319 X-Archives-Salt: 39f85847-a2a3-47e4-859a-55e198bf53ed X-Archives-Hash: 7e149c7e8226cafd8df06f475fab7eb0 Ace Dahlmann schrieb: > Hi! >=20 > On Fri, 29 Jul 2005 19:53:01 +0200 > Thomas Schweikle wrote: >=20 >> Das st=F6rt nicht. Wichtig ist nur, dann das Buildsystem *nicht* von >> der Gentoo-Installation auf der "gro=DFen" Kiste zu verwenden. >=20 > Wie meinst Du das? >=20 > Ich bin die ganze Zeit ab =FCberlegen, was bei Alex dann genau passiert= , > aber ich hab da wohl gerade eine logische Denkblockade. In der Regel werden in einen chroot-K=E4fig dateien, die im Hauptsystem liegen =FCbernommen. Es wird zum beispiel per "bind" der gesamte "/usr/lib"-Baum gemountet. Damit steht im chroot der gleiche Baum zur verf=FCgung wie im Hauptsystem --- nur =FCblicherweise als "read only". F=FCr Teile, bei denen das nicht geht wird eine Kopie, oder ein Hardlink im K=E4fig angelegt. Diese Techniken sparen Platz. Wenn ich jetzt im chroot-K=E4fig aber eine andere gcc-Version einsetzen will, und sogar f=FCr eine andere CPU kompilieren m=F6chte, dann funktioniert das nicht mehr. Ich mu=DF alles was zum build-System geh=F6rt im chroot-K=E4fig nocheinmal haben. Passend zum compiler, den verwendeten Libraries, usw. F=FCr den Fall, das ich f=FCr eine andere Architektur (i386 auf athlon-xp) compiliere, mu=DF ich fast das gesamte System im chroot nocheinmal aufsetzen. Der Aufwand ist zimlich hoch. >> Interressant in diesem Zusammenhang: das Buildsystem von NetBSD >> leistet genau so etwas. Es k=F6nnte also lohnend sein, sich damit >> auseinanderzusetzen (Gentoo und FreeBSD unterscheiden leider noch >> nicht bei den i386-Prozessoren. P4 ist genauso wie Athlon ein und >> dieselbe Architektur --- auch wenn ein P4-optimiertes Programm auf >> einem 586 garantiert nicht mehr l=E4uft!). >=20 > H=F6h? Auch das erkl=E4r mal bitte genauer. Was genau wird nicht > unterschieden? Und was macht NetBSD da denn anders? In FreeBSD gibt es f=FCr alle Intel-586-Kompatiblen CPU nur eine Architektur: i686. Wenn ich jetzt f=FCr einen P4 optimiere, dann f=E4llt hinten Programmcode f=FCr i386 optimiert f=FCr P4 heraus. Jetzt starte ich einen zweiten Kompilerlauf, diesmal mit Optimierung f=FCr den Pentium. Da dieser auch i386 als Architekturkennung hat, f=E4llt das was f=FCr Pentium optimiert wurde auf das was ich gerade vorher f=FCr P4 erzeugt hatte. Ergebnis: es ist zur Zeit *nicht* m=F6glich ohne weiteren Aufwand einfach f=FCr mehrere verschiedene Pentium, Pentium MMX, P-II, P-III, P4, Athlon-XP optimal angepassten Code zu erzeugen. Ich mu=DF die Build-Umgebung f=FCr *jeden* dieser Prozessoren komplett neu zusammenschrauben. Dabei ist zimlich viel zu beachten, weil ich sicherstellen mu=DF, das keine Library, die f=FCr P4 gedacht war in ein f=FCr den Pentium gedachtes Binary gelinkt wird. Gentoo hat zur Zeit exakt das Selbe Problem. Auch hier wird kein Unterschied zwischen Pentium, P4 und Athlon-XP gemacht. Es ist alles i586. Ich mu=DF, wenn ich das machen will f=FCr jede CPU einen eigenen Buildbereich mit allem was dazugeh=F6rt zusammenbauen. NetBSD macht zwischen einem Pentium, P4 und Athlon-XP einen Unterschied. Die verschiedenen CPU werden nicht mehr als eine Architektur betrachtet, sondern als verschieden. Es ist dadurch m=F6glich mit nur einem Befehl optimierte Pakete f=FCr jede dieser CPU zu bauen --- das mit immer demselben Kompiler, ohne auf chroot, oder =E4hnliche Kunstgriffe zur=FCckgreifen zu m=FCssen. --=20 Thomas --=20 gentoo-user-de@gentoo.org mailing list