Fucking MingW

#include <stdio.h>

int main() {
 printf("Hello world!\n");
 return 0;
}

Default MingW compilation+link size: 47KB
Best MingW compilation+link size: 8KB

Default MSVC compilation+link size: 40KB
Best MSVC compilation+link size: 1KB

After postprocessing:
MingW (using MS's linker and libs): 1594 bytes
MSVC: 624 bytes

What the fuck? Am I missing something here?

MingW optimised command line (compile only):
gcc -nostdlib -Os -c -s -o hello.obj hello.c -Wl,--gc-sections,--section-alignment,4096,--file-alignment,512

MingW link command line:
link hello.obj msvcrtlib mainstub.obj /align:4096 /filealign:512 /entry:main /merge:.rdata=.text /merge:.eh_fram=.text /merge:.text.st=.text /section:.text,EWR /stub:mzstub64.exe

mainstub.obj is a dummy __main because libming32.a which is supposed to contain it also contains __CTOR_LIST_ and some other C++ shit. I'm compiling a C program, with gcc, and they force you to link with a bunch of C++ shit? Are you kidding me?

(Why won't it merge the bloody .eh_fram and .text.st sections?!?! Maybe this is a bug of MS's linker since it merges fine with its own compiler output, but the compiler shouldn't be generating .eh_fram and .text.st anyway!)

Executables for your inspecting:
MingW: http://pastebin.com/vZn5WtMz
MSVC: http://pastebin.com/AV63Hr5x

Therefore, I challenge anyone to come up with a smaller Hello World using MingW, and post the commands you used to do it.

http://www.thewebcomiclist.com/o/8538

What's a few hundre bytes between friends?

>>2
fuck off fagshit

I tried Googling about on your behalf, but what I found is totally unhelpful:

http://www.mingw.org/wiki/Large_executables

>>1,3
I suppose the real question to ask is, why do you care? If you are really that concerned about performance, I think you are going to be stuck using msvc or icc on Windows anyway.

Yeah, I know both of those suck for various other reasons, but at least you can keep mingw around for your build scripts instead of using .vcproj or whatever terrible thing Microsoft expects you to use.

>>1

comparing anything based on ``hello world''

The extra few kilobytes will be irrelevant once you write a real program.

>>5

Doesn't Visual Studio come with nmake, which is a POSIX-compliant make?

you should feel bad for using winshit

>>5
It does, and POSIX make will get the job done fine if you are building a trivially small project. For bigger stuff, your options are: gmake (in MinGW, decently fast and very powerful), autoconf + automake (gag me, also slow), or CMake (not really make, but really fast).

>>5
Oh, and in case it's not clear why POSIX make isn't a real answer for big projects:

[1] POSIX make has next to no support for generic rules. Pattern rules? Haha you wish, use .SUFFIXES.

[2] It is also totally incapable of supporting dependency generation on its own. There's no include, at all, so you need to write your own shitty makedep or whatever. If your compiler isn't gcc, this will be just loads of fun.

I don't know why people say FrozenVoid left when he's clearly been here all along.

>>9
Regarding [1]: I recently wrote a Makefile to track an arbitrary number of Metapost diagrams from one .mp file to put into a latex document, without giving it each possible .1, .2, .3... file individually.
The solution is trivial, and that's to give it a dummy target file that's touched after successful compilations.

I also once wrote a generic Makefile that allows recursion deep into file heirarchies, without recursive make calls, without name clashes from identical filenames in different folders, with a simple OBJECTS= and SUBDIRS= system for each subfolder's module.mak, and with pretty output.

I don't see why I should use a different build system when this one suits me perfectly fine and is very portable.

>>9

There's no include

Thankfully, they added this in Posix 2008:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html#tag_20_76_13_02

intel-loving kike

>>11

How did you do it? Did you generate absolute paths down from the root directory?

>>14
I'm not entirely sure of the specifics any more, but here's the skeleton for every directory's module.mk:

DIRS    :=
OBJS    :=

### Do not edit below this line!
PWD    := $(dir $(lastword $(MAKEFILE_LIST)))
ALLOBJS    := $(ALLOBJS) $(addprefix $(PWD), $(OBJS))
ifneq ($(DIRS),)
include $(addprefix $(PWD)/, $(addsuffix /module.mk, $(DIRS)))
endif
DIRS being all subdirectories, and OBJS being source/object file names with extensions stripped.
The root Makefile includes
include ./module.mk
OBJECTS := $(addsuffix .o, $(ALLOBJS))

I guess I was slightly misleading when I said "without name clashes from identical filenames in different folders", because apparently all .o files get put alongside all .c files. But that's easy enough to change, I just didn't need to at the time.

>>11
Works great until you delete one of the .n files.

>>12
Neat, didn't know that. I wonder if nmake supports using it in POSIX mode...

>>14
That's pretty much the only way to do it.

>>15
$(dir $(lastword $(MAKEFILE_LIST)))
This is textbook GNU make.  I thought you had done everything in >>11 using only POSIX make - that would be really impressive.

>>15
Everything below

### Do not edit below this line!

can be changed to a regular macro and hoisted up into the main makefile. All you really need to have is an include_dir macro that you can eval to include all the module files.

>>16,17
Ah. I had a feeling it wasn't unsurpassably incredible. Cheers for the tips.

This entire fucking thread is worthless because all of these compilers are trash.

TCC absolutely destroys all of its' competition in terms of output size, compilation time, and pretty much anything else you can think of. It also supports C scripting just because it's that awesome.

TCC manages to be this awesome and take up how much space? The TCC executable, including C preprocessor, C compiler, assembler and linker is 100 KB. That's right. You can fit this shit on your floppy.

>>19
TCC also doesn't support even a tenth of what all the other big name compilers do. I'm sure it's nice if you don't need something ``exotic'' like -ffunction-sections, but if you do...

Also,
http://bellard.org/tcc/
I am no longer working on TCC. Check the mailing list to get up to date information.

Programming shouldn't be done in PDP macro assembly.

TCC
output size
No.
compilation time
Yes.

>>22
I've tested it out. In every case TCC destroyed gcc often by factors of 10-50+.

It would be a fair comparison if tcc was capable of any optimization. It's a Toy C Compiler.

>>24
Everything is optimized without any flags.

>>24
Real programmers write good code.

It's a Toy C Compiler.
Or a quite good C JIT.

>>27
A good JIT necessarily performs optimizations. Otherwise you are talking about a naive JIT.

mingw gcc + msvc link:

$ gcc -nostdlib -Os -s -c small.c -ffunction-sections -fdata-sections -Wl,--gc-sections,--section-alignment,4096,--file-alignment,512

$ link small.o msvcrt.lib __main.o /entry:_start /subsystem:console /merge:.rdata=.text /merge:.eh_frame=.text /merge:.bss=.text /fixed

$ du -b small.exe
1024

Best I could get with just mingw gcc and mingw ld:

$ gcc -Os -s -o smallmingw.exe small.c -mconsole -nostartfiles -ffunction-sections -fdata-sections -Wl,--gc-sections,--section-alignment,4096,--file-alignment,512,-e,__start,merge_sections.ld

$ du -b smallmingw.exe
1536

merge_sections.ld script:

SECTIONS {
    .text : {
        *(.text)
        *(.eh_frame)
        *(.idata)
        *(.rdata)
        *(SORT(.rdata$*))
    }
}

(I still can't get rid of the .idata section for some reason, if I could the size would be 1K just like msvc linker)

small.c:

#include <stdio.h>

void _start(void)
{
    puts("Hello World");
}

And this is not using any packer or PE stub tricks, just the basic compiler output.

>>29

$ du -b smallmingw.exe
$ du -b s

czech em

>>29
*(SORT(.rdata$*))

Why?

>>5
Not performance, but efficiency. I guess the better question to ask is <i>why are you using gcc</i>. That's not by choice, there's too much opensource code out there that's dependent on its features. (I'm thankful that at least gcc produces COFF that MSVC's linker can consume, and not its own format.)

>>6
I don't care about "scalability" or whatever you call it, if it can't do a basic "Hello World" at least as efficient as MSVC, then it's worse. The majority of the projects I work on are <32KB anyway.

>>19-23
TCC has no optimisation at all. So long as it's not too much, I don't care if a compile takes longer if it can produce more efficient output.

>>29
So that's how you merge sections... can you set the section attribute to EWR too?

Don't touch my free-software ThinkPad or try to curtail my essential rights, cretin. I will kill any intruders. You have been warned.

>>36
eat shit and die, nazi so-called feminist piece of shit

>>36
LET'S BAN CRYPTOGRAPHY AND FOSS SOFTWARE AND GENERAL PURPOSE COMPUTERS BECAUSE SOMEONE SOMEWHERE MIGHT SEND AN ENCRYPTED MESSAGE CONTAINING A JOKE THAT MAY BE INTERPRETED AS DEPICTING HOMOSEXUALITY IN A SLIGHTLY NEGATIVE MANNER.  SUCH A DISGUSTING ACT MUST NOT GO UNPUNISHED.


SECTIONS {
    .text : {
        *(.text)
        *(.eh_frame)
        *(.idata$*)
        *(.rdata)
        *(SORT(.rdata$*))
    }
}
This will at least place the import data into the .text section, but the .idata section is still generated for some damn reason.

$ objcopy -R .idata smallmingw.exe

Will remove it, however this will cause it to crash so you need to fix the imports manually, I used PE Explorer.
Afterwords with some more post-processing:

$ du -b smallmingw.exe
687

So challenge met (kind of)

Who the hell said TCC doesn't optimize? Quote:
TCC does perform a few optimizations, such as constant propagation for all
operations, multiplications and divisions are optimized to shifts when
appropriate, and comparison operators are specially optimized (by maintaining
a special cache for the processor flags). It also does some simple register
allocation, which prevents many extraneous save/load pairs inside a single
statement.