-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
./configure'ing with built but not installed SSL breaks some features #3006
Comments
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. I'm talking |
It does? I build with that option very frequently and I have not experienced that. Which checks do you see it breaking? |
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 If you 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 Lines 7012 to 7027 in 4058cf2
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 ... |
oops I meant |
Sure!
As I said, I'm really bad at Autotools, so pardon me for being wrong there.
and contents of
There is 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 |
Thanks! I'm now pretty sure this is because of a few places where |
If you want to try out out #3049: apply the patch, run |
Yep, it works with the patch! Thanks! |
Awesome, thanks for confirming! |
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.
That libssl is bundled with another libraries (including libcurl) and deployed with an executable that is built with
$ORIGIN
inrpath
. This is not the issue, but that usage pattern leads to an actuall one../configure --prefix=/home/user --enable-ares=/home/user --with-ssl=/home/user
does what it's suppose to do, but with a twist.I experienced the following
./configure
executes fine, but it fails some 'seems to work' tests like this:There are about 8 test that fail in a similar fashion and disable some features, although for me disabling
poll
was critical.The issue here, if I'm seeing it right, is that it can't load .so's that are not in
ld
search path, but still links against them.I'm not really sure if
rpath
of test executable or similar tools should be usedMy dirty fix is to just put prebuilt libraries in
./
before runningconfigure
, but it seems... bad?curl/libcurl version
operating system
Centos 6
The text was updated successfully, but these errors were encountered: