openssl and bash libcrypto
ari at ish.com.au
Fri Apr 10 01:48:14 UTC 2015
Dewayne Geraghty wrote:
> Most likely there was a port build that required openssl port, and also required
> something like libarchive or libfetch (for example), both require openssl base
> (I've found net-mgmt/net-snmp does this). Your bt reveals that the symbol table
> is confused, as expected.
Ah, that's a good help. So I can easily core dump /usr/bin/vi by trying to edit any file. Forgive my ignorance of C debugging, but I'll stumble through this:
1. I attach gdb to the application and load the core dump.
2. It tries to read symbols from a bunch of system libraries.
3. In amongst all those libraries are some located in /usr/local:
So the whole chain of problems originates from nss_ldap. But I'm confused about what I'm looking at here..
Did vi try to load some access control library when it tried to write a file out to disk, and then that loaded nsswitch which in turn I've tied into the nss_ldap port, and then from there it was a slippery slope to disaster of conflicting libraries?
I'll try building nss_ldap against base openssl and see if that helps, but can someone help explain the naming here. Why do we have /usr/local/lib/libcrypto.so.8 but lib/libcrypto.so.7. Was this done when the openssl port moved from 1.0.1 to 1.0.2? Isn't there usually a warning in UPDATING when we need to rebuild all ports for that reason?
If all ports move to only use openssl from ports, then how does my example above get fixed? Doesn't it make it all worse?
So many questions! Thanks for all the help in understanding this.
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
More information about the freebsd-ports