-
Notifications
You must be signed in to change notification settings - Fork 49
Trying to -fuse-ld with swiftly's ld.lld proxy causes circular invocation #272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
After some more testing, it seems that in CMake, However, this originally came up with a third-party meson configure via vcpkg inside a CI runner, which ends up passing the full path to the linker. I'm not quite sure how it ended up selecting the ld.lld version from the swiftly toolchain, because on my local machine it always picks |
Thanks for raising this. There are some ideas about how the circularity error could make it easier to pinpoint how it happens. For example, maybe the internal environment variable could keep a PID, and the error might dump both process' argv and env. Do you think that would help track down this problem? |
Well, I suppose a better way to frame my issue is that I'd prefer that that this "just works ™ ". While it's not particularly standard to use a full path in -fuse-ld, it does seem like clang supports it just fine for other linkers. I could go poking around in the vcpkg wrapper for meson builds and try to see why it's normalizing the path to the system linker. A "portable" final command line might look more like Is there a good place to look in the swiftly code for why a "circular proxy invocation" needs to be a fatal error? Even if invoked for two different tools? |
@ADKaster the circular proxy invocation is a fatal error to avoid process bombing a system. Maybe the check needs to be more sophisticated, but that's the reasoning. |
It seems that the reason this happens in my vcpkg config is related to the Whenever a port needs to extract information such as the compiler, the linker, the archiver, or other implicit information to pass on to a non-cmake build system, it will use this It's simply bad luck that the first case I ran into was the It seems that CMake itself normalizes the path to CMAKE_LINKER, which is a private |
If there's no clear way to make the proxy sometimes accept circular arguments, then in order to keep using swiftly toolchains for my project I'll need some way to work around this limitation with full paths to Is there a way to add a command to like, print the current toolchain bin dir? If I use the paths to binaries that are directly in the toolchain dir as CMAKE_C_COMPILER/CMAKE_CXX_COMPILER, then they don't have the proxy wrapping them, and have symlinks as I would expect from an install of llvm and friends. I suppose this is a special case where the pre-proxy behavior was desirable, as it simply created symlinks into the real toolchain directory. |
@ADKaster a workaround for now might be to ask swiftly where the currently in-use toolchain is located:
And then construct a PATH without swiftly, and just this path entry in it. |
Ah! I'm not sure how I missed that option. I prototyped up a CMake disaster using clang --print-prog-name that seems to work. Using that path from swiftly use should make things a lot less messy. |
Uh oh!
There was an error while loading. Please reload this page.
It's impossible to use swiftly's lld with -fuse-ld on Ubuntu 24.04
Passing in the lld as distributed by apt.llvm.org works fine:
Invoking swiftly's ld.lld proxy directly works as well
The text was updated successfully, but these errors were encountered: