Not sure what platform the other person is using, but, for the record the soname 1.0.0 causes big problems on Solaris 11 and up. Solaris 11 ships an OpenSSL 1.0.0 version in standard library locations, if anyone just builds anything higher than that, and do NOT modify build to add -R runtime load paths, you will see the libssl built link with Solaris 11 libcrypto which is not good. There are functions in 1.0.1 that do not exist in 1.0.0
I have seen a change in version naming strategy in main branch, so hopefully this will soon be not an issue. FYI, changing LD_LIBRARY_PATH using crle, is a bad idea on Solaris 11, made my boot environment un-bootable. For Solaris at least, I think its a good idea to modify makefiles to always provide the -R option to the linker. I have used that for a very long time, and avoided any collisions with standard Solaris versions. >-- Original Message -- > >On Wed, Apr 22, 2015 at 12:12:45AM +0000, Shanku Roy wrote: > >> lrw-r--r-- root root 2015-04-10 02:33 libcrypto.so -> >> libcrypto.so.1.0.0 >> -rw-r--r-- root root 1988088 2015-04-10 02:27 libcrypto.so.1.0.0 >> >> Is there any configure option in OpenSSL build scripts to not generate >> the symbolic links and rather generate actual binary as >> libcrypto.so/libssl.so from the build process like following: > >The library "soname" is part of the ABI. What platform are you >building for where it would not be appropriate to encode the ABI >compatibility name into the library name? > >-- > Viktor. >_______________________________________________ >openssl-users mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
