FR: Remove requirement for libraries to be installed, just to build the application #65
Comments
|
We could probably add a meson option that allows to build with only headers present, and call https://mesonbuild.com/Reference-manual_returned_compiler.html#compilerhas_header when it's enabled. |
|
BTW this comes back to our discussion the other day, about the nvidia plugin missing in my install, and I said I would let the other packager know, but he'd have to build the nvidia libs, and he was told he would be banned if he did: https://build.opensuse.org/request/show/1119517?notification_id=43795733#comment-1838966 It's absolutely stupid (and I'm not even sure it's correct) that I can build it in VM 'X' and it's totally legit, but if I built it in VM 'Y', then it's illegal and we will be punished, but that's what we've been told :( |
Maybe very harsh expression =) But yes, you need to compile NVIDIA libs locally. If you compile it in OBS, you can lose repo or you can lose repo with account. Anyway maybe I can be not right. So it's not only for NVIDIA packages. As I know (and rules talks), all proprietary tools repacking without building in OBS is bad. But with permissions maybe you can. But anyway, as I told, Stefan ask me to not enabling build and not add .run files in OBS. I would ask ahjolinna how he/she build NVIDIA drivers in OBS. It's very interesting.
Not entirely true, we can. But with a condition. My tuxclocker build for openSUSE exactly is not conflicted with any license. The problem seems that maybe:
|
I believe you bro. I 'get it', but I just think it's stupid. Nobody wins out of this scenario; not the end users, not the application devs, not the packagers, not openSUSE, not Nvidia; it's a lose-lose-lose-lose situation, it's just dumb that some people let it get to this stage. openSUSE and nvidia (and other distros, this definitely doesn't just effect openSUSE, probably PPAs would be illegal also, etc) they all need to get their shit together and fix problems like this before they happen. But still, here we are, and I have removed my nvidia driver build (so thank you for warning me in case I got a ban for having built it there. I had no idea it was not allowed. You might have saved my ass from a hidden trap!. So THANK YOU BRO)
Yes you're quite right, that was not entirely true, I was being too brief, I'm sory. We CAN build tuxclocker..... just not the nvidia plugin for tuxclocker.... But unless you have an AMD GPU, that's kinda the most important part of it 😢 It is like, we can build the car. Just no motor or wheels 😆 And while we at OBS and openSUSE are first to discover this problem, I am quite certain that it is going to be a problem for practically every distro. At least, in the legal sense, perhaps other distros won't be so strict about it, but still, it's a thing for everyone, I think, except for MAYBE the build-from-source distros like gentoo and maaaayyybe arch maybe. Anyway now we have to find a better long term solution. FWIW, I run a private OBS instance where I can build the nvidia packages (i's legal for me, I don't distribute them, they are not publicly available online) and also tuxclocker, and so for the mean time I would be very happy to provide openSUSE packages to this project, for download by users. I would not be distributing any nvidia binaries, so there's no legal problem there. Or I could just provide the nvidia plugin pre-compiled, which could then be added to your build from OBS (you could use a postinstall script so that it gets it from this repo automatically from the end-user's side, or you could use it as a source for your project and build without it and then just copy it into place). But I understand neither of these kind of things are optimal for many obvious reasons. The good news is that the nvml.h header we need, is not licensed at all, and is definitely open source, so it should be OK for OBS builds.
I agree, I think this is really the best answer. It's mostly just a matter of configuring meson correctly. Unfortunately I never used meson in my professional work, just old-fashioned configure && make or just calling cc in sh scripts (I am old, I moved from developer to manager/consultant, more than 10 years before meson even existed), so I don't know how to fix this. I feel confident that @Lurkki14 will find a way 😃 |
And one more time I want to take the opportunity to say a big big thank you to you, for warning me! |
|
I don't know, anyway, how AUR users build NVIDIA drivers and how it conflicted with licenses/etc. - https://aur.archlinux.org/packages/tuxclocker. Anyway NVIDIA is optdepends in PKGBUILD. nvml.h provided by nvidia-settings tool: https://github.com/NVIDIA/nvidia-settings/blob/main/src/nvml.h But then it should work on X11 and I don't know works it or not. Wayland problem is different problem. |
Right but this is the problem, the way tuxclocker is configured, even though it has those headers, and has the declarations, if the functions are declared but not defined, it generates an error. Normally an app should be able to link against the lib header without the lib or the lib's source being present in order to define the functions, and I think this is what tuxclocker should be doing. |
|
You could do something like this in and have that patch in the package repo. You could also make the NVIDIA plugin a separate package, that the end user can build locally. |
Doesn't work, whenever the code references one of the functions declared in the nvml.h header, it generates an error that the function is not defined. This is because meson is calling gcc and passing the --no-undefined parameter.....I have no idea why it's doing that, and if you could stop it, it should just build as it is, with the header in place, and without the library binary itself
Yeh but that really shouldn't be necessary. An app which wants to use the functions declared in nvml.h should be able to link against that header and then the code will generate pointers to those functions in the library, even without the library being present, and then when the app runs, it will go and run the code for those offsets in the library generated by the linker with the header, and call the functions. |
|
@pallaswept I decline your request in OBS so if you can find solution (or create a patch for meson.build), that doesen't conflict with rules send another. Or if it fixed on git, I wait for new version. |
I guess you could remove the check entirely and see what happens? If not, meson might have a way somewhere to unset the |
Tried that, same result. It's the meson config that needs fixing, so it doesn't set that flag, but I wouldn't know meson from the dark side of the moon. I wish I could help you with that part but I can't. BTW I actually stopped listening to opensuse saying nvidia didn't allow it, and read the license, and it's opensuse that won't allow it to be built on their server, so it might not be a problem with other distros. |
|
Nvidia license: 2.1 Rights and Limitations of Grant. NVIDIA hereby grants Customer a non-exclusive, non-transferable license to install and use the SOFTWARE for use with NVIDIA GeForce or Titan branded hardware products owned by Customer, subject to the following: 2.1.1 Rights. Customer may install and use multiple copies of the SOFTWARE on a shared computer or concurrently on different computers, and make multiple back-up copies of the SOFTWARE, solely for Customer's use within Customer's Enterprise. "Enterprise" shall mean individual use by Customer or any legal entity (such as a corporation or university) and the subsidiaries it owns by more than fifty percent (50%). 2.1.2 Linux/FreeBSD Exception. Notwithstanding the foregoing terms of Section 2.1.1, SOFTWARE designed exclusively for use on the Linux or FreeBSD operating systems, or other operating systems derived from the source code to these operating systems, may be copied and redistributed, provided that the binary files thereof are not modified in any way (except for unzipping of compressed files). So we're good there. OBS CoC (you always know things are going to be stupid when there's a CoC) and in particular the part about what you can't build there: https://openSUSE:Build_Service_application_blacklist
Then there is a big list of blacklisted software and nvidia isn't on it, but because it's not OSI-certified, we'd need an exception from openSUSE.... Which they're never going to give out, they'll just say that this software should be able to build from the headers so we don't need an exception. |
Fedora for example doesen't provide it by default seems, need third-party-repo (RPM Fusion). In Debian it on non-free repo. Seems not openSUSE only problem. |
|
I already have this in my browser history but it's a very brief answer that means very little to me. I don't know where to type the things he said to type. I really don't know anything about meson. |
Yeh, other distros might have similar FOSS-or-GTFO rules. It culd go on opensuse's non-free repo, too, but instead they just host it on nvidia's site that nvidia kindly provided. But my point is, this is nothing to do with nvidia's license, it's the distros that are the problems. |
Having both of those would look like this. |
I'll fork and try it. |
|
We also need to do To not check for the presence of the .so I got all excited for a moment there when it built and then I realised it hadn't tried to build the nvidia plugin hahahah |
|
It builds :) I'll test it before I send a PR |
|
It builds and packages the plugin but doesn't try to load it:
|
|
@pallaswept did you use the same spec? |
Probably some symbols can't be found, check |
|
|
Indeed, linux-vdso.so.1 does not exist on my system. |
https://stackoverflow.com/questions/58657036/where-is-linux-vdso-so-1-present-on-the-file-system |
lol was just about to post that link 😆 |
|
So in that case, it finds everything.... but still, didn't find the plugin so didn' try to load it. Interesting, I guess whatever made the nvml so, shared, broke this.... |
Seems that allowing undefined symbols makes the linker not add |
Like I said mate I don't know anything about your build chain, all these tools are about 15-20 years after my time as a dev... Like, the last time I bought K&R was because C99 just came out. I wouldn't know where to start doing that. I am sorry, I'm trying to help as much as I can, I'm 4 hours past my bedtime, I really am trying to help. I can maybe help with code, but when it comes to that buildchain, it's all a mystery to me |
|
|
Yeh I did notice it's not installed by default so I'll have to make it a build dep but then I don't know the syntax of it, I don't know where to run it, what to run it on, etc.... And making sure that the libraries are properly linked that kinda strikes me as something the build chain should be doing anyway, no (like you said maybe you can get the linker to do that)? |
That's what meson does when you have the library as a dependency |
|
|
so in our case is that
I'll give it a try once I have a clue what you're talking about 😆 But the point is, meson (or whatever build chain you're using) should be configured to do this when it builds the lib. libnvidia.so still has the nvidia-ml.so library as a dependency, a runtime dependency, and the libnvidia.so should know this already once it's built, since it's calling all those functions from the nvml.h header which refer to the defined functions compiled into nvidia-ml.so. Screw it I'll try it and maybe you'll explain it to me like I don't understand it because I really don't.... but I had about the degree of success I expected when I'm guessing from a foo bar baz example of a tool I've never heard of before: nope OK I keep guesing And that looks to me like it never linked that lib, which surprises me none. At least it tried to start the nvidia plugin this time but it instantly segfaulted. It's 5 hours past bedtime for me and I have medical procedures I have to consider coming up so I can't really keep working on this I'm sorry, I'll wish you luck figuring it out while I am away. |
|
|
|
As soon as I posted that I realised why it segfaulted - the first guess I took broke the nvidia lib. So I reinstalled it all and
So yeh, just gonna need to figure out how to get meson to do that at build time. |
Yeh that's what I was trying to do the first time but you didn't exactly give me solid doco with foo.so and my-application-here and I got the arguments the wrong way around lol |
|
@pallaswept Summary, so theoretical possibly to build with nvidia plugins for distro? |
|
Works too. SO yeh, now to get meson to link it properly so this step isn't required.... And I'm not taking any more guesses at syntax for tools I've never seen before on this one. I'm really not bullshitting you when I say I don't know what you're talking about with this build chain. Like I don't get it at all. This is not how I code or ever have. I have to leave meson up to you I'm sorry, I really would help with it if I could but I can't. |
Yes of course, just have to get meson to link to the library properly. Before, it was using the header, but statically linking the lib, which is why it needed the lib there to link against. Now we have shown by building without the lib's .so there, and telling meson to not link it properly, that it can treat a shared lib as a shared lib, but I don't know how to make meson do the linking properly without post-modifying it to point at the lib like we just did. That's the last piece in the puzzle. It's really the only piece of the puzzle there ever was, we've just proven that it can be done, in theory. Making meson do it for real, in practice, that's the thing I can't help with. |
|
Do RPM packages not allow you to have post install scripts? Ideally meson itself wouldn't mess with anything after installing the files. |
|
So we have:
RPM packages do have post install scripts but we shouldn't need to use this hack to make it work, the file should be correct before it's installed, after meson is done with it. |
|
Think of it this way: I can build Gnome here on my KDE desktop, including all of Gnome's shared libraries, without needing to install Gnome as a prerequisite, and without having to install Gnome afterwards and then run commands to make it work, just using Gnome's sources. This should be the same. We have the source - we have the nvml.h, that should be enough to build it and link it. Just to demonstrate that the nvidia-ml.so does not need to exist, to have the tuxclocker plugin link to it: Now there is no nvidia-ml.so present. The "build requirement" is not there. Now the tuxclocker nvidia plugin is correctly built (by modifying it with this hack) Now we put the nvidia so back, like we just installed it somewhere that has this library annnnd: Works! We don't need the nvidia-ml.so present, to have libnvidia.so link to it. We only need the header file at compile time, so that libnvidia.so has pointers to the code in that nvidia-ml.so, when it finds it. |
|
@pallaswept can you send PR in my forked repo on Github with edited meson so I can try to build RPM with patchelf script to test? |
Bro I would love to help but I don't know the first thing about meson :( But you can build it just as it is here, with the two changes from above: And then it will build the libnvidia.so without the nvidia-ml.so being present, and you can test after modifying the resulting libnvidia.so with patchelf, and it will work.....but that is not the way to resolve this issue., you should not consider doing this in your spec file. Even if your RPM includes patchelf as a runtime dependency so it can run it as a post-install script, that's a total hack. The way to fix this is to have the build toolchain (meson) build the lib and have the linker refer to nvidia-ml.so, then it has the same result as using patchelf, but without having to do that hack after the linker. It's obvious that meson has a way to link a library by finding it when it is installed, but what we need is to find the way to specify it to meson to link to it in the same way, without needing the file to be present during the build. |
Patchelf works, but it is the wrong way
This is the right way. |
|
As discussed in #70, the right way to deal with this is actually to use a wrapper library to call the nvidia library - and there's a very strong reason why, I've just discovered: How can we know what version of the driver to build against? There are 3 different closed source drivers and 2 different open source drivers from nvidia, all 5 of which will provide this library, and if we build against one of them, it will ONLY work if the user happens to be using that same driver. It's not a rube goldberg machine, it's a fix for a problem. |
|
@tujhen I was thinking.... If you wanted to try, perhaps the packman project would be a good option for you to host the package? They don't have the same OSI-approved restrictions as the OpenSUSE OBS, so you could build the driver, and hence the nvidia module, if you built it there. Although, then we still have the problem of mismatched drivers between the built module and the end-user's machine, so perhaps it's worth waiting for @Lurkki14 to implement the wrapper library to solve that problem. I know there's the workaround added to use flatpak, but that depends on flatpak, and not all systems will have that (eg mine doesn't - flatpaks use too much disk space so I removed it). But then, maybe we could retrieve the flatpak directly using http rather than flatpak install, using the OBS source services, and extract the .so from there, build against that, and then since we can't distribute it from opensuse, add a post-install script for the end-user to download and extract the same .so to the tuxclocker directories, and link to that, rather than the system-installed .so - to enable opensuse and fedora (or any RPM) builds? It's a bit of a hack to do it this way, a wrapper lib would definitely be cleaner, but it just might work... and hackish, but working, is better than not working at all, I think 😆 What do you think? |
hi, i was following the whole situation silently and i just wanted to tell you thanks for putting so much effort into this |
|
FYI I tested the new nvidia open cuda packages with this. That isn't released yet, it's beta/NFB at present, but that should give us a FOSS means to build this. I don't want to get too excited yet, but my initial tests have been promising. |
I understand why libraries, specifically I'm talking about the nvidia-ml.so lib, are required to run tuxclocker, but why are they needed just to build it? Why aren't the headers enough? I can see that meson is invoking the --no-undefined switch, so it's not going to work with any headers alone but needs the whole library, but WHY? Can this be changed? It's kinda the whole point of a shared library that you can build against the header and not need the actual library in your app.
I ask this because, we have a serious problem where we're unable to package tuxclocker, because it requires a source of the nvidia packages, and those aren't licensed to any public build services, only from nvidia themselves. This means you can't have any RPM-based distros building tuxclocker, with it the way it is now (because RPMs are built with no network connection, so you can't just go download the libs and install them, you have to have them packaged, and because of licensing, we can't). So fedora and suse are out, at the very least. It would be cool to fix that.
The text was updated successfully, but these errors were encountered: