updating openssl, now link error with NSSLOW_ - linux

We have centos6 6.5 64bit server. It had been setup for 32bit development. Our project is statically linked.
a team member installed the most recent openssl, openssl-devel, and openssl-static 64bit and 32bit i686 libraries. Nothing else in our setup has been modified. Now when compiling we get a list of errors similar to
/usr/lib/libcrypt.a(md5-crypt.o): In function `__md5_crypt_r':
(.text+0x99): undefined reference to `NSSLOW_Init'
/usr/lib/libcrypt.a(md5-crypt.o): In function `__md5_crypt_r':
(.text+0xb4): undefined reference to `NSSLOWHASH_NewContext'
we have tried reverting out openssl packages but the error persists
thank you

/usr/lib/libcrypt.a(md5-crypt.o): In function `__md5_crypt_r':
(.text+0x99): undefined reference to `NSSLOW_Init'
That's not part of OpenSSL:
openssl-1.0.1f$ grep -r NSSLOW_Init *
openssl-1.0.1f$
libcrypt.a
libcrypt is part of NSS. NSS is is Mozilla's Network Security Services library. You can read about it here: https://developer.mozilla.org/en-US/docs/NSS.

Related

Keep gcc linker from using non-system libraries found in system /lib64 folder

I am porting a large C++ library (libcoro.so) and example application (coro-example.cpp) from Windows to RedHat Linux 7.4. I have very little development experience on Linux, so this is probably a 'newbie' question. I have libcoro and the example app compiling, linking, and running on my RHEL 7.4 VM. However, the gcc linker fails to link the app on the customer's RHEL 7.4 machine when he tries to link coro-example.o to libcoro.so. The error message is:
/usr/bin/ld: warning: libusb-0.1.so.4, needed by ./bin/libcoro.so not
found (try using -rpath or -rpath-link) libcoro.so: undefined
reference to 'usb_open' libcoro.so: undefined reference to
'usb_release_interface' ...etc...
Running 'ldd coro.so' on my machine displays:
libusb-0.1.so.4 => /lib64/libusb-0.1.so.4 (0x00007f71115db000)
...etc...
And on the customer's machine:
libusb-0.1.so.4 => not found [many other libs] => not found ...etc...
Indeed, these libraries are in my /lib64 folder, but are not in the customer's. I'm not sure how they got installed on my machine. I have access to the missing libraries and can deliver them with my libcoro.so library. I really want my app to be self-contained and run on any RHEL 7.x machine. My question is:
What is the best way to identify which libraries are not part of the RHEL 7.x installation and have the linker fail on my machine if I'm not delivering a local copy? I tried linking with -nodefaultlibs, but the link fails on functions like printf() and I haven't found a way to locate these standard libraries. They don't appear to be in /lib64.
Is there a way to exclude /lib64 from the default library search?
There is a linker switch -Wl,--no-undefined which seems to do what I want. It fails to link and generates an error is the library is isn't explicitly named. Also, the command ldd libcoro.so lists all dependencies and where they are being resolved. I also found this this article very helpful.

Compiling openssl for android - warning: shared library text segment not shareable

I'm trying to build static openssl library for x86 by using the latest NDK (r11b) as explained in this link:
Compiling the latest OpenSSL for Android
However, when I try to include the output libcrypto.a in to some other shared library (SO) and compile that, it throws the error:
WARNING: shared library text segment not shareable
error: treating warning as errors
I tried using the pre-built libraries from here: https://github.com/emileb/OpenSSL-for-Android-Prebuilt/tree/master/openssl-1.0.2/x86/lib
and the above error message disappeared and everything built just fine.
Does anybody know how exactly I can build openssl libraries myself without "text segment not shareable" problem?
Note: I'm not looking for options to suppress this warning.
I was able to get rid of this issue by using the following scripts for building openssl:
https://github.com/xvtom/build-openssl-android
Also refer this:
https://wiki.openssl.org/index.php/Android

Openssl header not found -- error

I need to compile a libwebsocket library for my ARM target which requires openssl for its functioning.
I am getting following error when i build latest libwebsocket at the time of, cmake ...
But openssl is installed here
whereis openssl
openssl: /usr/bin/openssl /usr/bin/X11/openssl /usr/share/man/man1/openssl.1ssl.gz
=================================== Error ================
-- Looking for 4 include files stdlib.h, ..., float.h - found
-- Found ZLIB: /usr/lib/arm-linux-gnueabihf/libz.so (found version "1.2.7")
ZLib include dirs: /usr/include
ZLib libraries: /usr/lib/arm-linux-gnueabihf/libz.so
Compiling with SSL support
CMake Error at /usr/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (message):
Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
system variable OPENSSL_ROOT_DIR (missing: OPENSSL_LIBRARIES
OPENSSL_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:291 (_FPHSA_FAILURE_MESSAGE)
/usr/local/share/cmake-2.8/Modules/FindOpenSSL.cmake:313 (find_package_handle_standard_args)
CMakeLists.txt:436 (find_package)
-- Configuring incomplete, errors occurred!
======================================= openssl is here ========================
ignite#ignite:~/sbox2/rootfs/rfs-raspbian_2/home/pi/libwebsockets/build$ whereis openssl
openssl: /usr/bin/openssl /usr/bin/X11/openssl /usr/share/man/man1/openssl.1ssl.gz
actually i have, source tarball from here. it have configure script to make & make install
http://www.openssl.org/source/
openssl-1.0.1e.tar.gz
So with this (openssl-1.0.1e.tar.gz) will be the right package to get --> openssl-dev or openssl-devel --- so that i can resolve this error ?
So with this (openssl-1.0.1e.tar.gz) will be the right package to get --> openssl-dev or openssl-devel --- so that i can resolve this error ?
The openssl-dev packages are for development on the host machine (which is probably x86 or x64 family). You need a cross compiled library for the target (and not the host). So openssl-dev will probably not solve your problem.
Are you targeting a generic ARM processor, iOS, or Android? If the former, you will need an arm cross-toolchain with paths set appropriately. I'm not aware of a good tutorial on cross compiling the library (and I've suffered it in the past).
There are some prebuilt configurations for generic cross compiling. Open Configure and config, and look at some of the triples. (OpenSSL does not use Automake and friends).
If iOS or Android, the OpenSSL wiki has some examples of cross compiling for the platforms. See, for example, FIPS Library and Android. The setenv-android.sh script is most important because it set paths, sysroot and toolchains. Once paths and toolschains are set, the rest is easy.
If you are targeting a generic ARM, then you could use the Android setenv-android.sh as a starting point for your generic build. Once you complete the build, then point OPENSSL_ROOT_DIR into the install directory for ARM.

undefined reference to `_WinMain#16' with cygwin and mingw in openssl

I kind of am struggling with OpenSSL over here. I downloaded the current release 1.0.1 and the compilation itself works. I can even call ./apps/openssl.exe. But when I get to the linking process the linker complains:
/usr/i686-pc-mingw32/sys-root/mingw/lib/libmingw32.a(main.o): In function `main':
/usr/src/mingw-runtime/mingw-runtime-3.20-1/src/mingwrt-3.20-mingw32/main.c:73: undefined reference to `_WinMain#16'
(this is if I use mingw in cygwin, the same error occurs with cygwin itself)
This is the cygwin error:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xba): undefined reference to `_WinMain#16'
Now I found out that this means that it doesn't find a main function, but this couldn't actually be, can it? I mean openssl HAS its main-function. And concerning mingw: I can't find that file it mentions so there could be cause of the error, but libcygwin.a does exist (though I have no idea how to figure out if it has a main function).
So basically I ask: Why does this error occur that only occurs if I don't add a main function. Did I miss something?
Edit: Sorry to have missed that: I am on Win 7 x64 Enterprise
See this for a solution. Steps summarized below:
unpack the .tar with the msys tools and NOT 7-zip.
Use tar -xzf openssl-x.y.z.tar where x.y.z denotes your version.
Then run the commands and it will work like a charm.

Problems building libcurl 7.21.2 on Ubuntu 11.10 (Hiphop)

I'm following this Hiphop installation guide:
https://github.com/facebook/hiphop-php/wiki/Building-and-installing-on-ubuntu-10.10
And when I try to make it, I get the following errors:
../lib/.libs/libcurl.so: undefined reference to `SSLv2_client_method'
I've found this Server Fault ticket, but the merged change from the linked Github pull request didn't seem to fix the problem.
https://superuser.com/questions/339932/compiling-curl-with-hiphop-for-php-patch
I'm running Ubuntu 11.10, but I doubt that's the issue.
Thanks for any help you can provide!
EDIT: Adding Hiphop Cmake errors:
Here are errors when I just try to cmake . while ignoring the libcurl problems:
CMake Error at CMake/HPHPFindLibs.cmake:90 (message):
Custom libcurl is required with the HipHop patch
Call Stack (most recent call first):
CMake/HPHPSetup.cmake:46 (include)
src/CMakeLists.txt:18 (include)
Ubuntu 11.10 uses OpenSSL v1.0. OpenSSL v1.0 has (finally!) disabled SSLv2 support entirely.
Curl can build against nosslv2 OpenSSL starting from 7.21.5.
You can port the changes in 7.21.5 that allow such builds back to your custom libcurl. Alternatively, you can build a private version of OpenSSL that includes SSLv2 support, and link your custom libcurl against it.
I had the same problem on 11.10.
#n.m was exactly right on this problem....
I inserted the following lines of code:
#ifdef OPENSSL_NO_SSL2
failf(data, "openSSL was compiled without SSLv2 support");
return CURLE_SSL_CONNECT_ERROR;
#endif
after line 1462
Please find these lines of code here : github.com/bagder/curl/commit/26b487a5d6ed9da5bc8e4a134a88d3125884b852
in curl/lib/ssluse.c
recompiled and built...
Seems to work now!

Resources