Skip to content

Conversation

@MichalStrehovsky
Copy link
Member

Before this change, running link.exe on the output of the compilation produced LINK : fatal error LNK1561: entry point must be defined.

This took longer to figure out than I would be willing to admit.

There are two things at play - linker uses the presence of a method named main or wmain to choose between setting wmainCRTStartup or mainCRTStartup as the actual entrypoint of the application (C apps don't start with main - they start in the C runtime library that calls main).

In #21 we deleted the __fail_fast method from main.cpp and then in #72 we also removed the compiler reference to the now non-existent symbol. The obscure result of that was that main.obj stopped being part of the linking set because nothing now references symbols from it. When linker looks for main or wmain, it only looks at object files that are already part of the linking set.

As a result, linker didn't inject wmainCRTStartup as the entrypoint and we failed with the above message.

It looks like the only way out is to hardcode the CRT implementation detail here. We were already hardcoding it, but for other reasons.

We also need to set the subsystem since the autodetection is failing.

Before this change, running link.exe on the output of the compilation produced `LINK : fatal error LNK1561: entry point must be defined`.

This took longer to figure out than I would be willing to admit.

There are two things at play - linker uses the presence of a method named `main` or `wmain` to choose between setting `wmainCRTStartup` or `mainCRTStartup` as the actual entrypoint of the application (C apps don't start with `main` - they start in the C runtime library that calls `main`).

In dotnet#21 we deleted the `__fail_fast` method from main.cpp and then in dotnet#72 we also removed the compiler reference to the now non-existent symbol. The obscure result of that was that main.obj stopped being part of the linking set because nothing now references symbols from it. When linker looks for `main` or `wmain`, it only looks at object files that are already part of the linking set.

As a result, linker didn't inject `wmainCRTStartup` as the entrypoint and we failed with the above message.

It looks like the only way out is to hardcode the CRT implementation detail here. We were already hardcoding it, but for other reasons.

We also need to set the subsystem since the autodetection is failing.
@jkotas
Copy link
Member

jkotas commented Aug 31, 2020

LGTM. I guess building the bootstrapper as .obj would fix this too, but it would be more complex change.

@jkotas jkotas merged commit a19596e into dotnet:NativeAOT Aug 31, 2020
@MichalStrehovsky MichalStrehovsky deleted the entrypoint branch August 31, 2020 17:16
scalablecory pushed a commit that referenced this pull request Sep 22, 2020
Add server-side code for calculating and formatting the Retry Packet Integrity field, and update client code to calculate and verify the integrity value.
MichalStrehovsky pushed a commit to MichalStrehovsky/runtimelab that referenced this pull request Oct 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants