meson 0.60 does not set SONAME for shared_module() anymore #9492
Comments
|
I can't reproduce this. With 0.59.4: And with Meson 0.60: |
|
@nirbheek Hmm, sorry my attempt at a reproducer failed. I hadn't actually tried it precisely that way myself; I simply noticed that the rpath validation phase in Guix would fail when attempting to build NetworkManager with Meson 0.60 and succeed with 0.59.4, as show in the log originally posted. There's probably something else at play then :-(. |
|
Have you already reported this to Guix? Or are you a Guix maintainer yourself? In any case, we need more details to be able to do anything here. |
|
Hello; I'm one of the army of Guix maintainers, yes :-). I was assuming the problem had to do with Meson since just going back to 0.59.4 makes the issue go away. Perhaps one thing which we have in Guix which is not going to be found on traditional distributions is that the 'ld' linker binary available on PATH is a wrapper script to the real GNU ld, which is tasked with translating any link directive used during the build into rpath directives (see: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/ld-wrapper.in?id=2b76179ecd951172288f5f6f78402d9304d2da41#n44). So, if for some reason Meson from 0.59.4 to 0.60 now links with objects in the source directory, that would be captured in the binaries as rpaths because of this script. Did Meson's behavior change in this regard? |
|
To be clear, every version of meson adds rpaths for the build directory (not the source directory). These rpaths are generically speaking useful to ensure that shared libraries which an executable links to, are functional when running the uninstalled version of the program. There is a depfixer script which runs against installed binaries and is supposed to remove those rpath entries (but leave alone the ones you added as link args). As I don't understand the format of the error message which Guix is displaying... what is the problematic rpath field of the binary that is failing your validation? |
|
Hello! @eli-schwartz: The relevant bit is this line: What it's saying is that the Indeed, I can see 0.59.4 passes Looking at I'm not sure how to address this but the bogus |
|
Huh... Isn't shared_module only supposed to be used for things like dlopened plugins, that are never linked to? Why is networkmanager creating one, then linking to it? |
I suppose that libnm-wwan.so needs to link to the executable, but is also a dependency of libnm-bluetooth.so. I think that should be a shared_library as you say, and the bug is in Network manager, but perhaps we need to make the behavior depend on the minimum required meson version? Can you Guix folks check if changing wwan from module to library fixes it? |
|
@bonzini Changing Note that the problem is not limited to NetworkManager; it's fairly common in the GNOME and Freedesktop stack, which so far we worked around by switching to 0.59: https://git.savannah.gnu.org/cgit/guix.git/log?id=9f94eb3d7bb9dab83d5df80b4f05558abfcc5564 |
You should do this: shared_library('nm-wwan', ...,
override_options: ['b_lundef=false'])Can you try that and see if it works? It really should. This feature (
Yeah, I think this makes sense. |
nirbheek
changed the title
|
Hi @nirbheek. I confirm that using For the record, NM specifies this: So I suppose it'd be possible to restore the pre-0.60 behavior in this case, as @bonzini suggested, though it may be surprising that changing the minimum requirement changes the way shared libraries/modules are linked. |
This is another way to address <mesonbuild/meson#9492> as suggested by Nirbheek Chauhan and Paolo Bonzini. * gnu/packages/patches/network-manager-meson.patch: New file. * gnu/local.mk (dist_patch_DATA): Add it. * gnu/packages/gnome.scm (network-manager)[source]: Use it. [arguments]: Remove #:meson.
|
The mesonic approach to this problem, if the sonames linkage change is classified as a breaking change rather than a bug that was fixed, is to add a new kwarg This would mean annoying every single user of shared_module anywhere by asking them to switch to shared_library() or confirm they want a real module ( |
|
Is there even a need to deprecate it? Could the default instead vary depending on the minimum version of Meson that the project requires?
|
|
Or even add a soname automatically if a shared_module is used as a dependency, but (independent of the minimum required version of Meson) raise a FeatureDeprecated warning that shared_library+override_options is preferred. |
|
Detecting the specific case where it's used as a dependency for another target and
would be a pretty reasonable option too IMO. The advantage is that we automatically do "the right thing", and get the correct results in each case, and do so no matter what your meson_version is (so people who upgrade their meson copy get better software immediately without having to wait for upstream to drop support for versions of meson that are more than a few days old). Above, I merely commented on what I think would make more sense in the event we actually wanted to make it depend on your version of meson -- i.e. not a straight behavior change based on meson_version, but a deprecation. |
|
So it looks like we have a way forward now. Detect when
Just needs someone to implement it now 😉 PS: This issue is the only blocker issue for 0.60.2 without a proposed pull request |
|
@civodul, can you confirm that the NetworkManager build is already emitting this warning: mlog.warning('target links against shared modules. This '
'is not recommended as it is not supported on some '
'platforms')(It should according to https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/28 but it's an old issue)? That would simplify the implementation quite a bit. I don't have much time this week (sorry) but I placed a sketch here. |
|
You can already test the Meson patch too - what's missing is mostly running the test suite and/or writing a new test. |
Yep, I can confirm that that warning is being emitted. |
Emit a detailed deprecation warning that explains what to do instead.
Also add a unittest.
```
DEPRECATION: target main1 links against shared module linked_module1, which is incorrect.
This will be an error in the future, so please use shared_library() for linked_module1 instead.
If the target requires undefined symbols, you can use `override_options: ['b_lundef=false']`.
```
Fixes mesonbuild#9492
|
I've tested that #9629 fixes the SONAME for libnm-wwan.so in NetworkManager. Someone should really fix NM's build files, it's full of ancient cruft. Lots of warnings, deprecations, and incorrect usage of options 😬 |
Emit a detailed deprecation warning that explains what to do instead.
Also add a unittest.
```
DEPRECATION: target main1 links against shared module linked_module1, which is incorrect.
This will be an error in the future, so please use shared_library() for linked_module1 instead.
If the target requires undefined symbols, you can use `override_options: ['b_lundef=false']`.
```
Fixes mesonbuild#9492
Emit a detailed deprecation warning that explains what to do instead.
Also add a unittest.
```
DEPRECATION: target prog links against shared module mymod, which is incorrect.
This will be an error in the future, so please use shared_library() for mymod instead.
If shared_module() was used for mymod because it has references to undefined symbols,
use shared_libary() with `override_options: ['b_lundef=false']` instead.
```
Fixes mesonbuild#9492
Emit a detailed deprecation warning that explains what to do instead.
Also add a unittest.
```
DEPRECATION: target prog links against shared module mymod, which is incorrect.
This will be an error in the future, so please use shared_library() for mymod instead.
If shared_module() was used for mymod because it has references to undefined symbols,
use shared_libary() with `override_options: ['b_lundef=false']` instead.
```
Fixes mesonbuild#9492
Emit a detailed deprecation warning that explains what to do instead.
Also add a unittest.
```
DEPRECATION: target prog links against shared module mymod, which is incorrect.
This will be an error in the future, so please use shared_library() for mymod instead.
If shared_module() was used for mymod because it has references to undefined symbols,
use shared_libary() with `override_options: ['b_lundef=false']` instead.
```
Fixes #9492
Emit a detailed deprecation warning that explains what to do instead.
Also add a unittest.
```
DEPRECATION: target prog links against shared module mymod, which is incorrect.
This will be an error in the future, so please use shared_library() for mymod instead.
If shared_module() was used for mymod because it has references to undefined symbols,
use shared_libary() with `override_options: ['b_lundef=false']` instead.
```
Fixes #9492
|
Apparently linking shared modules to other shared modules is an essential feature on Android: #9999 |
Describe the bug
After upgrading meson from 0.59.1 to 0.60.0, the network-manager build was failing on GNU Guix like so:
Reverting meson to 0.59.1 fixes the rpaths.
To Reproduce
Specify custom rpath locations via
-Dc_link_args=-Wl,-rpath=/some/pathand inspect the resulting binary.Expected behavior
network-manager should build as it used to with 0.59.1, with correct specified rpaths in the binaries.
system parameters
meson --version0.60ninja --versionif it's a Ninja build 1.10.2The text was updated successfully, but these errors were encountered: