Luke Boswell (Nov 21 2024 at 21:18): Luke Boswell (Nov 21 2024 at 21:18):On linux, if there is no surgical host (which is the default for linking) then users get an error.
LinkingStrategy was set to Surgical (default), but I tried to find the surgical host at any of these paths Either the generic host files or the surgical host files must exist. File status: Generic host (platform/host.rh): missing, Generic metadata (platform/metadata_host.rm): missing, Surgical host (platform/linux-x64.rh): missing, Surgical metadata (platform/metadata_linux-x64.rm): missing but it does not exist.
I think it should be ok to default to the legacy host if one is available and just use that without a warning.
I think we discussed it previously, that roc should only give a warning if a --linker flag was given, otherwise link the prebuilt host that is available.
Just wanted to confirm we're happy to change to use the legacy host without a warning if no flag is provided.
Brendan Hansknecht (Nov 22 2024 at 04:57):110%
Anton (Nov 22 2024 at 10:02):I think I left that out in purpose in the rebuilt host PR, it complicated the code a lot at the time, and that particular function is already very complex. It could be easier though to integrate in the current version, not sure. I do still strongly dislike this type of switching things silently behind the scenes.
Once we have a standardized way to build platforms that everyone uses this should occur very rarely.
I prefer a nice error tip by a large margin, or at least a warning mentioning the switch to the user.
Anton (Nov 22 2024 at 10:11):The legacy linker can be very noticeably slower, silently degrading the user experience feels like a mistake.
Anton (Nov 22 2024 at 10:13):I am aware that switching automatically is also an improvement to the user experience.
Anton (Nov 22 2024 at 10:13):A warning feels like it strikes a good balance
Jasper Woudenberg (Nov 22 2024 at 11:59):For me, being able to specify the linker to use as a platform setting would already make a huge difference. The platform I'm working on seems to run into this error case for any application I write against it, and it'd be nice if users writing scripts against it wouldn't need to pass this --linker=legacy option.
Richard Feldman (Nov 22 2024 at 12:08):hm, so a relevant consideration here is that long-term the goal is to eliminate the legacy linker
Richard Feldman (Nov 22 2024 at 12:08):(the only reason it's called "legacy" and not "deprecated" is that we don't have the surgical option available on all our supported targets yet)
Richard Feldman (Nov 22 2024 at 12:10):so it seems like this might create the impression that it's something we're planning to support indefinitely :thinking:
Richard Feldman (Nov 22 2024 at 12:11):are there platforms where surgical hosts can't be created successfully on Linux right now?
Anton (Nov 22 2024 at 12:22):are there platforms where surgical hosts can't be created successfully on Linux right now?
I have not hit this for a while, but I think it's still possible to hit #3609
Anton (Nov 22 2024 at 12:25):The json package hits #3609 and still requires --linker=legacy
Anton (Nov 22 2024 at 12:26):basic-webserver also hits #3609
Luke Boswell (Nov 23 2024 at 01:26):I do still strongly dislike this type of switching things silently behind the scenes.
I am ok leaving this for now.
I will work to try and ensure our platforms have a surgical host.
I think this will only be experienced by people dipping into platform development, and it is reasonable thing for these persons to learn about roc.
Brendan Hansknecht (Nov 23 2024 at 01:48):We should definitely silently switch behind the scenes in my opion
Brendan Hansknecht (Nov 23 2024 at 01:48):The surgical linker isn't ready
Brendan Hansknecht (Nov 23 2024 at 01:48):Not even on linux
Brendan Hansknecht (Nov 23 2024 at 01:48):And it is totally unsupported on other platforms
Brendan Hansknecht (Nov 23 2024 at 01:48):If a platform only supports the legacy linker today. We should just use the legacy linker
Brendan Hansknecht (Nov 23 2024 at 01:49):It benefits zero users to force them to specify the linker flag all the time
Brendan Hansknecht (Nov 23 2024 at 01:49):That is a platform detail and not something the user even has control over
Richard Feldman (Nov 23 2024 at 02:41):fair enough
Oskar Hahn (Nov 23 2024 at 07:18):What about the case, that the compiler hits the issue #3609 ?
Currently, there is a special error message. So it is possible for the compiler to detect this case. Should it also automatically use the legacy linker?
Oskar Hahn (Nov 23 2024 at 07:23):I don't know what my opinion is. On the one hand, it is annoying to manually set the surgical linker. On the other hand, as someone who has played with platform development, I probably would not have learned to build the stuff for the surgical linker and all my platforms would only work with the legacy linker.
So I think that this change will lead in a direction where platforms do not have the files for the surgical linker and therefore the surgical linker gets irrelevant.
Oskar Hahn (Nov 23 2024 at 07:27):For example, you can see how strange the changes are, to support both linkers in a go platform:
https://github.com/lukewilliamboswell/roc-platform-template-go/pull/1/files
I get, why @Luke Boswell did not merge this PR. If I had a Mac and therefore did not have to manually specify the legacy linker, I would not do all the hacks to support the surgical linker.
Brendan Hansknecht (Nov 23 2024 at 07:30):That's fair
Brendan Hansknecht (Nov 23 2024 at 07:31):I think the surgical linker has a major bug that will require a significant rewrite. It is lucky that it works most of the time, but until it works all the time it is nice to have but not really worth forcing on people.
Brendan Hansknecht (Nov 23 2024 at 07:31):It is cool that it is super fast, but that isn't the end all be all.
Luke Boswell (Nov 23 2024 at 07:31):I hadnt noticed that PR...
Oskar Hahn (Nov 23 2024 at 07:32):Luke Boswell said:
I hadnt noticed that PR...
And you gave me merge permissions. So it's not fair that I point at you :stuck_out_tongue_wink:
Last updated: Jun 16 2026 at 16:19 UTC