Fix linker nonsense partly #9731
Conversation
Codecov Report
@@ Coverage Diff @@
## master #9731 +/- ##
==========================================
- Coverage 67.08% 64.01% -3.08%
==========================================
Files 404 202 -202
Lines 85711 42814 -42897
Branches 18907 9357 -9550
==========================================
- Hits 57501 27406 -30095
+ Misses 23676 13189 -10487
+ Partials 4534 2219 -2315 Continue to review full report at Codecov.
|
| @@ -292,9 +292,9 @@ def detect_static_linker(env: 'Environment', compiler: Compiler) -> StaticLinker | |||
| linkers = default_linkers | |||
| popen_exceptions = {} | |||
| for linker in linkers: | |||
There was a problem hiding this comment.
Why not just add
linker = os.path.basename(linker)Here and call it good?
There was a problem hiding this comment.
linker is a list?
Also this assumes again that the linker is on the path which it is not.....
| override = comp_class.use_linker_args(value[0]) | ||
| check_args += override | ||
|
|
||
| if extra_args is not None: | ||
| check_args.extend(extra_args) | ||
|
|
||
| p, o, _ = Popen_safe(compiler + check_args) | ||
| p, o, _ = Popen_safe(compiler + check_args) # This assume whatever 'compiler' is, is either on PATH or it is an absolute path to a valid executable! |
| @@ -72,13 +72,14 @@ def guess_win_linker(env: 'Environment', compiler: T.List[str], comp_class: T.Ty | |||
| override = [] # type: T.List[str] | |||
| value = env.lookup_binary_entry(for_machine, comp_class.language + '_ld') | |||
| if value is not None: | |||
| compiler = value # If meson is explicitly told a value for the linker so use it! | |||
There was a problem hiding this comment.
If meson is explicitly told a value for the linker, use it!
There was a problem hiding this comment.
This change makes me nervous, this should only get hit in the case of gcc-esque clang, which expects to get the linker value as -fuse-ld=..., so I think this is going to break things.
| if value is not None and invoked_directly: | ||
| compiler = value | ||
| # We've already hanedled the non-direct case above | ||
|
|
There was a problem hiding this comment.
Same here, now we're looking for linkers that are invoked directly, not through the compiler driver. The more I liok at this, the more I feel ilke this change is wrong.
There was a problem hiding this comment.
If I explicitly tell meson to use the linker directly it should shut up and do as I say!
meson really tries too hard to be clever .... (personally I think the whole stuff should be rewritten. I saw many fragments of code duplication, especially for defaults in complier/detect.py and linker/detect.py )
There was a problem hiding this comment.
As far as I'm concerned, meson has to be clever - if you "just use the linker directly" how is it going to know what flags to use for linking? Path conversion, library search locations, whether the target is static or shared etc... There is no concept of a dumb linker because it isn't sensible, I think.
One of my biggest pain points with meson is also one of its biggest strengths - if your compiler is not known, you are forced to implement it properly so all future consumers of that compiler benefit from correct detection.
closes #9730
closes #9727
In my opinion the whole linker detection is a mess... there is no way for a user to opt out of the "meson" behavior......