Kylix-Programme auf verschiedenen Linuxen zum Laufen kriegen

10/12/2013 - 15:01 von Matthias Hanft | Report spam
Hallo,

ich verwende heute noch einen Kylix-Compiler, damit ich den gleichen
Sourcecode auf Windows (mit Delphi) und auf Linux (mit Kylix) compi-
lieren kann. Das funktioniert im allgemeinen auch noch bis heute ganz
hervorragend - nur einige Linuxe sperren sich irgendwie bei der Aus-
führung und machen einen Segmentation Fault...

Also: Laufen tuts z.B. ohne Änderung auf aktuellem Suse, Gentoo, CentOS
(32bit) und etlichen anderen. Die Libs sind also auch heute noch kompa-
tibel - verwendet werden libc.so.6, libdl.so.2, ld-linux.so.2, libz.so.1
und libpthread.so.0.

Auf einigen Linuxen muß man "patchelf" von http://crosskylix.untergrund.net/execshield.shtml
verwenden (es genügt, nur eine Lib damit zu patchen), dann geht's auch.

Hartnàckig wehren sich dagegen noch CentOS (64bit) und Ubuntu (12.04 und
13.10 32bit). Ich hab jetzt erst mal Ubuntu (32bit) weiterverfolgt (64bit
ist ja vielleicht noch etwas schwieriger zu debuggen), komme aber nicht so
recht weiter. Mit strace sieht man folgendes:

- Gentoo (Kernel 3.10.7, funktioniert):

2265 mprotect(0xb6663000, 4096, PROT_READ) = 0
2265 mprotect(0xb5de4000, 8257536, PROT_READ|PROT_WRITE) = 0
2265 mprotect(0xb5de4000, 8257536, PROT_READ|PROT_EXEC) = 0
2265 mprotect(0xb695d000, 286720, PROT_READ|PROT_WRITE) = 0
2265 mprotect(0xb695d000, 286720, PROT_READ|PROT_EXEC) = 0
2265 munmap(0xb6665000, 32815) = 0
2265 gettimeofday({1386668483, 926366}, NULL) = 0
2265 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 0
2265 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7617000
2265 write(1, "Result=0", 9) = 9

- Ubuntu 12.04 (Kernel 3.8.0, Absturz):

3393 mprotect(0xb652a000, 4096, PROT_READ) = 0
3393 mprotect(0xb5cbe000, 8257536, PROT_READ|PROT_WRITE) = 0
3393 mprotect(0xb5cbe000, 8257536, PROT_READ|PROT_EXEC) = 0
3393 mprotect(0xb682b000, 286720, PROT_READ|PROT_WRITE) = 0
3393 mprotect(0xb682b000, 286720, PROT_READ|PROT_EXEC) = 0
3393 munmap(0xb652c000, 61444) = 0
3393 SIGSEGV (Segmentation fault) @ 0 (0)

Ich hatte zwar auf https://bugs.launchpad.net/ubuntu/+...ug/1131115
schon was von einem "munmap-Bug" auf Ubuntu gefunden, aber wenn hier noch
"= 0" steht, scheint *das* ja zu funktionieren. Könnte es am "gettimeofday"
scheitern? Schreibt strace den "defekten" Befehl überhaupt noch ins Log,
oder ist der letzte Log-Eintrag der letzte *funktionierende*?

Will gettimeofday vielleicht die Zeit in einen Speicherbereich holen, der nur
zum Lesen freigegeben ist? Der Pointer wird im strace ja aber anscheinend nicht
angezeigt, sondern nur, was dort steht...?!

Wobei die Grundfunktionalitàt des Programms schon laufen würde; es stürzt nur
dann ab, wenn XML-Funktionalitàt aufgerufen wird; die entsprechenden Kylix-
Libs (libstdc++-libc6.1-1.so.2, libxerces-c1_6_0.so, libxercesxmldom.so.1,
libicudt20l.so, libicuuc.so.20) habe ich aufs Zielsystem rüberkopiert. (Selt-
samerweise werden die bei "ldd" aber gar nicht angezeigt?! Nur die "System-
Libs" wie libc etc. wie oben aufgeführt.)

Langer Rede kurzer Sinn: Was ist an Ubuntu anders als an anderen Linuxen? :-)
(Und was auf 64bit-Systemen? Ich mache natürlich "gcc -m32" und habe alle
nötigen 32bit-Libs installiert.)

Danke & Gruß Matthias.

PS: Auf Ubuntu 13.10 und CentOS 6.5 (64bit) "verabschiedet" sich strace ganz
woanders...
 

Lesen sie die antworten

#1 Edzard Egberts
10/12/2013 - 17:15 | Warnen spam
Matthias Hanft schrieb:
Könnte es am "gettimeofday" scheitern?



Bei der Umsetzung auf 64bit muss die Unix-Zeit beachtet werden, da sie
von 32bit- auf 64bit-Werte wechselt. Ansonsten àndern natürlich noch
alle Zeiger ihre Lànge.

Wobei die Grundfunktionalitàt des Programms schon laufen würde; es stürzt nur
dann ab, wenn XML-Funktionalitàt aufgerufen wird;



So etwas habe ich in meinem Code öfter korrigieren müssen:

unsigned Pos= string("Test").find('q');
if (Pos== string::npos) // immer ungleich!

mit

string::size_type Pos= string("Test").find('q');

geht der Vergleich dann.

(Und was auf 64bit-Systemen? Ich mache natürlich "gcc -m32" und habe alle
nötigen 32bit-Libs installiert.)



Vielleicht verursacht gerade das den Konflikt zwischen 32bit- und
64bit-Zeit? Ist aber nur geraten...

Ähnliche fragen