Problem populating rootfs with a binary only recipe

Problem populating rootfs with a binary only recipe

[Kroll, Scott]

I have a recipe for NVIDIA display drivers written that simply fetches
the drivers, compiles a kernel module, and populates some
(unfortunately) binary only libraries. The RPMs created work just
fine, but when generating the root filesystem, an issue crops up due
to a "missing" dependency.

The drivers provide a libGL.so.325.15, which eventually becomes the
symlinked libGL.so (at least in the -dev package). However, one of the
required libraries in the NVIDIA package depends directly on libGL.so
instead of libGL.so.325.15, so when the root filesystem population is
to occur, the RPM refuses to install because no package provides
libGL.so.

Is there any way to handle this sort of situation? I'm not against
overriding the packaging of libGL.so since the target system is going
to only have a particular NVIDIA chipset inside of it, and since CUDA
is being used, the official NVIDIA drivers are required. I've looked
all over but it seems that no matter what the naked unversioned
libraries will never end up on the target. I was even considering
modifying the binary itself to depend on libGL.so.325.15 instead,
although I have a feeling that is probably not a good idea.

Re: Problem populating rootfs with a binary only recipe

[Stefan Seyfried]

Hi Scott,

Am 07.01.2014 20:17, schrieb Kroll, Scott:
> I have a recipe for NVIDIA display drivers written that simply fetches
> the drivers, compiles a kernel module, and populates some
> (unfortunately) binary only libraries. The RPMs created work just
> fine, but when generating the root filesystem, an issue crops up due
> to a "missing" dependency.
> 
> The drivers provide a libGL.so.325.15, which eventually becomes the
> symlinked libGL.so (at least in the -dev package). However, one of the
> required libraries in the NVIDIA package depends directly on libGL.so
> instead of libGL.so.325.15, so when the root filesystem population is
> to occur, the RPM refuses to install because no package provides
> libGL.so.

Maybe putting the libGL.so into the main package might already be enough?

You can achieve that by using

FILES_${PN}-dev = ""

(but then -dev is completely empty).

Another thing worth trying might be

PROVIDES += "libGL.so"

Good luck :-)

	Stefan
-- 
Stefan Seyfried
Linux Consultant & Developer -- GPG Key: 0x731B665B

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537