Re: [Tinycc-devel] Why does TinyCC fail to link standard C runtime functions in 32-bit mode but works in 64-bit mode?

[avih]

> I shouldn't have put `-subsystem=console` because it'd lead to
> confusion in my example.  The point is that, when you compile with
> `-subsystem=windows` (which all GUI applications do), you _have_ to
> allocate a console

OK, but you didn't provide a minimal "normal" example program which
doesn't define _MSVCRT_ and which you expect to work with tcc, so
I'm going to assume it's the same sample, but without defining _MSVCRT_
and compiled as a GUI app, like so, even with an additional fgetc:

    // test.c
    #include <windows.h>
    #include <stdio.h>

    int main() {
        AllocConsole();
        freopen("CONOUT$", "w", stdout);
        freopen("CONIN$", "r", stdin);
        printf("press enter to exit\n");
        fgetc(stdin);
        return 0;
    }

Compiled as:
tcc -m32 -std=c11 -Wall -Werror -Wl,-subsystem=windows test.c

or as (using native tcc 32):
tcc -Wl,-subsystem=windows test.c

And both invocations compile without errors and work as expected
both from cmd.exe shell and from explorer (i.e. open a new console,
independent of the current console if launched from cmd.exe, print
the message, and waiting for ENTER).

Also, this works regardless of the include order (stdio/windows).

If this is not a program and tcc invocation which demonstrates your
issue, then please provide one yourself.

> I guess using TCC (at least for building full-fledged windows apps) is
> rather niche in comparison to "mainstream" compilers (and its `-m32`
> compiler even more so), explaining why no one has encountered/reported
> this basic bug before.

tcc is maybe niche, but it's irrelevant, and if something is broken
with -m32 then hopefully it can be fixed.

But I'm still not seeing an issue without defining _MSVCRT_.

> the _MSVCRT_ macro is really not all that important here; it's just
> telling <stdio.h> to use the latest MSVCRT.dll as opposed to "old"
> versions of it.  Newer MSVCRT.dll only comes with _iob, because
> _imp___iob has been deprecated.

But it is important. In fact, it's the only important thing, because
without it there's no issue that I can tell or which you demonstrated.

You also didn't explain how did you come up with _MSVCRT_. Doing some
search I'm not seeing it documented or recommended anywhere. All the
search results point to stdio headers internal to mingw. Not in any
project which uses mingw and not in MS compiler/windows SDK docs.

You also didn't explain why an application should care about the
version of msvcrt it ends up linking against. Are you expecting
Microsoft to drop support for older versions? (let's ignore UCRT for
now), Maybe other reasons?

What are they, very specifically?

It's possible that the with official mingw, the behavior changes in
the way you want without getting broken when _MSVCRT_ is defined, and
it's also possible that this doesn't work in tcc, maybe even for the
reasons as you described, and maybe even fixed with your suggested fix.

That could be because the mingw headers in tcc are old or intentionally
stripped in that way or accidentally broken.

But before fixing it in tcc, we'd need a plausible reason, and so far
I've not seen one.