jzakrzewski
commented
4 years ago As far as I can tell this error comes purely from configure. I had it in other projects also and always ask myself "why the heck does it care about runtime". I have no idea if that could be remedied.
I am not proposing to move towards cmake or meson/ninja per se either, even though I think both are better,
Just to let you know - CMake build actually is there. I don't know if I would build for LFS with it but I do build local versions for various projects.
bagder
Hello curl developers and maintainers,
I will soon describe a bit of the issue at hand, but let me just copy/paste what I did on my linux system (tarball I use for curl at the time of writing this issue is:
http://curl.haxx.se/download/curl-7.72.0.tar.bz2
)
So, cutting this off here, that was the error:
configure: error: one or more libs available at link-time are not available run-time. Libs used at link-time: -lnghttp2 -lidn2 -lpsl -lssl -lcrypto -lssl -lcrypto -lldap -llber -lzstd -lbrotlidec -lz
I am compiling everything from source on linux here, using mostly the LFS/BLFs approach. So my system is quite a mess at times. :) In particular older libraries may still exist at /usr/lib/ usually.
The above "one or more libs are not available" message is quite useless, though. Because I have to ask ... WHICH libraries exactly? What is the offender? To me it is not clear, and the configure error is a bit unusual too. Isn't it normally the case that configure tells you what the problem is? Such as "nghttp2 is missing" or something like that? Instead I get a dump shown like this:
-lnghttp2 -lidn2 -lpsl -lssl -lcrypto -lssl -lcrypto -lldap -llber -lzstd -lbrotlidec -lz
So, 12 different libaries I guess, in perhaps 9 different programs or so. All of these I already have registered locally and can compile or re-compile, but this configure line is unclear to me right now. And I think it is not a good idea to just dump it on the commandline and let the user find out, or go through config.log. The latter is more than 4000 lines long and only a few lines contain what is helpful to the issue at hand.
Partially this is due to GNU autoconfigure I guess. I am not proposing to move towards cmake or meson/ninja per se either, even though I think both are better, but transition periods can often lead to other problems, so that is not a trivial task. But the current error dump is quite useless too. Nobody wants to go through the macro-stuff in configure (the KDE project moved to cmake largely to avoid this macro-stuff, understandably so), but if perhaps in the next months or years someone finds time to reconsider the error messages, it would be greatly appreciated. Specifically I think a simple change may be to just show more information here. Like, rather than list all these 12 libraries as a dump, to specifically say which one is the troublemaker - then I can concentrate on that part. Right now I am guessing ... and I already guessed wrong, since the error message was repeated. And it's still not any more helpful. :\
I was able to compile curl just fine before, so I think this is something wrong in the current set of programs I use - but without being told where the error is, I am operating mostly in a black box, which is a bit annoying.
Edit: Actually, config.log showed at the least one error:
However had, I still decided to file this issue request, because I think it would be better to not show a dump per se (only), and instead also report something like either that error message, or alternatively an additional line. And perhaps other users find it, and they may also have encountered the same problem, so it may be helpful to these - but please feel free to close the issue here at any moment in time; many projects like to keep the bugtracker clean, which I can understand.