Lurkki14 / tuxclocker

Qt overclocking tool for GNU/Linux
GNU General Public License v3.0
776 stars 31 forks source link

FR: Remove requirement for libraries to be installed, just to build the application #65

Open pallaswept opened 1 year ago

pallaswept commented 1 year ago

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.

Kyr4l commented 8 months ago

@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

pallaswept commented 2 months ago

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.

https://developer.nvidia.com/blog/nvidia-transitions-fully-towards-open-source-gpu-kernel-modules/#using_package_managers_with_the_cuda_metapackage