[Issue 14008] New: cross-compiling dmd.exe with MinGW

[via Digitalmars-d-bugs]

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 at puremagic.com
          Reporter: ketmar at 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.

--