Da er alle Ergebnisse im Speicher hält und nicht mehr berechnen muss...
Wenn man sich aber mal die ganzen Dependencies mit ldd `which gcalctool` ansieht, die so ein Taschenrechner braucht, wird eigentlich schnell klar, warum soviel Speicherplatz verbraucht wird, obwohl ich eigentlich annehmen würde, dass eine Library nur einmal im Speicher rumliegt und von allen Programmen benutzt werden kann.
Wenn man sich aber mal die ganzen Dependencies mit ldd `which gcalctool` ansieht, die so ein Taschenrechner braucht, wird eigentlich schnell klar, warum soviel Speicherplatz verbraucht wird, obwohl ich eigentlich annehmen würde, dass eine Library nur einmal im Speicher rumliegt und von allen Programmen benutzt werden kann.
Mein lieber Herr Gesangsverein... Wozu um alles in der Welt braucht ein Taschenrechner Sound-Libraries, Crypto-Bibliotheken, Resolving-Bibliotheken und sogar eine Library, die sich um die Xinerama-Darstellung kümmert??
Klar, xcalc ist nicht so mächtig wie gcalc, aber ein ldd `which xcalc` zeigt da schon einen gewissen Unterschied.
Hm, warum du die Audiosachen drin hast, weiß ich auch nicht (bei mir ist's nicht dabei), aber der Rest ist schnell erklärt:
eine .so kann natürlich selbst wieder von einer .so abhängen, und wenn die libgtk+ zB xinerama können soll (was ja nichts dummes ist), muss sie halt gegen die libxinerama linken, und damit jedes gtk programm automatisch auch. Wie der Poster vorne aber schon gesagt hat, natürlich werden die bibs nur einmal in den Speicher geladen und dann brüderlich geteilt.
Wenn man sich aber mal die ganzen Dependencies mit ldd `which gcalctool` ansieht, die so ein Taschenrechner braucht, wird eigentlich schnell klar, warum soviel Speicherplatz verbraucht wird, obwohl ich eigentlich annehmen würde, dass eine Library nur einmal im Speicher rumliegt und von allen Programmen benutzt werden kann.
Da fallen mir doch glatt die Augen aus dem Kopf:
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00c9d000)
libesd.so.0 => /usr/lib/libesd.so.0 (0x0073e000)
libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x00a7c000)
libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0x00b93000)
libssl.so.4 => /lib/libssl.so.4 (0x0081d000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x04557000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x007b1000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00101000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x006f5000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x007fa000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00c03000)
libasound.so.2 => /lib/libasound.so.2 (0x00261000)
Mein lieber Herr Gesangsverein... Wozu um alles in der Welt braucht ein
Taschenrechner Sound-Libraries, Crypto-Bibliotheken, Resolving-Bibliotheken und sogar
eine Library, die sich um die Xinerama-Darstellung kümmert??
Klar, xcalc ist nicht so mächtig wie gcalc, aber ein ldd `which xcalc` zeigt da schon
einen gewissen Unterschied.
eine .so kann natürlich selbst wieder von einer .so abhängen, und wenn die libgtk+ zB xinerama können soll (was ja nichts dummes ist), muss sie halt gegen die libxinerama linken, und damit jedes gtk programm automatisch auch. Wie der Poster vorne aber schon gesagt hat, natürlich werden die bibs nur einmal in den Speicher geladen und dann brüderlich geteilt.