Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

profile: Added debian library path #3996

Open
wants to merge 1 commit into
base: testing
Choose a base branch
from

Conversation

rizalmart
Copy link
Contributor

Newly built debian-based puppy unable to detect library installed at /usr/lib/-linux-gnu. This will fix the problem

Newly built debian-based puppy unable to detect library installed at /usr/lib/<arch>-linux-gnu. This will fix the problem
@techrockedge
Copy link

I vote to merge this commit! I have had to manually do this exact export manually several times recently and this does the fix.

@dimkr
Copy link
Contributor

dimkr commented Feb 13, 2024

This is a "dirty" solution for a problem that doesn't exist. The clean solution is to use the upstream distro's /etc/ld.so.conf{,.d} instead of forcing Puppy's one, and use the upstream distro's file system layout (usrmerge or not).

dpup uses Debian's library path and the LD_LIBRARY_PATH value set in /etc/profile doesn't do anything really. 3builddistro doesn't force Puppy's bad ld.so.conf if USR_SYMLINKS=yes, otherwise many applications you install are broken and multilib doesn't work (it works thanks to files in /etc/ld.so.conf.d).

In dpup, /lib64/ld-linux-x86-64.so.2 --help shows that the search path used is a combination of what /etc/ld.so.conf (plus /etc/ld.so.conf.d/* - sourced by ld.so.conf) says plus what LD_LIBRARY_PATH says (/lib, /usr/lib, etc' are meaningless because libraries are under the x86_64-linux-gnu subdirectory).

@techrockedge
Copy link

The clean solution is to use the upstream distro's /etc/ld.so.conf{,.d} instead of forcing Puppy's one, and use the upstream distro's file system layout (usrmerge or not).
That is the best solution. I have manually created files in /etc/ld.so.conf{,.d} to test this on F96-CE when compiling certain packages.

Though I have also manually added the lib path to LD_LIBRARY_PATH in /etc/profile on Fossapup64's for a quick fix.

@peabee
Copy link
Contributor

peabee commented Feb 14, 2024

@dimkr
Copy link
Contributor

dimkr commented Feb 14, 2024

Puppy's ld.so.conf has no advantage over Slackware's ld.so.conf, using Slackware's one can only improve compatibility with Slackware, and maybe it can reduce the number of directories the loader needs to check when you run an executable.

I'd delete Puppy's ld.so.conf and remove this condition (use the if flow in all builds and drop the else):

if [ "$USR_SYMLINKS" = "yes" ];then

@peabee
Copy link
Contributor

peabee commented Feb 14, 2024

Slackware does not have ld.so.conf in glibc

@dimkr
Copy link
Contributor

dimkr commented Feb 14, 2024

Maybe not in glibc, maybe somewhere else 🤷🏿

And if it doesn't have on at all (just uses the loader's default search path), that's also a valid option for a Slackware-based Puppy.

@peabee
Copy link
Contributor

peabee commented Feb 14, 2024

Nowhere else in any of the packages currently included in the build.........

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants