Closed Bug 386841 Opened 14 years ago Closed 14 years ago

Crashreporter linked with libssl.so.4, libcrypto.so.4

Categories

(Toolkit :: Crash Reporting, defect)

x86
Linux
defect
Not set
major

Tracking

()

VERIFIED FIXED

People

(Reporter: mehturt, Assigned: ted)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Opera/9.20 (X11; Linux i686; U; en)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007070304 Minefield/3.0a7pre

Crashreporter program linked with libssl.so.4 and libcrypto.so.4, which do not exist in Debian.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Actual Results:  
Crashreporter does not work.

Expected Results:  
Should be linked with libssl.so, libcrypto.so.

ldd ./crashreporter
...
        libssl.so.4 => not found
        libcrypto.so.4 => not found
...
Component: General → Breakpad Integration
Product: Firefox → Toolkit
QA Contact: general → breakpad.integration
Gentoo doesn't have these either.

Simply symlinking them to lib{ssl,crypto}.so.0.9.8 makes breakpad work (AFAICT).
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hrm, I'm on openSUSE 10.2 and when crashing I get

/mnt/mozilla/packages/seamonkey-2.0a1pre.2007070808.en-US.linux-i686/seamonkey/crashreporter: error while loading shared libraries: libssl.so.4: cannot open shared object file: No such file or directory

instead of the crashreporter - looks like that's happening on a broad range of distros :(
(In reply to comment #1)
> Gentoo doesn't have these either.
> 
> Simply symlinking them to lib{ssl,crypto}.so.0.9.8 makes breakpad work
> (AFAICT).
> 

Even when symlinking them to proper libraries, it does not send the report, but the error message does not say why it fails.. but it's probably not related
Actually, sending did work fine for me when I did symlink the .so.4 versions to the .so.0.9.8 binaries.
Ted/Dave, who wants to take this? Linking directly against libssl.so makes me really nervous, but I'm not sure what the other options are.

Is this a problem where RedHat distros and other distros have radically different soversioning for these libs?
Shouldn't applications link against static ssl/crypto libraries instead of shared libraries (for security)?
We're just using `curl-config --libs`, which on my CentOS5 install gives:

-L/usr/kerberos/lib -lcurl -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl -lidn -lssl -lcrypto -lz

I don't see libssl.so.4 in /usr/lib, I wonder if this is specific to our current CentOS4 build platform?  Anyone want to test the builds from
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/linux-newref/latest-trunk/ ?  Those are built on the new linux refplatform, which uses CentOS 5.  If this isn't a problem there, then this bug is a non-issue, since we'll be switching to that machine for the official builds probably this week.

bsmedberg $ ldd linux-newref/firefox/crashreporter
...
        libssl.so.5 => /lib/libssl.so.5 (0x00cde000)
        libcrypto.so.5 => /lib/libcrypto.so.5 (0xf7ca4000)
It seems to work ok if we just link with -lcurl instead of the entirety of CURL_LIBS.  I'll have a patch in a bit.
Assignee: nobody → ted.mielczarek
This WFM, as libcurl pulls in those other libs anyway.
Attachment #271541 - Flags: review?(benjamin)
Comment on attachment 271541 [details] [diff] [review]
Link with -lcurl instead of CURL_LIBS

We should remove the MOZ_LIBCURL_LIBS configure check and do a AC_TRY_LINK using -lcurl.
Attachment #271541 - Flags: review?(benjamin) → review-
Running UBUNTU 7.04, normal is libssl.0.9.8
Firefox nightlies since about 7/06
Same error, except called lib is "libssl.so.6"

Somehow, we need the install to check for what is available -- or, of course, to link to a non-shared copy which we supply.
The approach used in my patch (with the changes bsmedberg requested in comment 11) are the proper fix for this.
Ok, this adds an AC_TRY_LINK -lcurl (inside of an AC_CACHE_CHECK) to configure.in, and then links to -lcurl in the client Makefile (as before).
Attachment #271541 - Attachment is obsolete: true
Attachment #272670 - Flags: review?(benjamin)
Attachment #272670 - Flags: review?(benjamin) → review+
Checked in.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
This doesn't seem to have fixed it.  I was pretty sure in my testing that it worked, I'm not sure if I missed something, or it never actually worked.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Oh, I think I'm wrong.  I ran `ldd crashreporter` on the CentOS5 system I built it on, and it lists libssl.so.6 etc.  But if I copy it to a different system and run ldd on it, it lists the correct libssl.  Please comment if there are any further issues.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Verified with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007071904 Minefield/3.0a7pre on Debian Etch and Sarge.
No, it's not fixed. Running ldd crashreporter I get

libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb7429000)
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb72fd000)

but when I actually crash I get 

firefox/crashreporter: error while loading shared libraries: libssl.so.6: cannot open shared object file: No such file or directory
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Works fine here now (Debian unstable).
I tested it by running crashreporter by hand and also by sending ABRT to firefox..
However the crash report is still not sent, for some unknown reason.
Oh, whoops. Apparently I was a day behind on updates and didn't notice. Works fine here, sorry.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
verified fixed in 2007082304 3.0a8pre nightly build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.