Page 3 of 3

Re: [4.1.1] libSPIRV.so: cannot open shared object file: No

Posted: Tue May 14, 2019 4:45 am
by Graf Zahl
Chris wrote:but it's apparent that custom building all your packages really didn't give you that much in terms of performance and resource saving, it was easy to break things with bad build settings, and building packages took way more time than just grabbing binaries.
So we agree about the core issue here. But this same issue will always be present if some library gets used both by the system and by other applications and there's conflicts that cannot be resolved easily. This is why I consider it such a problem if applications depend on what the system provides and the system depends on the single instance of said library. It may be too new if the application code is too old or it may be too old if the system hasn't been built against the latest version. And here's where separation of modules would help.

I only need to point to the 32 bit performance issue with libsndfile shortly after the GPL transition. This was because the official build was miscompiled. Now, if that had been used by the system without being able to replace easily it'd have been a major problem for GZDoom.

Re: [4.1.1] libSPIRV.so: cannot open shared object file: No

Posted: Tue May 14, 2019 6:25 am
by Rachael
Having used Gentoo, myself, as well as pretty much any other distribution - I prefer pretty much any other distribution. Even Slackware is better than Gentoo, although I will admit Emerge is better with picking up the dependencies than Slackware's package manager is.

The only thing I like about Gentoo is its extremely minimalistic approach, which is great for cloud services (such as Linode). It basically runs with a lot less bloat than any other system. That's pretty much its only advantage.

Re: [4.1.1] libSPIRV.so: cannot open shared object file: No

Posted: Sat May 25, 2019 8:35 am
by _mental_
Internal libraries were forced to be static in 6fafa29.