Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
./configure'ing with built but not installed SSL breaks some features #3006
Maybe that's something I actually do wrong and it's not a legit problem, but still.
I did this
I'm trying to build libcurl as a shared library that depends on prebuilt libssl that differs from installed in the system.
I experienced the following
There are about 8 test that fail in a similar fashion and disable some features, although for me disabling
The issue here, if I'm seeing it right, is that it can't load .so's that are not in
I'm not really sure if
My dirty fix is to just put prebuilt libraries in
I'm not exactly sure what you're asking or saying. configure does checks of libraries, most of them by linking and some of them by actually running compiled code. Link-time is different than run-time. The configure script tries to make sure that what is found at its link-time checks is also used for its run-time checks.
Post configure, or post make even, when you run curl or use libcurl, making sure that the correct 3rd party libraries is used is your concern and you need to make sure that your ld.so links with the correct libs with LD_LIBRARY_PATH, editing /etc/ld.so.conf or similar.
Post-configure is not an issue, it's my concern indeed.
It does if you have no SSL of similar version installed system-wide.
A check I've been burnt by is a
But I think all of those are affected:
It all happens with an error like this:
It CAN link test binary, but CAN'T run it.
That's not what typically happens and looks like something is broken for you. It looks like it fails to set the correct path to load the library from and sure, then everything breaks from that point on.
Well yeah, that's what I'm saying right from the start.
It links its tests to 'correct' SSL version, but tries to run in w/o including the path from
I'm not really savvy in linux builds, autotools and all that magic, but that behavior seems wrong for me.
That's not true. The configure.ac script uses the
As you can see here, that macro sets
So, I understand that something breaks when you run configure but your analysis is directed to the wrong thing - the problem is not the lack of using the variable, the problem is either that it passes on the wrong directory or that you've found a case where it doesn't use this macro to execute the check. Also remember that countless of people already run and use this configure script without these problems.
If you would attach your config.log file, we might be able to help you narrow this search faster.
We don't support "not installed" OpenSSL, you have to actually install it to some location first and then point configure to that location. However it sounds like you may have OpenSSL installed just independent and in a path separate from the packaged one. In other words there's actually a /home/user/lib with the import library for libssl.so. Try setting the rpath before invoking configure, for example assume I installed OpenSSL to /usr/local/ssl and the imports are in /usr/local/ssl/lib then:
LDFLAGS="-Wl,-rpath,/usr/local/ssl" ./configure --with-ssl=/usr/local/ssl ...
As I said, I'm really bad at Autotools, so pardon me for being wrong there.
and contents of
I've failed to mention that gcc that curl is built with is installed locally too, thats why LD_LIBRARY_PATH isn't empty from the start.
Could it be the culprit?
Erm, I probably named it wrong. OpenSSL was built and, well,
This will probably help, but it also will make a final library have that