You are not logged in.
Hello,
today I upgraded packages, including libidn2. I assume before the update it provided the file '/usr/lib/libidn2.so.0'. After the update this changed to '/usr/lib/libidn2.so.4'. When I now try to compile a large software project I'm working on, linking dependencies (that we also compile from source) failed with the error that the libidn2.so.0 cannot be found. I tried downgrading the package from cache, which broke my pacman (it needed the .so.4 file to run). I hoped it would at least solve my compile issue. However, a different dependency then complained that it was missing the .so.4 file....
As a solution, I manually created a symlink for the .so.4 file and reinstalled libidn2 with the --force flag to get rid of the manual symlink. As of now, my linux is fine but I still haven't solved the compile issue. As I understand it, users should never create these symlinks in /usr/lib/. However, I often had the problem that various programs were missing certain .so.* files even though the libraries were installed. So I'm wondering what the suggested way to solve these issues is and how I could fix my issue at hand.
Also, as I don't know much about dynamic linking, c++ and all that: If I manually create the symlink, will the program during linking link to a precalculated adress or does it still search 'where is function with signature X in this library'?
Offline
See https://wiki.archlinux.org/index.php/Sy … nsupported
The only reason something would be trying to use the old library is if it hasn't been recompiled against the new library. Everything affected in the official repositories has been rebuilt, so whatever is causing your problem is most likely a foreign package which is your responsibility to maintain.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
When I now try to compile a large software project I'm working on, linking dependencies (that we also compile from source) failed with the error that the libidn2.so.0 cannot be found.
This doesn't sound right. Did you try deleting any build cache and rebuilding the software from scratch? Other than this sort of cache, there should be no reason any build system would be searching for the old version in the first place.
If it is trying to link an already-built dependency, then the dependency probably needs to be rebuilt. Consider that as a cache for your final product.
I tried downgrading the package from cache, which broke my pacman (it needed the .so.4 file to run). I hoped it would at least solve my compile issue. However, a different dependency then complained that it was missing the .so.4 file....
It probably depends both on libidn2 and on software that in turn depends on libidn2.
In general, this is the other reason you shouldn't try to have both. Because if some parts of the application are linked to .so.4 and some parts are linked to .so.0, then you end up having both sets of symbols fighting over which version is the real version. And ultimately, you're only using one version (whether the first-loaded version or the last-loaded version wins, is OS-dependent).
Static compilation or versioned symbols can solve the case of coexisting libraries, but this still requires you to build your own old version of the library with versioned symbols (or staticlibs). There's generally very little reason to do that as a clean rebuild should link to the new version instead.
But again, you may have caching issues which cause the build to fail.
Last edited by eschwartz (2019-01-17 00:12:22)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Running
make clean
and then a fresh
make
just causes make (that we also compile ourselves) to complain about missing libidn2.so.0
The hotfix of creating the .so.0 symlink myself seems to work for now, maybe the crash in my software is my fault after all. The link WorMzy provided helped a lot (and explained why one shouldn't do what I'm doing ). When I want to fix it for good I'll probably try setting up the project again (then it would get linked against the new library ) but this would cost me roughly a day just for downloading and compiling so I'd rather work with the bandaid fix for now.
Thanks for the help.
Edit: Managed to resolve my issue, thanks.
Last edited by Ratslayer (2019-01-18 15:40:15)
Offline