Fragen? Antworten! Siehe auch: Alternativlos
glibc installiert seine Header in /usr/include, und hat verschiedene Header für x86 und x86_64. Man kann aber gcc mit -m32 aufrufen, und dann kompiliert er für x86. Leider benutzt er dann immer noch /usr/include. In den meisten Fällen ist das OK, aber manchmal eben nicht, wie z.B. beim Java-Runtime von gcc. Nun hat gcc einen Override-Mechanismus für sowas. Z.B. included er vor /usr/include noch seinen Override-Pfad /usr/lib64/gcc/x86_64-unknown-linux-gnu/4.1.1/include (bei mir). Nun, leider ist auch dieser Pfad der selbe bei -m32.
gcc hat einen Mechanismus, um sowas zu fixen. Man kann ein specs-File erzeugen. Früher hat gcc das mitgeliefert, heute ist das built-in. Man kann das trotzdem noch extrahieren (ruft mal "gcc -dumpspecs" auf, um euch den Horror mal zu geben) und irgendwo geschickt platzieren, aber … wir haben 2007. Liebe gcc-Leute, das ist unter aller Sau. Fixt das mal. Und wenn die glibc-Deppen nicht pro Plattform andere Includes hätten, wäre das auch alles kein Problem. Das liegt im Übrigen u.a. daran, daß glibc die Kernel-Header included. Ich habe das am Anfang auch gemacht bei der dietlibc. Linus himself hat mir dann eine Mail geschrieben, daß ich das nicht machen soll, weil das nur Probleme macht, und hey, rückblickend hatte der Mann sowas von Recht… tja, nur bis zur glibc hat sich das noch nicht rumgesprochen.
Wenn ihr eine 64-bit Distribution fahrt, dann guckt euch mal an, wie die das regelt. Gentoo hat da echt einmal den Hazmat-Anzug angezogen und ein Konstrukt namens "multilib" gebaut. Auf meinem Gentoo-Testsystem sieht z.B. /usr/include/wchar.h so aus:
/* Autogenerated by create_ml_includes() in multilib.eclass */Na, ist das nicht wi-der-lich? Danke, liebe glibc, daß ihr Linux so effektiv kaputt gemacht habt. Nicht einmal offene Eiterwunden wie X oder Samba sind je so tief gesunken.#ifdef __i386__
# include
#endif /* __i386__ */#ifdef __x86_64__
# include
#endif /* __x86_64__ */
Oh, noch nen Nachschlag für die Variante mit dem "specs"-File: wenn ich das anfasse, und da z.B. folgendes bei cpp_options reineditiere:
{m32:-isystem /usr/include32}dann hängt mir das natürlich auch beim dietlibc-für-x86-Kompilieren /usr/include32 in den Pfad und macht alles kaputt. Ihr seht schon, wieso Gentoo diese Würg-Lösung gewählt hat.