Problem beim Kompilieren vom slrn-Source als 64-Bit-executable

01/06/2013 - 00:43 von Uwe Premer | Report spam
Mein Ziel:
ich möchte die neueste git-Version des Quelltextes vom Newsreader slrn
unter Windows 7 Pro 64 zu einem 64-Bit-Windows-executable kompilieren.

Dazu habe ich mir folgende Requisiten heruntergeladen und den passenden
64-Bit-Compiler (mingw64) schon funktionsfàhig installiert:
- slrn-pre1.0.2-8.tar.gz
- slang-pre2.3.0-88.tar.gz
- Console 2.00b148c x64.exe
- slcurl-pre0.2.2-5.tar.gz
- slirp-pre2.0.0-24.tar.gz
- mingw64 in Form von x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z

mingw64 habe ich nach Auspacken nach C:\mingw64 kopiert und die
User-Variable PATH entsprechend angepaßt.

Als Grundvoraussetzung muss ja erstmal slang kompiliert werden, dieses habe
ich ebenfalls ausgepackt und nach C:\Sources\s-lang kopiert.

Der erste Schritt zur Kompilation von slang klappt dann auch noch:

X
Setting up environment for MinGW-w64 GCC 64-bit...
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

C:\mingw64>cd \Sources\s-lang

C:\Sources\s-lang>mkfiles\m32init.bat
- generating Makefile in src...
- generating Makefile in slsh...
- generating Makefile in modules...
1 Datei(en) kopiert.
-
Now run mingw32-make to build the library. But first, you should
look at Makefile and change the installation locations if
necessary.
-
X
Dem entsprechend habe ich dann in der .\src\Makefile folgende kleine
Änderung gemacht:

prefix=/mingw/local #durch
prefix=/mingw64/local #ersetzt

Danach dann ein Versuch eines makes:
X
C:\Sources\s-lang>mingw32-make
cd src && mingw32-make COPY="cmd /c copy /y" RM=del prefix=C:/mingw/local
mingw32-make[1]: Entering directory `C:/Sources/s-lang/src'
gcc -c -DWIN32 -DSLANG_DLL=1 -O2 -W -Wall -o gw32objs/slang.o ./slang.c
In file included from ./slang.c:30:0:
./slang.h:1403:1: error: unknown type name 'HANDLE'
SL_EXTERN HANDLE SLw32_Hstdin;
^
./slang.c: In function 'execute_intrinsic_fun':
./slang.c:3621:14: warning: cast to pointer from integer of different size
[-Win
t-to-pointer-cast]
if (NULL == (char *)ret)
^
./slang.c:3623:33: warning: cast to pointer from integer of different size
[-Win
t-to-pointer-cast]
else (void) SLang_push_string ((char *)ret);
^
makefile:247: recipe for target `gw32objs/slang.o' failed
mingw32-make[1]: *** [gw32objs/slang.o] Error 1
mingw32-make[1]: Leaving directory `C:/Sources/s-lang/src'
makefile:15: recipe for target `all' failed
mingw32-make: *** [all] Error 2
X
An der Stelle komme ich dann nicht weiter.
Einmal kennt der Compiler das "HANDLE" in Zeile 1403 innerhalb der
.\src\slang.h nicht und in der slang.c stimmts auch nicht.
Insofern wird dann wohl keine Datei .\gw32objs/slang.o erzeugt und damit
dann für die Weiterverarbeitung gefunden.

Problem ist wohl irgendwie, das lese ich aus dem von mir geànderten Makefile,
| # This Makefile is for the MINGW32 environment
also wohl nicht ganz 64-Bit-kompatibel.

Hat es überhaupt Sinn, die Fehler zu korrigieren oder artet das eh zuviel
aus, aus dem 32-Bit-kompatiblen Source ein 64-Bit-Text zu machen?
Oder wie kann man das überhaupt hinbekommen?

Uwe
 

Lesen sie die antworten

#1 Ulrich Eckhardt
03/06/2013 - 10:18 | Warnen spam
Am 01.06.2013 00:43, schrieb Uwe Premer:
./slang.h:1403:1: error: unknown type name 'HANDLE'
SL_EXTERN HANDLE SLw32_Hstdin;



#include <windows.h>


./slang.c: In function 'execute_intrinsic_fun':
./slang.c:3621:14: warning: cast to pointer from integer of different size
[-Win
t-to-pointer-cast]
if (NULL == (char *)ret)
^
./slang.c:3623:33: warning: cast to pointer from integer of different size
[-Win
t-to-pointer-cast]
else (void) SLang_push_string ((char *)ret);



Wenn Du mich fragst zeugt beides von hochgradig kaputtem Code. Die Casts
sollten in C nicht noetig sein und zeigen IMHO dass der Autor einfach
nicht den richtigen Typ kannte oder wollte und dann halt mit Gewalt
gearbeitet hat. Auf jeden Fall ist das eine moegliche Fehlerquelle zur
Laufzeit. Fuer eine genauere Antwort und moegliche Alternativen muesste
man sich aber den Code ansehen.


Hat es überhaupt Sinn, die Fehler zu korrigieren oder artet das eh zuviel
aus, aus dem 32-Bit-kompatiblen Source ein 64-Bit-Text zu machen?
Oder wie kann man das überhaupt hinbekommen?



Ich bin mir relativ sicher dass SLRN 64-kompatibel ist, nur u.U. nicht
mit der OS/Compiler-Combo. Unter Linux geht es naemlich mit 64 Bit.

Uli

Ähnliche fragen