fix linker flags for lld-link

[lucascolley]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

An attempt at fixing scipy/scipy#24925. Along the lines of conda-forge/clang-win-activation-feedstock@57f1981.

Closes gh-22

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/23719013012. Examine the logs at this URL for more detail.}

[lucascolley]

After looking into this a bit more, it seems a fix will be required on the Meson side. It has the concept of a LINKER_PREFIX, and sometimes it is prepending -Wl, to each element of LDFLAGS when invoking flang.exe, other times it is just prepending a single -Wl,--version then passing LDFLAGS as given.

Ideally our LDFLAGS here would not need to contain -Wl, or -Xlinker and Meson could correctly handle prepending either /link for clang-cl or -Wl, or -Xlinker for flang when needed.

[isuruf]

Ideally our LDFLAGS here would not need to contain -Wl, or -Xlinker and Meson could correctly handle prepending either /link for clang-cl or -Wl, or -Xlinker for flang when needed.

No. Removing -Wl, is undesirable. Meson is not the only build system. We prepend -Wl, in unixes too for some linker flags.

[lucascolley]

Ideally our LDFLAGS here would not need to contain -Wl, or -Xlinker and Meson could correctly handle prepending either /link for clang-cl or -Wl, or -Xlinker for flang when needed.

No. Removing -Wl, is undesirable. Meson is not the only build system. We prepend -Wl, in unixes too for some linker flags.

Okay. The problem is that when we have -Wl,, lld-link is unhappy with receiving it:

build scipy/_cyutility.cp314-win_amd64.pyd | scipy/_cyutility.cp314-win_amd64.pdb: c_LINKER scipy/_cyutility.cp314-win_amd64.pyd.p/meson-generated_..__cyutility.c.obj | C$:/Users/lucas/ghq/github.com/scipy/scipy/.pixi/envs/build/libs/python314.lib
 LINK_ARGS = "/nologo" "/DEBUG" "/PDB:scipy\_cyutility.cp314-win_amd64.pdb" "/DLL" "/IMPLIB:scipy\_cyutility.cp314-win_amd64.lib" "-Wl,/DEFAULTLIB:C:/Users/lucas/ghq/github.com/scipy/scipy/.pixi/envs/build/lib/clang/21/lib/windows/clang_rt.builtins-x86_64.lib" "C:\Users\lucas\ghq\github.com\scipy\scipy\.pixi\envs\build\libs\python314.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib" "advapi32.lib"

so are we expecting Meson to strip the -Wl, before passing to ninja?

[lucascolley]

Ready for review, this seems to fix the issue for me in combination with mesonbuild/meson#15660.

[lucascolley]

(I don't think it matters for this PR, but shouldn't we be passing -fuse-ld=lld-link given that we have FC_LD=lld-link.exe above?)

[h-vetinari]

Sorry this floundered for a while. I see mesonbuild/meson#15660 got no response yet... How would you like to continue?

[lucascolley]

Seems like we may as well merge this now? Admittedly it is a bit useless until the meson PR is in for SciPy, but maybe it helps some other build system.