wie feststellen, mit welcher gcc Version etwas kompiliert wurde?

[holgerw]

Hi,

gibt es eigentlich eine Möglichkeit, herauszufinden, mit welcher Kompilerversion ein Kernel, ein Kernelmodul, eine Anwendung kompiliert worden ist? Z.B. habe ich eine Debian XFS_Netinstall CD mit nem 2.4.20er Kernel und ich wüsste gerne, ob der mit dem gcc2.95 oder schon mit einer 3er Version kompiliert worden ist.

Danke für Infos dazu.

Grüße,
Holger

[mario88]

Also beim Kernel findest du es mittels
cat /proc/version raus.

[holgerw]

Hi mario88,

danke für diew Antwort. Aber mir geht es eher um Programme, Module oder Kernelimages, die ich noch nicht installiert habe. So z. B. den Kernel2.4.20_XFS auf der Debian Netinstall CD.

Grüße,
Holger

[mario88]

Oh, ich glaube ich bin schon müde :ugly:
Ich hab deinen Post ein bisschen falsch verstanden.

Wie das bei Anwendungen, Kernel-Modulen usw. geht, weiß ich leider nicht, würde mich aber auch interessieren.

[holgerw]

Hi Mario,

zum Hintergrund meiner Frage:
für mein Vorhaben, mich nochmal an einen XFS System mit alsa zu wagen, wäre es hilfreich, vorher zu wissen, ob Denian 2.4.20_xfs Kernel auf der Netinstall CD mit gcc2.95 oder 3.x erstellt worden ist.

Na ja, wenn das Basissystem insdtalliert ist, lässt sich das ja mit cat /proc/version herausfinden.

Vielleicht maile ich mal dem Debian XFS Kernelbetreuer Eduardo Bloch, der muss das wissen.

Davon abgesehen interessiert es mich weiterhin, ob das bei sonstigen Anwendungen auch heraus zu finden ist

Grüße,
Holger

[xare]

Original geschrieben von holgerw

Davon abgesehen interessiert es mich weiterhin, ob das bei sonstigen Anwendungen auch heraus zu finden ist

Grüße,
Holger

meine Methode:



xare@linux:/opt/kde3/bin> tail -5 konqueror
ELF4 4 /lib/ld-linux.so.2GNU ñÿ ÞñÿÒÅÔ ×ñÿ#ñÿêñÿ9 M konqueror.so_DYNAMIC_init_fini_GLOBAL_OFFSET_TABLE __Jv_RegisterClasses__gmon_start__libkonq.so.4libk parts.so.2libkio.so.4libkdeui.so.4libkdesu.so.4lib kdecore.so.4libDCOP.so.4libdl.so.2libresolv.so.2li bart_lgpl_2.so.2libkdefx.so.4libqt-mt.so.3libpng.so.3libXext.so.6libX11.so.6libSM.so. 6libICE.so.6libpthread.so.0libXrender.so.1libutil. so.1libz.so.1libfam.so.0libstdc++.so.5libgcc_s.so. 1libm.so.6libc.so.6_IO_stdin_used__libc_start_main _edata__bss_start_end/opt/kde3/libGLIBý\2.0¬ii UåèmèÔèÉÃÿ5ÿ%ÿ%héàÿÿÿÿ%éÐÿÿÿ1í^áäðPTRhhQVhèÃÿÿÿôUå Sè[Ã+RÀtÿÐX[ÉÃUå=u-Òt¶ÀÿÒÒuëÆÉÃöUå¡Àt!?Àt?ì hè[zû÷Ä?&ÉÃUåVS1ÛèÐþÿÿÁø9ÃsÆC9órô[^]ÃUåÁøSìXÿÀX[]éMØKÀuòX[]é7UåSR¡øÿ»t?¶¿ëÿÐøÿuôX[]ÃUåSè[ÃßPèÊþÿÿY[ÉÃ\ix °?È×êø+6BRboy¢¬ï p þÿÿoÿÿÿoðÿÿoÿÿÿÿÿÿÿGCC: (GNU) 3.3 20030226 (prerelease) (SuSE Linux)GCC: (GNU) 3.3 20030226 (prerelease) (SuSE Linux)GCC: (GNU) 3.3 20030226 (prerelease) (SuSE Linux)GCC: (GNU) 3.3 20030226 (prerelease) (SuSE Linux)GCC: (GNU) 3.3 20030226 (prerelease) (SuSE Linux)GCC: (GNU) 3.3 20030226 (prerelease) (SuSE Linux)GCC: (GNU) 3.3 20030226 (prerelease) (SuSE Linux).shstrtab.interp.note.ABI-tag.hash.dynsym.dynstr.gnu.version.gnu.version_r.r el.dyn.rel.plt.init.text.fini.rodata.data.eh_frame .dynamic.ctors.dtors.jcr.got.bss.comment !(H' pÐ/@7ÿÿÿoH?Dþÿÿod S \ `?0kðpq`?w| ?«?µeÅ?
xare@linux:/opt/kde3/bin>

Sorry für den vielen Schrott, aber so gehts. ;)

MfG Xare

[schnebeck]

Auch für Kernel-Image-Dateien? ;-)

[holgerw]

Hi xare,

danke, aber bei mir kommt da keine gescheite Angabe raus.

Grüße,
Holger

[geronet]

Mit "ldd" vielleicht?
Sorry hab grad keine man-page dazu da, hab aber in Errinnerung dass man da irgendwas auslesen kann.

[keiner_1]

Original geschrieben von geronet
Mit "ldd" vielleicht?


nein mit ldd bestimmt nicht, das zeigt die Shard Lib Abhängigkeiten...

hier ein Beispiel:

# ldd /bin/bash
libtermcap.so.2 => /lib/libtermcap.so.2 (0x00d49000)
libdl.so.2 => /lib/libdl.so.2 (0x00b1b000)
libc.so.6 => /lib/tls/libc.so.6 (0x009bd000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x009a5000)


greez
adme

[schnebeck]

Ein Kernelimage ist quasi eine statische Datei, ldd zeigt die dynamischen Abhängigkeiten normaler ausführbarer Dateien an.

Bye

Thorsten

[holgerw]

Hallo,

danke für die rege Beteiligung an meiner Frage :)

Etwas schlauer bin ich nun geworden. Man kann zum Beispiel od (octal dump) auf die Anwendung loslassen und dann mit grep nach "E L F" suchen, also:
alpha:/home/holger# od -t cx1 /usr/bin/kmail|grep 'E L F'
0000000 177 E L F 001 001 001 \0 \0 \0 \0 \0 \0 \0 \0 \0

oder:
alpha:/home/holger# od -t cx1 /usr/bin/kmail|grep '2 . 9 5'
alpha:/home/holger#

Sollten allerdings die kompilierten Anwendungen - um sie möglichst klein zu halten - gestripped sein, fehlen Angaben, wie etwa der Stempel des entsprechenden Kompilers. Und ich vermute, bei Debian Paketen ist das standardmäßig so, daher bei der Suche nach 2.95 keine Ausgabe.

P.S.: Gebe ja zu, das nicht selbst heraus gefunden zu haben. Ein Freund ist gestern bei uns vorbeigekommen, der ist Unix Admin. :D

Dennoch: Octal dump ist ein interessantes Tool.

Grüße,
Holger

[schnebeck]

Nur ist das Kernel-Image gezippt (bz2) und nicht mal eben so zu "unzippen" und vermutlich auch keine ELF-Datei.

file /boot/bzImage
/boot/bzImage: x86 boot sector

Für normale ELF-Dateien (sozusagen Linux-EXE) funktioniert die Methode von xare auch für gestrippte Dateien.

file /usr/kde/3.1/bin/kmail
/usr/kde/3.1/bin/kmail: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), stripped

tail -5 /usr/kde/3.1/bin/kmail
[...]
GCC: (GNU) 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice)GCC: (GNU) 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice)
[...]

Bye

Thorsten