Liebe Pascaller,
ich hab' ein kleines CGI in PASCAL geschrieben und der gpc hat's mir übersetzt:
# P -static Weisel_Zucht.pas /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libgpc.a(rts.o): In function `_p_CGetPwEnt': /usr/src/tarfiles/DL/gcc/gcc-3.3.4/gcc/p/rts/rts.c:2563: warning: Using 'getpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
von diesen Warnungen gibt's noch mehr ...
local läuft das Programm und macht was es soll ... hier läuft: 2.6.23.14-e3 #1 PREEMPT vom Februar # ldd $(which WZ) linux-gate.so.1 => (0xffffe000) libm.so.6 => /lib/libm.so.6 (0xb7eae000) libc.so.6 => /lib/libc.so.6 (0xb7d66000) /lib/ld-linux.so.2 (0xb7ef5000)
auf dem http-Sever läuft: 2.4.22-e17 #3 SMP von vor fünf Jahren ... da sagt mir der Rechner: # WZ FATAL: kernel too old Speicherzugriffsfehler
es gibt: /lib/libm.so.6 /lib/libc.so.6 /lib/ld-linux.so.2
linux-gate ist wohl ein dummy, ihn gibt es weder lokal noch remote ...
Wie bekomme ich das Programm doch noch auf dem anderen System zum Laufen (ohne das ferne System zu erneuern)?
Jeder Hinweis ist mir sehr willkommen!
Grüße Egbert
Egbert Seibertz schrieb:
ich hab' ein kleines CGI in PASCAL geschrieben und der gpc hat's mir übersetzt:
# P -static Weisel_Zucht.pas /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libgpc.a(rts.o): In function `_p_CGetPwEnt': /usr/src/tarfiles/DL/gcc/gcc-3.3.4/gcc/p/rts/rts.c:2563: warning: Using 'getpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
von diesen Warnungen gibt's noch mehr ...
Bei halbwegs modernen glibc-Versionen ist das leider normal. Bestimmte Funktionen kann sie nicht statisch linken. Das ist aber kein Problem, so lange man sie nicht benutzt. Das GPC-Laufzeitsystem referenziert sie zwar, aber wenn sie nicht aufgerufen werden, stört es nicht. So weit ich weiß, betrifft das i.w. Funktionen zur Benutzer- und Netzwerkinformation (z.B. eben "getpwent" (s.o.) oder DNS).
local läuft das Programm und macht was es soll ... hier läuft: 2.6.23.14-e3 #1 PREEMPT vom Februar # ldd $(which WZ) linux-gate.so.1 => (0xffffe000) libm.so.6 => /lib/libm.so.6 (0xb7eae000) libc.so.6 => /lib/libc.so.6 (0xb7d66000) /lib/ld-linux.so.2 (0xb7ef5000)
auf dem http-Sever läuft: 2.4.22-e17 #3 SMP von vor fünf Jahren ... da sagt mir der Rechner: # WZ FATAL: kernel too old Speicherzugriffsfehler
Ah, den kannte ich noch nicht. Anscheinend sind neue glibc-Versionen nur noch begrenzt abwärtskompatibel zu älteren Kerneln. Ich fürchte, das gibt es nur zwei Lösungen:
- Neuerer Kernel auf dem Zielsystem (willst du ja anscheinend nicht; ich weiß nicht, ob ein neuerer 2.4 gehen würde, müsste man recherchieren, das wäre vielleicht noch recht schmerzlos; ein Upgrade von 2.4 auf 2.6 würde ich auf einem aktiven Server auch nicht einfach so probieren).
- Programm mit älterer glibc (oder sogar libc5) bauen. Du kannst die neben die aktuelle installieren und z.B. mit entsprechenden Pfad-Optionen (-L für die Bibliothek und -I für die C-Header) dafür sorgen, dass der Compiler die alte findet. Dann erst mal das GPC-RTS und dann dein Programm compilieren. Klingt auch etwas lästig.
Vielleicht ist es sogar am einfachsten, GPC (inkl. RTS) auf dem Zielrechner zu bauen und dort dein Programm zu compilieren. (Du musst ihn nicht systemweit installieren, wenn das ein Problem ist, du kannst ihn in irgendeinem Verzeichnis bauen, wenn du "--prefix" beim "configure" angibst. Du brauchst allerdings ein paar 100 MB Plattenplatz dafür.)
Frank
Frank Heckenbach (02.Jul 2008 (17:52 (+0200))):
Egbert Seibertz schrieb:
ich hab' ein kleines CGI in PASCAL geschrieben und der gpc hat's mir übersetzt:
# P -static Weisel_Zucht.pas /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libgpc.a(rts.o): In function `_p_CGetPwEnt': /usr/src/tarfiles/DL/gcc/gcc-3.3.4/gcc/p/rts/rts.c:2563: warning: Using 'getpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
von diesen Warnungen gibt's noch mehr ...
Bei halbwegs modernen glibc-Versionen ist das leider normal. Bestimmte Funktionen kann sie nicht statisch linken. Das ist aber kein Problem, so lange man sie nicht benutzt. Das GPC-Laufzeitsystem referenziert sie zwar, aber wenn sie nicht aufgerufen werden, stört es nicht. So weit ich weiß, betrifft das i.w. Funktionen zur Benutzer- und Netzwerkinformation (z.B. eben "getpwent" (s.o.) oder DNS).
aha, braucht es definitiv nicht ...
local läuft das Programm und macht was es soll ... hier läuft: 2.6.23.14-e3 #1 PREEMPT vom Februar # ldd $(which WZ) linux-gate.so.1 => (0xffffe000) libm.so.6 => /lib/libm.so.6 (0xb7eae000) libc.so.6 => /lib/libc.so.6 (0xb7d66000) /lib/ld-linux.so.2 (0xb7ef5000)
auf dem http-Sever läuft: 2.4.22-e17 #3 SMP von vor fünf Jahren ... da sagt mir der Rechner: # WZ FATAL: kernel too old Speicherzugriffsfehler
Ah, den kannte ich noch nicht. Anscheinend sind neue glibc-Versionen nur noch begrenzt abwärtskompatibel zu älteren Kerneln. Ich fürchte, das gibt es nur zwei Lösungen:
- Neuerer Kernel auf dem Zielsystem (willst du ja anscheinend nicht; ich weiß nicht, ob ein neuerer 2.4 gehen würde, müsste man recherchieren, das wäre vielleicht noch recht schmerzlos; ein Upgrade von 2.4 auf 2.6 würde ich auf einem aktiven Server auch nicht einfach so probieren).
bloß nicht, der Ärger ist vorprogrammiert ...
- Programm mit älterer glibc (oder sogar libc5) bauen. Du kannst die neben die aktuelle installieren und z.B. mit entsprechenden Pfad-Optionen (-L für die Bibliothek und -I für die C-Header) dafür sorgen, dass der Compiler die alte findet. Dann erst mal das GPC-RTS und dann dein Programm compilieren. Klingt auch etwas lästig.
diese Version werde ich später 'mal austesten ...
Vielleicht ist es sogar am einfachsten, GPC (inkl. RTS) auf dem Zielrechner zu bauen und dort dein Programm zu compilieren. (Du musst ihn nicht systemweit installieren, wenn das ein Problem ist, du kannst ihn in irgendeinem Verzeichnis bauen, wenn du "--prefix" beim "configure" angibst. Du brauchst allerdings ein paar 100 MB Plattenplatz dafür.)
diese Variante ist letztlich diejenige die gewählt habe, das war einfachste, auch wenn ich so glücklich darüber bin ... Deinen vorhergehenden Vorschlag werde ich wohl in Zukunft gehen, da auf dem Server eigentlich keine Compiler herumgammgeln sollen ...
Jedenfalls: Herzlichen Dank für Deine Vorschläge!
Frank
Grüße Egbert
-- Frank Heckenbach, f.heckenbach@fh-soft.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8
Egbert Seibertz schrieb:
Vielleicht ist es sogar am einfachsten, GPC (inkl. RTS) auf dem Zielrechner zu bauen und dort dein Programm zu compilieren. (Du musst ihn nicht systemweit installieren, wenn das ein Problem ist, du kannst ihn in irgendeinem Verzeichnis bauen, wenn du "--prefix" beim "configure" angibst. Du brauchst allerdings ein paar 100 MB Plattenplatz dafür.)
diese Variante ist letztlich diejenige die gewählt habe, das war einfachste, auch wenn ich so glücklich darüber bin ... Deinen vorhergehenden Vorschlag werde ich wohl in Zukunft gehen, da auf dem Server eigentlich keine Compiler herumgammgeln sollen ...
Tja. :-/ Zur Not kann man ja den (installierten) Compiler einpacken und auslagern und nur bei Bedarf wieder auf dem Server auspacken.
Frank
Frank Heckenbach (03.Jul 2008 (18:11 (+0200))):
Egbert Seibertz schrieb:
Vielleicht ist es sogar am einfachsten, GPC (inkl. RTS) auf dem Zielrechner zu bauen und dort dein Programm zu compilieren. (Du musst ihn nicht systemweit installieren, wenn das ein Problem ist, du kannst ihn in irgendeinem Verzeichnis bauen, wenn du "--prefix" beim "configure" angibst. Du brauchst allerdings ein paar 100 MB Plattenplatz dafür.)
diese Variante ist letztlich diejenige die gewählt habe, das war einfachste, auch wenn ich so glücklich darüber bin ... Deinen vorhergehenden Vorschlag werde ich wohl in Zukunft gehen, da auf dem Server eigentlich keine Compiler herumgammgeln sollen ...
Tja. :-/ Zur Not kann man ja den (installierten) Compiler einpacken und auslagern und nur bei Bedarf wieder auf dem Server auspacken.
ja, so läuft's jetzt auch ...
Frank
Grüße Egbert
-
Egbert Seibertz -
Frank Heckenbach