Default extensions of the executable output file of gcc

[KO Myung-Hun]

Hi/2.

Currently, default extensions of the executable output file of gcc is none except -Zexe.

For example,

gcc -o test test.c

This generates test not test.exe. However, I think, this is not appropriate. Of course, although if using -Zexe, we can get test and test.exe, it needs additional flags.

So it would be better to set default extensions correctly for the executable file like this.

1. .exe if both -c and -Zdll are not specified.
2. .dll if -Zdll is specified but not -c.

[KO Myung-Hun]

This is specific to ld. I attach the patch.

[KO Myung-Hun]

Patch for default extensions

[dmik]

The problem is even bigger (and not covered by the above patch from what I see), please read here: ​https://github.com/psmedley/gcc/issues/24.

To summarize, now we have the following:

#	Options	Output	Result
1	-o test[.xxx]	test[.xxx]	Pure A.OUT EXE with no LX stub
2	[-Zexe] -o test.exe	test.exe	A.OUT EXE with LX EXE stub
3	-Zexe -o test[.xxx]	test[.xxx] test[.xxx].exe	Only LX stub? A.OUT EXE with LX EXE stub
4	-Zdll -o test[.xxx]	test[.xxx]	Pure A.OUT DLL with no LX stub
5	-Zdll -o test.dll	test.dll	A.OUT DLL with LX DLL stub
6	-o test.dll	test.dll	A.OUT EXE with LX DLL stub (non-working DLL)
7	-Zdll -o test.exe	test.exe	A.OUT DLL with LX EXE stub (non-working EXE)

If you give the -Zomf flag, it goes little bit better, the correct executable/DLL is created in each case but if there is also -Zexe, a dummy test file (which appears to be a pure LX stub) is also created.

This all is COMPLETELY WEIRD and inconsistent. There is no point in creating pure A.OUT binaries on OS/2 at all (not until we have native A.OUT loaders or such). Things should be smooth and go like that:

#	Options	Output	Result
1	[-Zexe] -o test[.exe]	test.exe	A.OUT EXE with LX EXE stub
2	[-Zexe] -o test.xxx	test.xxx	A.OUT EXE with LX EXE stub
3	-Zdll -o test[.dll]	test.dll	A.OUT DLL with LX DLL stub
4	-Zdll -o test.xxx	test.xxx	A.OUT DLL with LX DLL stub

And the same with the -Zomf option except that the format should always be a native LX EXE or DLL, respectively.

[dmik]

Note that the attached patch doesn't achieve this goal, so a more complex modification is necessary.

[Yuri Dario]

Always adding exe/dll extension is going to break most makefiles, I'm against this.

[KO Myung-Hun]

@dmik, yes, I didn't consider case 2 and 4. Like a subject, this patch is for default extension. However, case 2 and 4 are also considerable. And a dummy file generated by -Zexe is its purpose to make some Makefile not using .exe extension happy.

@ydario, this patch does not always add .exe/.dll extension. Instead, this patch adds .exe/.dll extension if and only if an extension is not specified. And I don't think, this will break any Makefiles.

[Yuri Dario]

Consider this case:

test: test.c

gcc -o test test.c

You cannot add .exe without breaking the rule.

[KO Myung-Hun]

This patch is to fix exactly such a problem.

BTW, for such a case, could you get a working binary ?

Correct fix is to append .exe to a target. But with this patch you can get a working binary at least, although a result binary is generated whenever you call make.

So, I don't think that your example is not a correct counterexample.

[dmik]

Yes, I agree that the rule is incorrect per se. The target must be a real file in such a case, i.e. test.exe. That said, I don't think we should create a dummy extension-less executable just to please makefiles. That looks too much.

[KO Myung-Hun]

Generate binaries like OMF linkers do

[KO Myung-Hun]

New patch resolves the above problems except -Zexe. The behavior of -Zexe does not change for the compatibility.