| Summary: | Why is libcuda.so.1 filtered from provides/requires? | ||
|---|---|---|---|
| Product: | Fedora | Reporter: | Orion Poplawski <orion> |
| Component: | xorg-x11-drv-nvidia | Assignee: | Nicolas Chauvet <kwizart> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | nucleo, s.adam |
| Priority: | P5 | ||
| Version: | 16 | ||
| Hardware: | All | ||
| OS: | GNU/Linux | ||
| namespace: | |||
|
Description
Orion Poplawski
2011-12-10 00:35:26 CET
We previously have experienced the case where several libGL implementation was used in the dependency resolution. This was mostly seen on x86_64 system where the 32bit nvidia-libGL was preferred over the mesa-libGL version, even if the users wasn't using any proprietary graphics drivers. The solution is to only have one version of libGL "provided" from the whole fedora collection of avoid such mismatch. By extension, I have discovered that others libraries provided by the driver could lead to "Conflict" because either they are provided by different nvidia series (current, 173xx,96xx) or they could lead to mismatch if we introduce latest/beta/current branches. So I have disabled them also, given that others packages shouldn't link to them anyway. Still I see it very annoying problem if we re-introduce a libcuda.so.1 provide that the right driver got picked if we 'rpmfusion' or even any others downstream integrator introduce another latest/current/beta branch of the nvidia driver. Another problem is that if cuda enabled applications got packaged in rpmfusion and they can work with and without a cuda capable GPU. (by providing the cuda part as a separate loadable module), then it will be hard not to bring the nvidia driver in the dependency computation if such application is linked to libcuda.so.1. The problem is that currently installing the nvidia driver mean that that driver will have to be used. So I don't know if it's expected to link to this library in cuda enabled application. But If it's only needed by the cuda compiler I would suggest to filter it also. But I'm open to arguments. Also I'm not even comfortable to introduce multiple version of the nvidia driver already (that's why we don't have the LTS nvidia driver in F-16 where it should work). Had not thought about the issue of multiple driver packages. In cudatoolkit 4.1 it is libcuinj.so that needs libcuda.so.1:
# ldd libcuinj.so
linux-gate.so.1 => (0x0060b000)
libdl.so.2 => /lib/libdl.so.2 (0x00efa000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00110000)
libcuda.so.1 => not found
libcudart.so.4 => /usr/lib/cuda/lib/libcudart.so.4 (0x00f5e000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00497000)
libm.so.6 => /lib/libm.so.6 (0x0061d000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00ac5000)
libc.so.6 => /lib/libc.so.6 (0x0012b000)
/lib/ld-linux.so.2 (0x42002000)
librt.so.1 => /lib/librt.so.1 (0x0040e000)
which does not appear to used by anything else in cudatoolkit or in the CUDA SDK, so perhaps it is safe to remove. I compiled an example, and it doesn't appear to require libcuda.so.1.
Just some more info for the record. The sdk deviceQuery example that uses cuDeviceGetAttribute needs to link to libcuda.so. That is the only example that does. I've removed the filter for libcuda.so.1 with 295.09 beta (Will be provided in F-16 once stable). Thx for your report. |