digitalmars.D.bugs - [Issue 14008] New: cross-compiling dmd.exe with MinGW
- via Digitalmars-d-bugs (54/54) Jan 19 2015 https://issues.dlang.org/show_bug.cgi?id=14008
https://issues.dlang.org/show_bug.cgi?id=14008 Issue ID: 14008 Summary: cross-compiling dmd.exe with MinGW Product: D Version: D2 Hardware: x86 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nobody puremagic.com Reporter: ketmar ketmar.no-ip.org Created attachment 1469 --> https://issues.dlang.org/attachment.cgi?id=1469&action=edit fixes for MinGW this is a patch and a makefile to build dmd.exe with MinGW cross-compiler on GNU/Linux. please, note that this is NOT FOR WINDOWS MINGW, yet it produces windows executable. provided with my lovely "i don't care" attitude. no tests was done. no tries to support 64-bit builds was done. no support for build "debug" version in makefile. and so on. USE AT YOUR OWN RISK. some random notes. why do the code using "%llu" and "%lld" everywhere? it's unnecessary in most places. 'cmon, what sense of casting string length to `unsigned long long` in name mangler?! i was forced to change that formatting to ugly FMTS_U64 and FMTS_I64 macros, as MinGW using msvc6 runtime, which supports "%I64u", but not "%llu". say "hi!" to wonderful C++ language, which has half-assed lambdas and still doesn't have any standard way to specify structure alignment. i simply hacked gcc-specific attributes everywhere i noticed pragmapack. it seems to work for helloworld.d. someone tried to be nice and `delete`d Obj object in object file writer (i'm a great writer, aren't i?). gcc complains about the absence of virtual destructor for such objects, so i commented that out: generally, D compiler doesn't bother to free any memory, so let's be consistent with that habit. i threw in "-Wall", as i'm doing for all my projects… and that was a great mistake. warnings about unused variables, warnings about unused values, warnings about unused labels and unused functions. and — what scares me alot — warnings about using uninitialised variables (one time due to sequencing point, heh — that was a simple typo in the code). i just silenced gcc again: i'm not in the mood of fixing that mess and then let fixes rot in bugzilla forever. the code in root/async.c gave dmd.exe a gift of crashing in Wine. i was too lazy to figure out what that code was supposed to do and just hacked one "#if", so it falls back to non-threaded version. does anybody measured if that code gives any significant speedup at all? modern OSes does very good job at buffering file data, i don't think we should help 'em there. otherwise i added alot of "include malloc.h", 'cause this is the file where MinGW declares `alloca`, and added `|| __MINGW32__` and like in various ifdefs. happy hacking. --
Jan 19 2015