Can we maybe start from the begining again?

If you compile with subsusyem=console, why do you need to allocate a console in 
the first place and then reopen stdout? console apps already do that 
automatically, like so:

// test.c
#include <stdio.h>
int main() {
    printf("press enter to exit\n");
    fgetc(stdin);
    return 0;
}

And you compile it simply as:
tcc test.c

Or as in your example (omitting -m32 because I use a native tcc 32, to reduce 
the number of variables):
tcc -std=c11 -Wall -Werror -Wl,-subsystem=console test.c

Then if you run it in a console then it prints the message and waits for 
"enter", and if you double click it in explorer then it opens a console and 
prints the message in that console and waits for "enter".

Isn't this what you're trying to achieve?

Why is _MSVCRT_ defined in your example? Why is windows.h included in your 
example?

Maybe you have some other problem, and the example program which you attached 
is your attempted solution, which didn't work, and now you try to make it work?

If that's the case, maybe you can go back and describe your original problem, 
and the standard minimal program which you wrote to solve it (without defining 
_MSVCRT_), and which compiles in mingw gcc or msvc.

Please describe exactly how you compile it with mingw gcc, and then how you 
tried to compile it with tcc, and what went wrong.

- avih




On Sunday, November 24, 2024 at 07:43:30 PM GMT+2, Fereydoun Memarzanjany via 
Tinycc-devel <tinycc-devel@nongnu.org> wrote: 





If you use TinyCC in its 32-bit mode (`-m32`) to compile a sample
program that uses any CRT function/symbol from `msvcrt.dll` (such as
the snippet provided later in this message), you'll be met with
compilation failures:

`tcc.exe -std=c11 -Wall -Werror -Wl,-subsystem=console -m32 .\main.c`
"tcc: error: undefined symbol '_iob', missing __declspec(dllimport)?"

(This only happens under `-m32`, whereas `-m64` works perfectly fine.)

`_iob` is not the only "unresolved" symbol, either; `printf`,
`freopen`, `freopen_s`, and basically everything from the CRT will
fail to link.

Regardless of whether or not you use `-lmsvcrt`, `#pragma comment(lib,
"msvcrt")`, `_declspec(dllimport)`, `attribute ((dllimport))`,
`-static` or `-shared`, or even `-impdef` on
"C:\Windows\SysWow64\msvcrt.dll" (or earlier versions thereof:
"msvcrt40.dll"), TCC still complains.

I've verified with `DUMPBIN.exe` that both 32- and 64-bit "msvcrt.dll"
do, in fact, define `_iob` and other symbols.

By some arcane logic, the following works perfectly fine: `tcc.exe
-std=c11 -Wall -Werror -Wl,-subsystem=console -m64 .\main.c`

`main.c`
```c
//#pragma comment(lib, "msvcrt")
//__attribute__((dllimport)) extern __declspec(dllimport) FILE _iob[];

#include <windows.h>

// _MSVCRT_ being defined will cause MinGW's stdio.h to use _iob as
// opposed to _imp___iob; only the former is defined in msvcrt.dll.
// However, even though _iob is exported by both the 32- and 64-bit
// versions of said dll, TinyCC still fails to find _iob in the former.
#define _MSVCRT_
#include <stdio.h>

void main() {
    // AllocConsole() and basically everything from kernel32.dll or
    // user32.dll work perfectly fine, both in -m32 and -m64; it's
    // only msvcrt.dll that causes issues with TinyCC.
    AllocConsole();

    // Any CRT function (e.g., freopen, freopen_s, printf, etc.)
    // fail to get linked properly ONLY in -m32; -m64 is fine.
    // Even if I change the -I and -L paths to C:/Windows/SysWow64
    // and/or use tcc.exe -impdef to create .def files from them,
    // TCC still fails in finding _iob and other symbols.
    // Also, using #pragma comment(lib, "msvcrt") or -lmsvcrt
    // doesn't help at all.  Even if you do get TCC to somehow
    // stop complaining about missing symbols, it'd just include
    // a blank IAT.printf or IAT.freopen, causing segfaults.
    freopen("CONOUT$", "w", stdout);
    printf("This only compiles (and prints) under TCC in 64-bit mode.");
}
```

As mentioned earlier, this error in `-m32` happens regardless of other
switches like `-std`, `-shared`, `-static`, `-lmsvcrt`, `-subsyetem`,
etc.  So, at this point, I'm starting to think this might really be a
bug with TinyCC 0.9.27 (Win32 & Win64 builds) itself.

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Reply via email to