What does the LLVM library do and how badly do we need it?

[rcrsn51]

So the DRI has to stay?

For you personally, or in general?

Here are the choices:

1. Completely remove a function, but have the option to restore it if desired.

2. Keep the function but delete some of its dependencies, knowing that it might have catastrophic effects on some users.

[Smithy]

Well generally really, maybe 0.01% of graphics card users who would probably never join the forum to scream blue murder anyways.

Or are you saying that all those old ATI and Radeons would be not accelerated if llvm and dri are removed?
Oh yeah just had a look, it says Mesa 3.0 17.22, so it would screw things up to remove DRI folder I presume.

[dancytron]

Does that mean we will lose the comforting glx gears (the grinding mills of God in full screen)

You don't have to lose anything. You just need a way to make accelerated video an optional feature without breaking stuff.

As a test, I removed the libLLVM* file from my the Radky Puppy Stretch using editSFS.

On my computer, with Intel G30 video, it seems to work fine without it. GLXgears continued to work.

The test, would be to find a computer where the video card needs LLVM and copy the libLLVM file to the zdrv or adrv files and see if it works then. If so, a ydrv or fdrv sfs could be made with has the libLLVM file along with the drivers of the video cards that need it.

I am pretty sure this would work, but I don't have a way to test it. Later, I might prepare an ISO and post it to see if others will test it.

[dancytron]

This test was prepared by removing the libLLVM* file from the main sfs file and placing it in ydrv_stretch_7.5.sfs.

1. To test, make a frugal install from Radky's Stretch Puppy 7.5. Version RC-3
http://murga-linux.com/puppy/viewtopic. ... 4&t=112125 Use stretch-7.5_k4.9.101.iso

2. Ensure that it boots to X correctly and runs glxgears.

3. Rename the puppy_stretch_7.5.sfs file to something like puppy_stretch_7.5.sfs.old.

4. Download and copy the 2 files (puppy_stretch_7.5.sfs and ydrv_stretch_7.5.sfs to the frugal install directory.

5. Rename the ydrv_stretch_7.5.sfs to something like ydrv_stretch_7.5.sfs.test.

6. Attempt to boot the install. Choose the first option on the opening screen. Assuming it boots to x, open a terminal and run "glxgears". If glxgears works, then your display driver does not need libLLVM* and you can't really help us with the rest of test.

7. If it failed to boot or booted and failed to run glxgears, then rename ydrv_stretch_7.5.sfs.test back to ydrv_stretch_7.5.sfs.

8. Attempt to boot into the install. Choose the first option on the opening screen. Assuming it boots to x, open a terminal and run "glxgears".

If glxgears works, then we have successfully shown that for display drivers that require libLLVM* will work with libLLVM in the ydrv and for display drivers that don't require libLLVM, the ydrv can be deleted to save space and memory. Perhaps the display drivers that depend on libLLVM* could also be identified and moved to the ydrv sfs file as well.

ydrv

https://dl.dropboxusercontent.com/s/oij ... 5.sfs?dl=0

Main puppy sfs file

https://dl.dropboxusercontent.com/s/37e ... 5.sfs?dl=0

edit: per Kirk's post above "LLVM is required for Gallium3D, r300, and radeonsi Mesa drivers." So if you have one of these cards, your testing would be particularly valuable.

edit: numbered steps for easier reading

edit: 7-2-18 I am assuming that no else will want these so I am deleting them from my dropbox.

[musher0]

Very interesting research and test, Dancytron!

I'm still a bit confused, though.
-- Could you kindly provide a list through tree or ls of what's in the ?drv.sfs archive that
contains the LLVM lib and whatever you have associated with it? This list could serve
as reference for other Pups and/or remasterisations. Thanks.

A few other thoughts:
-- I'm not sure it is a good idea to occupy a ?drv.sfs with this. Some Pups, like peebee's
BionicPup, come with all ?drv.sfs positions already occupied.

One thing is for sure if we want to make it optional is : it cannot be in the zdrv.
How about it would have its own sfs? Or is a zzdrv*.sfs possible ?

-- I did the test suggested by Sailor E. and it turns out that on xenialPup-706,
driver /usr/lib/gio/modules/libgiolibproxy.so needs libproxy.so.1, and guess what?, are
you comfortably seated?, this libproxy needs the mono library!!! (which was "not
found", hehehe)

Not sure what the libgiolibproxy.so is needed for, but maybe we'll have to embark at
least some of the mono library along in that new libLLVM sfs as well.

-- Can we make it so this new sfs is loaded automatically? Some sort of self-detection?
Like on 1st run, we put the usual basic sfs's in the Pup folder. Then if the the LLvm or
mono libs are needed a message would pop up in the boot console saying:
"Stopping load at this point. Please add the LLVM-blabla.sfs in your Pup folder
because of such-and-such". Am I making any sense with this?

Again, most sincere thanks for your very helpful test report.

BFN.

[dancytron]

Very interesting research and test, Dancytron!

I'm still a bit confused, though.
-- Could you kindly provide a list through tree or ls of what's in the ?drv.sfs archive that
contains the LLVM lib and whatever you have associated with it? This list could serve
as reference for other Pups and/or remasterisations. Thanks.

A few other thoughts:
-- I'm not sure it is a good idea to occupy a ?drv.sfs with this. Some Pups, like peebee's
BionicPup, come with all ?drv.sfs positions already occupied.

One thing is for sure if we want to make it optional is : it cannot be in the zdrv.
How about it would have its own sfs? Or is a zzdrv*.sfs possible ?

-- I did the test suggested by Sailor E. and it turns out that on xenialPup-706,
driver /usr/lib/gio/modules/libgiolibproxy.so needs libproxy.so.1, and guess what?, are
you comfortably seated?, this libproxy needs the mono library!!! (which was "not
found", hehehe)

Not sure what the libgiolibproxy.so is needed for, but maybe we'll have to embark at
least some of the mono library along in that new libLLVM sfs as well.

-- Can we make it so this new sfs is loaded automatically? Some sort of self-detection?
Like on 1st run, we put the usual basic sfs's in the Pup folder. Then if the the LLvm or
mono libs are needed a message would pop up in the boot console saying:
"Stopping load at this point. Please add the LLVM-blabla.sfs in your Pup folder
because of such-and-such". Am I making any sense with this?

Again, most sincere thanks for your very helpful test report.

BFN.

The ydrv contains one file. /usr/lib/libLLVM-3.9.so.1

The main sfs file is exactly the same as the original except /usr/lib/libLLVM-3.9.so.1 has been deleted.

The rest of your comments are beyond the scope of this simple test. The goal is to see if the libLLVM* can be taken out of the main sfs file and loaded by itself only for those people who need it by using the built in *drv sfs function.

We need someone who actually needs the libLLVM* file to test it.

[musher0]

Thanks dancytron for the details.
~~~~~~~
@all: I submit this in the hope that this may help narrowing down what we need libLLVM
for and on what Pup.

xenialpup-7.0.6
Start: mercredi 27 juin 2018, 23:46:25 (UTC-0400)
* Checking system dirs: /bin /usr/libexec /sbin /usr/bin /usr/sbin /usr/games /usr/local/bin
==================================================
* Checking system dirs: /lib /usr/lib /usr/local/lib

/usr/lib/dri/kms_swrast_dri.so
libLLVM-4.0.so.1 => not found
/usr/lib/dri/nouveau_dri.so
libLLVM-4.0.so.1 => not found
/usr/lib/dri/r300_dri.so
libLLVM-4.0.so.1 => not found
/usr/lib/dri/r600_dri.so
libLLVM-4.0.so.1 => not found
/usr/lib/dri/radeonsi_dri.so
libLLVM-4.0.so.1 => not found
/usr/lib/dri/swrast_dri.so
libLLVM-4.0.so.1 => not found
/usr/lib/dri/virtio_gpu_dri.so
libLLVM-4.0.so.1 => not found
/usr/lib/dri/vmwgfx_dri.so
libLLVM-4.0.so.1 => not found
/usr/lib/libxatracker.so.2.3.0
libLLVM-4.0.so.1 => not found
/usr/lib/vdpau/libvdpau_nouveau.so.1.0.0
libLLVM-4.0.so.1 => not found
/usr/lib/vdpau/libvdpau_r300.so.1.0.0
libLLVM-4.0.so.1 => not found
/usr/lib/vdpau/libvdpau_r600.so.1.0.0
libLLVM-4.0.so.1 => not found
/usr/lib/vdpau/libvdpau_radeonsi.so.1.0.0
libLLVM-4.0.so.1 => not found
/usr/lib/xorg/modules/drivers/vmware_drv.so
libLLVM-4.0.so.1 => not found

BFN.

[musher0]

Hi.

If I may bother you with a bit of history, the libLLVM matter was originally brought
up on petihar 's Triton-5.7.3 thread four years ago:
http://www.murga-linux.com/puppy/viewto ... ost#772186

About a year later, Argolance decided to remove it from his ToOpPy Pup:
http://www.murga-linux.com/puppy/viewto ... ost#851134

and ASRI, to remove it from his educational Pup, but offer it as an option.
http://www.murga-linux.com/puppy/viewto ... ost#844928

~~~~~~~~~

Following dancytron's experiment above, I did remove it from the remastered xenial
that I'm working on and made it into an ydrv, with all video *dri" files. Shaves ~ 22
Mg's off the main puppy sfs.

Re-reading the posts of the French devs on the subject, I don't think we need to
make it into an ydrv. Although handy, since all *drv*.sfs files are loaded automa-
tically at boot, this LLVM archive could be named something else and loaded
through sfs_load.

BFN.

[nosystemdthanks]

although its more relevant to other systems (not only) ive deleted libllvm-4.0.so from the computer i have running my distro in ram (there is no drive, it booted from usb.)

i would like to remove llvm from the iso file i used to boot this and try running that as well; its very possible that deleting it from the running version will not change much; as anything still running it wont care that its deleted until it tries to load it again. for example, i havent closed the web browser yet. but i am interested in what happens without the file.