Hallo,
ich wollte heute mir einen neuen Kernel bauen und dabei den Framebuffer-Support wieder rauswerfen. Hintergrund dazu sind Fehlermeldungen die ich bei kleinen OpenGL-Programmen bekomme und ich vermute dass der Framebuffer-Support der Störenfried dabei ist.
Leider stelle ich mich etwas dumm dabei an. Der Compiler bemerkt während des Duchlaufes einige nicht initialisierte Variablen und bricht dann ab. Hier habe ich mal auf meiner Kiste rumgestöbert und bin zu folgenden Ergebnis gekommen:
/usr/bin/gcc linkt auf /usr/bin/gcc.wrapper, dieses ist ein Perlscript und ruft /usr/bin/gcc.real auf, dies ist ein Link auf /usr/bin/gcc-3.3
Sind Probleme hinsichtlich gcc-3.3 und Debian Testing bekannt? Was habe ich zu lesen, oder wo habe ich zu suchen?
Ich dachte immer dass sich nur im C++-Bereich des Compilers Änderungen sich vollzogen haben, bin wohl auf dem Holzweg?
Danke Jan
On 15.06.03 Jan Rakelmann (JanRakelmann@web.de) wrote:
Moin,
Sind Probleme hinsichtlich gcc-3.3 und Debian Testing bekannt? Was habe ich zu lesen, oder wo habe ich zu suchen?
Der offizielle Kernelcompiler ist immer noch gcc 2.95.x. In dcoulm tauchen regelmäßig Luete auf, die es mit gcc-3.3 versuchen und scheitern.
H.
* Hilmar Preusse wrote:
On 15.06.03 Jan Rakelmann (JanRakelmann@web.de) wrote:
Hallo,
Sind Probleme hinsichtlich gcc-3.3 und Debian Testing bekannt? Was habe ich zu lesen, oder wo habe ich zu suchen?
Der offizielle Kernelcompiler ist immer noch gcc 2.95.x. In dcoulm tauchen regelmäßig Luete auf, die es mit gcc-3.3 versuchen und scheitern.
Das dachte ich mir auch, laut http://lists.debian.org/debian-user-german/2003/debian-user-german-200306/ms...
habe ich im Makefile HOSTCC = gcc-2.95 eingetragen, dennoch kommt: md5sum: MD5-Prüfung fehlgeschlagen bei »hfc_pci.c« md5sum: kann hfc_pci. nicht öffnen md5sum: kann hfc_pci nicht öffnen acorn.c:27: Warnung: `adfspart_setgeometry' defined but not used acorn.c:42: Warnung: `adfs_partition' defined but not used acorn.c:67: Warnung: `riscix_partition' defined but not used acorn.c:108: Warnung: `linux_partition' defined but not used ldm.c: In function `ldm_parse_privhead': ldm.c:143: Warnung: integer constant is too large for "long" type ldm.c: In function `ldm_parse_tocblock': ldm.c:201: Warnung: integer constant is too large for "long" type time.c:433: Warnung: `do_gettimeoffset_cyclone' defined but not used dmi_scan.c: In function `dmi_decode': dmi_scan.c:832: Warnung: unused variable `data' {standard input}: Assembler messages: {standard input}:1055: Warning: indirect lcall without `*' {standard input}:1131: Warning: indirect lcall without `*' {standard input}:1210: Warning: indirect lcall without `*' {standard input}:1305: Warning: indirect lcall without `*' {standard input}:1321: Warning: indirect lcall without `*' {standard input}:1331: Warning: indirect lcall without `*' {standard input}:1415: Warning: indirect lcall without `*' {standard input}:1430: Warning: indirect lcall without `*' {standard input}:1441: Warning: indirect lcall without `*' {standard input}:1902: Warning: indirect lcall without `*' {standard input}:1990: Warning: indirect lcall without `*' head.S:116: Warnung: extra tokens at end of #endif directive bootsect.S:237: Warnung: extra tokens at end of #ifdef directive bootsect.S: Assembler messages: bootsect.S:239: Warning: indirect lcall without `*' setup.S: Assembler messages: setup.S:160: Warning: value 0x37ffffff truncated to 0x37ffffff setup.S:230: Warning: indirect lcall without `*' Root device is (33, 3) Boot sector 512 bytes. Setup is 4770 bytes. System is 769 kB sm_osl.c: In function `sm_osl_suspend': sm_osl.c:671: Warnung: unused variable `wakeup_address' tz.c: In function `tz_add_device': tz.c:336: Warnung: unused variable `tmp_handle' tz_osl.c: In function `tz_osl_proc_read_info': tz_osl.c:68: Warnung: unused variable `status' tz_osl.c:70: Warnung: unused variable `buffer' tz_osl.c:76: Warnung: unused variable `t' tz_osl.c: In function `tz_osl_proc_write_info': tz_osl.c:152: Warnung: unused variable `state' tzpolicy.c: In function `tz_policy_add_device': tzpolicy.c:488: Warnung: unused variable `thresholds' tzpolicy.c:489: Warnung: unused variable `j' horizon.c: In function `hrz_check_args': horizon.c:2923: Warnung: comparison is always false due to limited range of data type ambassador.c:301:21: pasting "." and "start" does not give a valid preprocessing token ambassador.c:305:23: pasting "." and "regions" does not give a valid preprocessing token ambassador.c:310:20: pasting "." and "data" does not give a valid preprocessing token make[3]: *** [ambassador.o] Fehler 1 make[2]: *** [_modsubdir_atm] Fehler 2 make[1]: *** [_mod_drivers] Fehler 2 make: *** [stamp-build] Fehler 2 jan@abacus:/usr/src/kernel-source-2.4.21$
Und dann ist Schluß, es liegt ein vmlinuz-Binary im Verzeichnis aber es wird kein Debian-Paket erstellt.
Jan
On 16.06.03 Jan Rakelmann (JanRakelmann@web.de) wrote:
Hallo,
ambassador.c:301:21: pasting "." and "start" does not give a valid preprocessing token ambassador.c:305:23: pasting "." and "regions" does not give a valid preprocessing token ambassador.c:310:20: pasting "." and "data" does not give a valid preprocessing token make[3]: *** [ambassador.o] Fehler 1 make[2]: *** [_modsubdir_atm] Fehler 2 make[1]: *** [_mod_drivers] Fehler 2 make: *** [stamp-build] Fehler 2 jan@abacus:/usr/src/kernel-source-2.4.21$
Gut, dann rück mal die Kernelconfig raus, ob sich das hier reproduzieren läßt. Vielleicht ist es ja wirklich ein Bug...
H.
On 16.06.03 Jan Rakelmann (JanRakelmann@web.de) wrote:
- Hilmar Preusse wrote:
Moin,
Gut, dann rück mal die Kernelconfig raus, ob sich das hier reproduzieren läßt. Vielleicht ist es ja wirklich ein Bug...
Im Anhang, ich hoffe ich nerv' nicht alle.
make modules geht bei mir an der Stelle problemlos durch. Compiler ist definitiv ein 2.95.4. Wenn Du Dir nicht durch irgendwas den Source-Tree versaut hast liegts am Compiler. Ich vermute Letzteres, da die Fehlermeldunegn ja auch google bekannt sind.
gcc -D__KERNEL__ -I/usr/src/linux-2.4.21/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.21/include/linux/modversions.h -g -nostdinc -iwithprefix include -DKBUILD_BASENAME=ambassador -c -o ambassador.o ambassador.c gcc -D__KERNEL__ -I/usr/src/linux-2.4.21/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.21/include/linux/modversions.h -g -nostdinc -iwithprefix include -DKBUILD_BASENAME=atmtcp -c -o atmtcp.o atmtcp.c
drachi:[/usr/src/linux] #time make-kpkg kernel_image
bricht bei mir nach 120 Minuten beim depmod während der Installation ab. Das ist dann ein echter Bug. Na ja, aber die Probleme da oben hab ich nicht.
H.
On 16.06.03 Jan Rakelmann (JanRakelmann@web.de) wrote:
Hallo,
ambassador.c:301:21: pasting "." and "start" does not give a valid preprocessing token ambassador.c:305:23: pasting "." and "regions" does not give a valid preprocessing token ambassador.c:310:20: pasting "." and "data" does not give a valid preprocessing token make[3]: *** [ambassador.o] Fehler 1 make[2]: *** [_modsubdir_atm] Fehler 2 make[1]: *** [_mod_drivers] Fehler 2 make: *** [stamp-build] Fehler 2 jan@abacus:/usr/src/kernel-source-2.4.21$
Im DBTS gibt es #194196 & #195129 zum Thema, die sich aber beide auf gcc-3.3 beziehen. Sicher daß Du gcc-2.95 am Start hast?
H.
* Hilmar Preusse wrote:
Im DBTS gibt es #194196
Hiersag ich einfach mal, was geht mich fremdes Elend an. ;-) Nee, im Ernst wofür gibt es make-kpkg, welches alle Programme in richtiger Reihenfolge aufruft?
& #195129
Naja, und hier genauso.
Es ist unglaublich, das erste mal fall ich hier so richtig auf die Nase, und hätte mich eigentlich um ganz andere Dinge zu kümmern.
Dank dir dennoch, Jan
* Hilmar Preusse wrote:
On 16.06.03 Jan Rakelmann (JanRakelmann@web.de) wrote:
Hallo,
Im DBTS gibt es #194196 & #195129 zum Thema, die sich aber beide auf gcc-3.3 beziehen. Sicher daß Du gcc-2.95 am Start hast?
Ja. Ein ls /usr/bin/gcc* liefert u.a. ein /usr/bin/gcc-2.95. In dselect nachgesehen liefert gcc-2.95.4-17 auf Debian Sarge stand gestern. Also spiele ich das Spiel nochmal, Kernelquellen neu auspacken ergibt ein frischen Kernel-Source für 2.4.21. In das frische Makefile die Variable HOSTCC auf HOSTCC = gcc-2.95 gesetzt. Config eingelesen und los ...
Ergebnis nach 20 Minuten: make[3]: *** [ambassador.o] Fehler 1 make[3]: Leaving directory `/usr/src/kernel-source-2.4.21/drivers/atm' make[2]: *** [_modsubdir_atm] Fehler 2 make[2]: Leaving directory `/usr/src/kernel-source-2.4.21/drivers' make[1]: *** [_mod_drivers] Fehler 2 make[1]: Leaving directory `/usr/src/kernel-source-2.4.21' make: *** [stamp-build] Fehler 2
Eine Möglichkeit sehe ich vielleicht noch, ich werf' einfach mal alle Treiber raus von denen ich _genau_ weis dass ich sie nicht benötige. Vielleicht hat auch make-kpkg eine Macke weg?
Jan
On 17.06.03 Jan Rakelmann (JanRakelmann@web.de) wrote:
- Hilmar Preusse wrote:
Hallo,
Ja. Ein ls /usr/bin/gcc* liefert u.a. ein /usr/bin/gcc-2.95. In dselect nachgesehen liefert gcc-2.95.4-17 auf Debian Sarge stand gestern. Also spiele ich das Spiel nochmal, Kernelquellen neu auspacken ergibt ein frischen Kernel-Source für 2.4.21. In das frische Makefile die Variable HOSTCC auf HOSTCC = gcc-2.95 gesetzt. Config eingelesen und los ...
gcc -v steht auf gcc-3.3? Bieg doch mal den Link /usr/bin/gcc um, um ganz sicher zu sein.
Eine Möglichkeit sehe ich vielleicht noch, ich werf' einfach mal alle Treiber raus von denen ich _genau_ weis dass ich sie nicht benötige.
Das sowieso, falls Du keinen Distributionskernel haben willst.
Vielleicht hat auch make-kpkg eine Macke weg?
Das sollte sich anders äußern.
H.
* Jan Rakelmann wrote:
Eine Möglichkeit sehe ich vielleicht noch, ich werf' einfach mal alle Treiber raus von denen ich _genau_ weis dass ich sie nicht benötige. Vielleicht hat auch make-kpkg eine Macke weg?
Und hier lag auch der Vierbeiner verbuddelt, manche experimentelle Treiber sollte ich besser meiden. Nachdem der Treiber für Asynchronous Transfer Mode, in Networking Options, klar mit experimentell gekennzeichnet, entfernt ist läuft der Kernelbau mit beiden Kompilern durch.
Jan
Hallo!
Am Dienstag, 17. Juni 2003 11:54 schrieb Jan Rakelmann:
Und hier lag auch der Vierbeiner verbuddelt, manche experimentelle Treiber sollte ich besser meiden. Nachdem der Treiber für Asynchronous Transfer Mode, in Networking Options, klar mit experimentell gekennzeichnet, entfernt ist läuft der Kernelbau mit beiden Kompilern durch.
ATM ist etwas problematisch. Es liegt zum Teil in networking, zum Teil bei den Netzwerk-Device-Treibern. Erst wenn beide Teile aktiviert sind, geht das Kompilieren (bei mir übrigens gcc-3.3).
ATM wird benötigt, wenn Du zum Beispiel eine Fritz!DSL einsetzen willst.
Gruss Reiner
Hi!
Am 2003-06-15 23:48 +0200 schrieb Jan Rakelmann:
ich wollte heute mir einen neuen Kernel bauen und dabei den Framebuffer-Support wieder rauswerfen. Hintergrund dazu sind Fehlermeldungen die ich bei kleinen OpenGL-Programmen bekomme und ich vermute dass der Framebuffer-Support der Störenfried dabei ist.
Leider stelle ich mich etwas dumm dabei an. Der Compiler bemerkt während des Duchlaufes einige nicht initialisierte Variablen und bricht dann ab.
Echt? Ich habe mir gestern auch den neuen Kernel gebaut (allerdings mit grsecurity-Patch), lief einwandfrei durch. Kannst Du mal die konkrete Ausgabe und Deine .config schicken?
/usr/bin/gcc linkt auf /usr/bin/gcc.wrapper, dieses ist ein Perlscript und ruft /usr/bin/gcc.real auf, dies ist ein Link auf /usr/bin/gcc-3.3
Meintest Du nicht, Du benutzt Debian testing? Bei mir ist /usr/bin/gcc direkt ein Symlink auf /usr/bin/gcc-3.3, das da oben kommt mir sehr verwurschtelt vor. Allerdings ist gcc-3.3 auch der einzige Compiler, den ich installiert habe.
Sind Probleme hinsichtlich gcc-3.3 und Debian Testing bekannt?
Mir nicht, ich benutze ihn auch sehr oft. Ich bin da allerdings keine Autorität.
Was habe ich zu lesen, oder wo habe ich zu suchen?
Vielleicht mal auf debian-devel oder debian-gcc?
Ich dachte immer dass sich nur im C++-Bereich des Compilers Änderungen sich vollzogen haben, bin wohl auf dem Holzweg?
IIRC hat sich nur das C++-ABI verändert. Ausserdem hast Du den Kernel doch frisch übersetzt, oder? IMHO gibt es nur Probleme mit verschiedenen Kernelversionen, wenn z. B. ein mit gcc-3.3 compiliertes Programm eine mit 2.95 compilierte Bibliothek verwendet; aber der Kernel benutzt ja keine Bibliotheken.
Wenn der Kernel nicht kompiliert, sondern mit einem Fehler abbricht, dann ist das eindeutig ein Kernelbug (ging mir mit 2.4.20 so, der wollte einfach nicht linken, 2.4.21 geht jetzt). Natürlich modulo der Annahme, dass die Toolchain auf aktuellem Stand ist, aber wenn Dein testing aktuell ist, sollte die toolchain okay sein.
Ciao, Pitti
On 15.06.03 Martin Pitt (martin@piware.de) wrote:
Moin,
IIRC hat sich nur das C++-ABI verändert. Ausserdem hast Du den Kernel doch frisch übersetzt, oder? IMHO gibt es nur Probleme mit verschiedenen Kernelversionen, wenn z. B. ein mit gcc-3.3 compiliertes Programm eine mit 2.95 compilierte Bibliothek verwendet; aber der Kernel benutzt ja keine Bibliotheken.
Aber auch das sollte nur auftreten, wenn mit C++ gearbeitet wurde. Der Kernel besteht IIRC nicht aus C++-Code.
H.
* Martin Pitt wrote:
Echt?
Echt! ;-) Er bricht zwar nicht unmittelbar danach ab, aber ich denk' es gehört damit zusammen.
Ich habe mir gestern auch den neuen Kernel gebaut (allerdings mit grsecurity-Patch), lief einwandfrei durch. Kannst Du mal die konkrete Ausgabe und Deine .config schicken?
Bis jetz wollte ich immer von der alten /boot/config-2.4.18 aktualisieren. Das dann durch make dep, welches letztendlich von make-kpkg aufgrufen wird, geprüft wird ist mir auch klar.
/usr/bin/gcc linkt auf /usr/bin/gcc.wrapper, dieses ist ein Perlscript und ruft /usr/bin/gcc.real auf, dies ist ein Link auf /usr/bin/gcc-3.3
Meintest Du nicht, Du benutzt Debian testing?
Ja, heute von ftp2.de.debian.org abgeglichen.
Bei mir ist /usr/bin/gcc direkt ein Symlink auf /usr/bin/gcc-3.3, das da oben kommt mir sehr verwurschtelt vor. Allerdings ist gcc-3.3 auch der einzige Compiler, den ich installiert habe.
Du meinst also ich sollte mal Ordnung auf meiner Kiste schaffen? Mehrere Compiler benötige ich nicht, kann die "alten" also löschen.
Was habe ich zu lesen, oder wo habe ich zu suchen?
Vielleicht mal auf debian-devel oder debian-gcc?
Ist eine Idee, ich werde morgen mal suchen.
Ich dachte immer dass sich nur im C++-Bereich des Compilers Änderungen sich vollzogen haben, bin wohl auf dem Holzweg?
IIRC hat sich nur das C++-ABI verändert. Ausserdem hast Du den Kernel doch frisch übersetzt, oder? IMHO gibt es nur Probleme mit verschiedenen Kernelversionen, wenn z. B. ein mit gcc-3.3 compiliertes Programm eine mit 2.95 compilierte Bibliothek verwendet; aber der Kernel benutzt ja keine Bibliotheken.
So habe ich auch immer gedacht.
Wenn der Kernel nicht kompiliert, sondern mit einem Fehler abbricht, dann ist das eindeutig ein Kernelbug
Ich versuche morgen noch mal mein Glück, und erstelle dann auch eine Logdatei. Naja was einen Kernelbug betrifft, ich glaube da kann ich mich auf die kompetenten Entwickler durchaus schon verlassen.
(ging mir mit 2.4.20 so, der wollte einfach nicht linken, 2.4.21 geht jetzt). Natürlich modulo der Annahme, dass die Toolchain auf aktuellem Stand ist, aber wenn Dein testing aktuell ist, sollte die toolchain okay sein.
Wie gesagt, Stand ist heute.
Jan
Hallo Jan!
Am 2003-06-16 1:06 +0200 schrieb Jan Rakelmann:
Ich habe mir gestern auch den neuen Kernel gebaut (allerdings mit grsecurity-Patch), lief einwandfrei durch. Kannst Du mal die konkrete Ausgabe und Deine .config schicken?
Bis jetz wollte ich immer von der alten /boot/config-2.4.18 aktualisieren. Das dann durch make dep, welches letztendlich von make-kpkg aufgrufen wird, geprüft wird ist mir auch klar.
??? Ich meinte eigentlich, dass Du mal die konkrete Fehlermeldung mailst, vielleicht lässt sich daraus die Fehlerursache finden. Und mit Deiner .config kann man dann auch mal rumspielen.
Du meinst also ich sollte mal Ordnung auf meiner Kiste schaffen? Mehrere Compiler benötige ich nicht, kann die "alten" also löschen.
Wenn Du nicht gerade Softwarepakete für verschiedene Distributionen erstellst, brauchst Du die sicher nicht. Ich habe mich nur gewundert, dass da so viele Indirektionen bei Dir sind... Aber wenn 'gcc -v' meint, dass er 3.3 wäre, ist es sicherlich okay.
Wenn der Kernel nicht kompiliert, sondern mit einem Fehler abbricht, dann ist das eindeutig ein Kernelbug
Ich versuche morgen noch mal mein Glück, und erstelle dann auch eine Logdatei. Naja was einen Kernelbug betrifft, ich glaube da kann ich mich auf die kompetenten Entwickler durchaus schon verlassen.
Naja, aber alle möglichen Kombinationen von Treibern haben die bestimmt auch nicht testen können. Wie gesagt: 2.4.20 wurde bei mir nicht gelinkt, es kam ein "unresolved symbol", und die gewünschte Funktion war nirgendwo in den Kernelsourcen definiert. Das passiert schon mal, sogar Linux-Kernelprogrammierer machen Fehler (man glaubt es kaum) ;-) Trotzdem leisten sie natürlich großartige Arbeit.
Gute Nacht und viel Erfolg!
Martin
lug-dd@mailman.schlittermann.de
-
Hilmar Preusse -
Jan Rakelmann -
Martin Pitt -
Reiner Klaproth