The partition for /usr is getting a little short on space.

If a Debian/Devuan developer is working with one or more packages, the instructions about:

apt-get build-dep whatever-package

are not a problem.  They are going to be using those packages over and over again, so there is a need for them to be on the system.

For someone like me, trying to track down a bug; they are a problem.  I have to install a bunch of packages I don't really want on the final system.  Which means trying to remember what to delete/purge later on.

Is there a jail/container/vm solution to this?

In the past and tonight, I am running

DEB_BUILD_OPTIONS=nostrip,noopt dpkg-buildpackage -rfakeroot -uc -us

(Sometimes it is "nostrip noopt", they both seem to work.)  But, maybe my problem was I didn't have the build-depends correct?  So, I  did

apt-get build-depends ocl-icd

and it installed I believe 3 packages which weren't here before.  Arrgh!  :-)  Okay, I've got a contaminated "source tree", so I made a new directory and re-downloaded the ocl-icd source.

Running the dpkg-buildpackage command (with the DEB...) takes longer than earlier tonight (with the contaminated source tree), and I again get the error: dump_vendor_icd not found.

The clinfo program needs that function to do anything (first libopencl function it calls).  From reading various  OpenCL related things, it seems most programs call it at the beginning.  How can it not be present?

There is no source code (in C or C++) in the source package.  What it looks like is happening to me, is that the C source is calculated from something in Ruby, for whatever purpose the Makefile presents.  Or dpkg-buildpackage.  How the heck do I track down why this function is missing in dynamically created source code?  I would much rather work in FORTRAN-IV or FORTRAN-77.  :-)

If want to compare
%command%

with
DRI_PRIME=1 %command%

If command is glxinfo and I go looking for the provider, the first version reports the APU, and the second version reports the RX-550.  So, I am guessing that the motherboard graphics and APU are the default.  If command is glxgears, I get about 20% higher frame rate with the RX-550.  The monitor is connected to the motherboard VGA connector.

I am guessing that this means that amdgpu is able to work with both the APU and the GPU.  I have never read anything about having to put DRI_PRIME=1 in anything having to do with BOINC jobs, so I don't know if that is a solution or not.  There is still the problem that clinfo hangs, and never tells you anything.

I am just using Mesa3D as a provider of OpenCL.  I had run into some problem quite a while ago about OpenCL (from Mesa?) co-existing with POCL on the same machine.  I could try purging POCL if that is present, I hadn't remembered to look.

I had been running it with both the radeon and amdgpu modules, and I think the radeon was doing the APU/motherboard side, and amdgpu was doing the RX-550.

I tried getting it to just use the amdgpu module.  I tried blacklisting and I tried kernel command line options.  It runs, it doesn't do GPU work any more for BOINC, and clinfo doesn't work.  If you run clinfo at a command prompt, it hangs.  Running clinfo under strace didn't seem to point to anything.

I downloaded the source to clinfo, and changed all print operations (to stdout) to being fprintf to stderr.  This should mean all prints are unbuffered.  Well, it hangs on the very first call to the OpenCL library.  What I think this call is supposed to do, is just to return how many platforms are present, so that it can loop over the platforms present.

I was doing this in emacs with the gdb interface.  And if you try to singlestep into that library call, it just hangs.  I believe I can get control of the process from within emacs.  So, probably an endless loop?

Debian doesn't supply that library with DBG symbols (and so it isn't surprising that Devuan doesn't either).  So, I downloaded the source, and did

DEB_BUILD_OPTIONS="nostrip noopt debug" dpkg-buildpackage -b-uc-us

And the first time, dpkg-buildpackage said I didn't have all the pre-requisties, so I downloaded more stuff.

Now the compile bombs out on an error.  It cannot find dump_vendor_icd().

I am in the top directory of this package when running dpkg-buildpackage.  I would think that function would be a few subdirectories down, but running fgrep that function is defined in a file in that top directory.  I didn't look to see if it is also defined elsewhere.

Or, maybe I am missing something on how to compile the package with debug symbols.  So, I am describing what I think I did.  And changing consoles with a KVM switch to type stuff.