Hallo Ralf, On Son, 11 Feb 2001, Ralf Corsepius wrote:
David Haller wrote: [.. ack soweit..]
* CFLAGS aus Environmentvariablen heraus zu exportieren (export CFLAGS=..) und auf der Command-Line zu verwenden (gcc $CFLAGS) ist eine reichlich fragwürdige Geschichte und sollte man sich besser nicht angewöhnen.
Wieso? Es ist extrem fehlerträchtig, da Du die Kontrolle darüber verlierst und es nicht unwahrscheinlich ist, dass Du Dich in einem halben Jahr nur noch diffus daran erinnern wirst,
Woran? an die gesetzen CFLAGS? echo $CFLAGS...
wenn Du nach einem Systemwechsel oder nach einem Login auf einer Sparc/Alpha/Mips/m68k/ix86 plötzlich mit merkwürdigen Übersetzungsproblemen zu kämpfen hast.
1. habe ich ein Einzelplatzsystem... Und das haben wohl die meisten hier, die dieses Problem nicht (sofort) erkennen wuerden ;)) 2. ist auf der sparc/sunos auf der ich mich machmal einlogge kein CFLAGS in der ~/.bashrc (procmail und wget liessen sich problemlos uebersetzen).
Der Grund ist, ich habe halt keine Lust immer:
"-Wall -O2 -march=i686 -mcpu=athlon -fno-strict-aliasing -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -mwide-multiply" Auch über den Sinn dieser Flags kann man streiten. .. werde ich jetzt aber nicht :)
Das sind (ausser dem fehlenden -fomit-frame-pointers und dem zusaetzlichen, da ich den athlon-patch des pgcc verwende, -mcpu=athlon) genau die, die von den 2.4.x Kernels bei Auswahl von "Athlon/K7" in der Kernel- config gesetzt werden... Und solche, Plattform/CPU-spezifischen Flags sind IMHO doch recht gut in der _Maschinen_-spezifisch gesetzen Variable CFLAGS aufgehoben... Weshalb sonst wuerden soviele Programme mit halbwegs ordentlichen Makefiles diese Umgebungsvariable beachten? Und ggfs. kann sie ja einfach vom Makefile ignoriert werden... Fuer mich ist $CFLAGS genau fuer diesen Zweck gedacht und ideal geeignet. Und ich selbst habe schon Makefiles geschrieben, die die eventuell gesetzte Umgebungsvariable CFLAGS hernehmen, eine kritische oder andere Option (z.B. -fomit-frame-pointers beim kompilieren im debug- Modus mit -g) herausnehmen (mit sed/bash, je nach gewuenschter Plattform/Portabilitaet) aber ansonsten die prozessorspezifischen Flags beachten / drinlassen...
einzugeben ;). Das -O2 usw. schrieb ich dahinter, damit mindestens diese Optionen gesetzt werden, falls jemand keine CFLAGS exportiert hat. Und genau das ist das Hauptproblem: Manchmal werden gewisse CFLAGS bewusst nicht gesetzt. In der Regel wissen die Entwickler eines Paketes besser als der "Casual Installer" warum sie gewisse Flags setzen und warum nicht. So wissen auch die gcc-Entwickler ziemlich genau warum sie gewisse Flags als Default setzen und welche nicht.
Generell, im Prinzip Ack, nur eben bei den Prozessorspezifischen nicht. Es macht einen deutlichen Unterschied, ob ich eine App mit den Default-flags (fuer i386) oder mit o.g. Athlon oder auch nur mit den 'Pentium >= 2'-Flags durch den Kompiler jage. Und diese Flags kann und IMHO sollte ein Entwickler nicht vorgeben. Konflikte lassen sich durch das erwaehnte Uebernehmen + sed usw. oder ein passendes ./configure umgehen. Zudem war der Quelltext um den es ging ein in 5min hingeschluderter, als Anregung gedachter Mehrzeiler (den ich dann in noch ein paar Minute hoffentlich brauchbar gemacht habe ;), fuer den vieles, was du richtigerweise _fuer den generellen Fall_ schreibst, einfach nur totaler Overkill waere... Eigentlich war auch schon die von dir aufgegriffene Zeile Overkill, ein einfaches 'gcc -o foo foo.c' haette auch gelangt...
Ein weiteres Problem sind Konflikte zwischen deinen exportierten Shell-Variablen und Makefile/configure-Script Shell- bzw. Make-Variablen, z.B.: [..]
s.o. Generell ACK, bis auf den "plattform-spezifische Flags"-Fall... (und LDFLAGS habe ich z.B. keine gesetzt)
Ausserdem erleichtert das (mir) das kompilieren generell sehr, es reicht ein ./configure ... statt einem CFLAGS="[s.o]" ./configure ... Ja, beides ist nahezu gleichbedeutend und hat entsprechend auch die gleichen generellen Probleme. Nur, im letzteren Fall gibst Du sie in jedem Einzelfall explizit an und läufst weniger Gefahr in oben erwähnte Probleme zu geraten.
Ack. Beziehe meine Situation (s.o.) ein und du wuerdest sicher auch ein CFLAGS mit _plattformspezifischen_ Flags exportieren ;) Besonders wenn du oefter mal ein Paket kompilierst, das keinerlei optimierende Flags setzt (was ich uebrigens gut finde) aber dennoch eine evtl. gesetze Variable CFLAGS beachtet. Ggfs. setze ich natuerlich ein CFLAGS="" vor den ./configure oder make Aufruf, was wesentlich leichter zu merken ist, als die oben zitierte von mir exportierte Variable ;)
Im Übrigen spielt dies auf einem Einzelplatzsystem so gut wie keine Rolle,
Eben! (scnr)
in einem (heterogenen) Netz wird es allerdings relevant.
ACK. Bis auf die _plattformspezifischen_ Flags! (scnr2)
Derartige Dinge sind oft die Ursache für "Bei mir daheim tuts, am Arbeitsplatz, an der Uni, beim Kunden, bei meinen Kumpel plötzlich nicht mehr" Fälle :).
Ouh. Damit habe ich (zum Glueck?) noch keine Erfahrungen (ausser bei WinDoSxx (siehe Zufallssig *bg*))... Wie gesagt, IMHO setzt derjenige $CFLAGS, der weiss, dass dies evtl. Konflikte verursachen kann... Mag sein, dass ich damit naiv bin... Aber wenn ich nur mal anschaue, was mir beim kompilieren der glibc, der bash, der stdlibc++, ganz zu schweigen von KDE oder GNOME (such dir weitere "Standards" ausser dem Kernel aus) mit einem einfachen -Wall und ggfs. einem Hack des/der Makefiles um eben _nicht_ alle Fehlermeldungen des gcc nach /dev/null umzuleiten, alles an Kompiler-"Warning"s um die Ohren gebretzelt wird, dann kommt mir die von dir angesprochene Problematik wahrlich trivial, oder besser, "ignorierbar" vor... *sad grin* Ein "Compiler-Warnings-Abstell-und-ein-ganz-klein-wenig-aus-anderen-patches- uebernommenes"-patch[1] der bash 2.04 von mir hat schlappe 2421 Zeilen, zugegebenerweise als 'diff -u'... [1] IIRC 2 Stellen aus dem security-patch, den Rest des sec-patches muss ich noch durchgehen. CU David, der dir aber nach wie vor _generell_ Recht gibt! :) P.S: fup2me/suse-talk da OT? PPS: Lather, Rinse... Repeat....... Flush! PPPS: Danke! --
The three "R"s of Microsoft support: Retry, Reboot, Reinstall You forgot one: Repeat -- Mark Atwood, Lars Balker Rasmussen