Guys do not do this, it’s gonna cause a mess further down the line.
“The problem with creating these links is that they aren’t managed in any meaningful way. If that library is removed, the link becomes broken. If the library is upgraded, it may encounter an error because of the link that it doesn’t expect to be there.”
It is most commonly used to get an older archived program to load a newer library without recompiling the older program, so none of those objections apply, or are serious, because a dangling symlink (when the os moves to a newer library version) just keeps the one program from loading, reproducing (in a way) the error the symlink was introduced to fix.
The user can typically fix the same exact problem in that case. Honestly, those objections read like that meme, “No, not that way!”
Guys do not do this, it’s gonna cause a mess further down the line.
“The problem with creating these links is that they aren’t managed in any meaningful way. If that library is removed, the link becomes broken. If the library is upgraded, it may encounter an error because of the link that it doesn’t expect to be there.”
https://askubuntu.com/questions/461706/is-it-okay-or-not-to-symlink-libraries-to-overcome-cannot-open-shared-object
It is most commonly used to get an older archived program to load a newer library without recompiling the older program, so none of those objections apply, or are serious, because a dangling symlink (when the os moves to a newer library version) just keeps the one program from loading, reproducing (in a way) the error the symlink was introduced to fix.
The user can typically fix the same exact problem in that case. Honestly, those objections read like that meme, “No, not that way!”
I think they meant creating the symlink in a local directory and using LD_PRELOAD