What does the humongous /usr/lib/libLLVM.so.3 do?

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#31 Post by technosaurus »

Uggg. Llvm is so frustrating. It has no simple way of removing support for architectures that it supports, but are completely useless for 99% of people. For example most x86_64 linux users don't need to build Qualcomm's hexagon or Microsoft windows binaries much less jit build them. On top of that it is written in c++ vs c, so compilers have a more difficult time eliminating unused cruft - thus the gratuitous amount of relatively large binaries. They tried to mitigate this to some extent by optionally combining most of the little static libraries into a single shared library, but not all binaries or dependent projects can take advantage of the shared library version of llvm either due to lack of maintenance (internal binaries) or for performance reasons (Mesa) It _could_ be made smaller and still function by modifying the build process to exclude unnecessary *.a libs from the *.so and even further by excluding some *.o files from the *.o files. IIRC ttuuxxx did something similar for an older version of Firefox, but most people won't have the skill set to do it and of those that do, most won't have the patience. I lack the patience to do anything other than a 1 time hack job like my mostly static build of midori, but the sources are poorly organized/named (not as bad as Mozilla, but bad) so it's difficult to pinpoint which objects and libraries can be omitted and, since it is c++, more difficult to find unnecessary references to them in the sources.

TLDR it's possible to make it smaller but not easy... a good GSOC project.

As for Mesa, the primary user, it can be built without llvm and then the drivers that absolutely need llvm can be built against a static PIC build of llvm (so only those drivers absorb the cost, but only the minimum cost); however this is a complicated arrangement that most automated build systems can't support.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#32 Post by musher0 »

Ok... :lol:

technosaurus wrote:
> "TLDR it's possible to make it smaller but not easy... a good GSOC project."
Translation: :)
"Too long didn't read, it's possible... Google Summer of Code project."
I was lucky to have the search gods smile on me tonight! :)

~~~~~~~

FYI and everyone's, figosdev, on
http://softwarefreedom.jcink.net/index. ... &#entry116
8th post down, wrote:
> "the latest version of mkfigos deletes llvm.
> the one effect ive noticed is that webkit doesnt work without it.
> thats a pretty big thing,"

BFN.
Last edited by musher0 on Sun 29 Jul 2018, 08:17, edited 2 times in total.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#33 Post by BarryK »

The latest EasyOS, 0.9.5, doesn't have llvm.

This distro is built with packages compiled from source in 'oe-qky-src', my fork of OpenEmbedded.

The only thing that I am missing out on is support for some video hardware, affecting a very small minority of users I think.

For the record:

https://github.com/bkauler/oe-qky-src
[url]https://bkhome.org/news/[/url]

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#34 Post by musher0 »

Ah, Barry, you were always the visionary! ;)

Thanks for this info!

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#35 Post by Marv »

Morning musher0,
A quiet Sunday morning so just for hoots over coffee, working on my fairly modified upupbb 18.05 +10, I removed the llvm libs and samba (a pretty thorough but probably not perfect manual scrub) and resquashed the main SFS. I am an all intel shop at this point, four i5s, two or three core 2 duos, and two Bay Trail desktops. Stopped using samba partly because of throughput and reliability issues with large files and partly just because it made me nervous. I just keep a USB3 HDD or two by my main computer and back up and transfer using them. It's fast and bulletproof and the extra walking doesn't hurt me. The space saved on the install doesn't matter to me at this time since my current hardware is all capable enough but I was just curious.

Things that I've tried and work here on this stripped version of upupbb:
My integrated pcmanfm and trashcan, glxgears, pmusic, gnome-mplayer, Slimjet 18.0.5.0 run-as-spot from SFS, Sylpheed, QtWebBrowser 3.8.5 portable install, gnumeric (simple financial spreadsheet), abiword (create, format, and print a testpage), networked printers (one HP4500 all-in-one and a Brother 2170 laserprinter) The Brother was already installed. I turned the firewall off and installed the usual HPlite. Both printers were autodetected by CUPS and the HP installed and printed a test page perfectly.

Things that fail: Haven't run into one yet. Certainly video driver dependent so I'm probably an outlier here with the all intel and pretty simple use but... I'll use this pup for a while and see what does break. I like it for it's non-gvfs nature.

Just fooling around :D

Update: A few days of steady use, including a kernel swap and the usual system tests of that, and I haven't found anything that is broken on this platform and pup by this change. I found my stripper script so the samba removal is complete and checked per the .packages list.
Last edited by Marv on Tue 31 Jul 2018, 12:33, edited 1 time in total.
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#36 Post by musher0 »

HI Marv.

I'd say we need more fooling around like that !!!

Many thanks for the report!!

Have a great day!
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
Duprate
Posts: 6
Joined: Wed 04 May 2016, 22:50
Location: Brazil

Xenial Pup 64 small

#37 Post by Duprate »

Hello! I am using Xenial Pup 7.5 with the following modifications:
Removed:
Palemoon;
Samba;
libLLVM-4.0.so.1 in usr / lib;
kms_swrast_dri.so,
nouveau_dri.so,
nouveau_vieux_dri.so,
r200_dri.so,
r300_dri.so,
r600_dri.so,
radeon_dri.so,
radeonsi_dri.so,
swrast_dri.so,
virtio_gpu_dri.so,
vmwgfx_dri.so, all in usr / lib / dri.

puppy_xenialpup64_7.5.sfs got 187 Mb. The kernel is 4.14.63, extracted from q.sfs of the latest version of Barry Kauler's Quirky Xerus 64 8.6, which was very well done with the following patches:
CPU vulnerabilites: Mitigation:
l1tf PTE inversion mitigation
meltdown PTI mitigation
spec_store_bipass * vulnerable
specter_v1 _user pointer sanitization
spectre_v2 full generic retpoline


On my PC (Intel (R) Pentium (R) CPU G3260 @ 3.30GHz), it is working very well. On an Ultra PC Ultra Liva X2 (Celeron Dual Core N3060) very well.

I do not recommend this for users with little knowledge of their PC and each computer has its specific configuration.
:D

User avatar
Duprate
Posts: 6
Joined: Wed 04 May 2016, 22:50
Location: Brazil

Warning!

#38 Post by Duprate »

Hello! Do not do the above procedure on Bionicpup 64 or the programs that require OpenGL will not work. This was just a temporary test done with Xenialpup 64!

Post Reply