libwww-5.4.0-r7 (also r6) pick up the libssl.so in /usr/local/lib/libssl.so if it exists, instead of /usr/lib/libssl.so. kerframil gave me a patch to configure.ac that works on my system, that hard codes the path to /usr/lib/, but said a less specific patch should be developed. * my first Gentoo bug report, so go easy on me :)
Created attachment 140926 [details, diff] hard codes libssl.so path to /usr/lib/libssl.so
The problem is this: if test -d '/usr/local/ssl/lib'; then ssllib="-L/usr/local/ssl/lib -lssl -lcrypto" else ssllib="-L/usr/lib -lssl -lcrypto" fi I can think of no good reason for the package to take any heed of localised SSL libraries so perhaps it should be changed. Robert mentioned hard coding to "/usr/lib" and implies that the attached patch does that. In fact, that patch is a half-baked attempt on my part at doing something else and should be disregarded. Upon reflection, and considering that hard-coding libdir is bad, I think the most sensible thing to do is this: ssllib="-L$(pkg-config --variable=libdir openssl) -lssl -lcrypto" I'll attach a new patch.
Created attachment 140928 [details, diff] configure.ac patch: use pkg-config to determine the appropriate libdir
As the reporter forgot to mention it, I should point out for the record that he experienced a compile error (undefined reference to SSL_CTX_set_info_callback) where USE="ssl" was in effect.
Your local cruft in /usr/local is none of a Gentoo problem.
Sorry, but I would like a second opinion from the herd responsible for the package and you are not a member of that herd. To put it plainly, no matter how much good work you may do, you do not ultimately have jurisdiction over the maintenance of this package. I also must say that I find your remark to be unnecessarily condescending and rude and am somewhat riled by it (would it hurt to be polite?). Whether a user is right or wrong to accumulate "local cruft" is one thing (it is up to them how they decide to employ their systems). The question I'm asking is simple: (1) is there any valid reason for a gentoo ebuild that links to openssl _not_ to link to the instance of OpenSSL provided by the base system? (2) if the answer to that is yes, then what possibly objection could there be to applying this patch? To do so would eliminate one scenario under which the package may fail to build and, consequently, increases the resilience of the system and reduces the support burden to other users such as myself just one iota. By what criteria is this not an enhancement and since when was bugzilla not a place to request enhancements? I do not subscribe to the mindset that stipulates that, if a user does anything that results in an unexpected outcome, the user should be blamed and that no due consideration should be given as to how to render a system resilient to the circumstances that lead to said outcome. Unchecked, that mindset leads to situations like these: https://bugzilla.redhat.com/show_bug.cgi?id=119185. Once again, I would like a second opinion. It may well be that the text-markup herd agree with you in which case I will leave it alone. As it stands, I do not feel that this request has been considered fairly. Re-opened.
Also, hard-coding /usr/lib is not correct under any circumstances (even though it happens a lot). Assuming /usr/lib on a 64-bit system is bad and, yes it does result in real bugs sometimes. Just to pick one example, bug 125156 although there have been plenty of others. We shouldn't have to rely on a /usr/lib/symlink. Using this technique should always choose the genuine libdir.
this patch has been rolled into the existing patch libwww-5.4.0-autoconf-gentoo.diff please close this bug
see bug #246978 for resolution of this bug as they are being rolled together into r8
Thanks Matthew. Excellent work on bug 246978. Hopefully it will be greeted with more than the sound of chirping crickets and tumbleweed drifting softly across the plain. Fortunately, I have the ability to close the bug so I am doing so, marking as a duplicate of the aforementioned. *** This bug has been marked as a duplicate of bug 246978 ***
*** Bug 182074 has been marked as a duplicate of this bug. ***
On second thoughts, I don't think it's appopriate to mark as a duplicate. Instead, I'll have it depend upon the resolution of bug 246978, as I have done so for the other bugs that would be resolved by it.
(In reply to comment #8) > this patch has been rolled into the existing patch > libwww-5.4.0-autoconf-gentoo.diff > > please close this bug Closing as fixed then
