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
Related
while compiling I get the following warning:
/usr/bin/ld: warning: libgfortran.so.3, needed by /usr/openmpi-4.0.3rc4/lib64/libmpi_usempi.so, may conflict with libgfortran.so.5
It does create the .exe but when executing it an error occurs:
ideal.exe: error while loading shared libraries: libgfortran.so.5: cannot open shared object file: No such file or directory
I search for it to try and link it but it didn't work
whereis libgfortran.so.5
libgfortran.so: /usr/lib64/libgfortran.so.3
I don't have much knowlegde about linux or compilers and I'm working on a SUSE server without sudo permission. The gnu fortran compiler I'm using is in my home directory /home/gomezmr/gcc . Does anyone know how to solve this? Thank you.
Your OpenMPI library was compiled for a different version of GCC/gfortran than the version you are using for compiling. The MPI library must be compiled for the same compiler version that you are using for compiling.
In simple cases it may happen that it will somehow work anyway, but problems like yours can happen. When using the mpi or mpi_f08 modules, the major release version must match (e.g. both GCC9 or both GCC 11,...).
I am trying to cross-compile my Rust project on Mac OS to Linux using cargo build --target=x86_64-unknown-linux-musl.
I installed the binary for Linux + musl cross-compilation on mac using brew install FiloSottile/musl-cross/musl-cross as I would ideally want a standalone binary.
I also installed the target using rustup target add x86_64-unknown-linux-gnu
And I have the following in my .cargo/config:
[target.x86_64-unknown-linux-musl]
linker = "x86_64-linux-musl-gcc"
However, I ran into issues with 2 libraries - sqlite3 and pcap:
= note: /usr/local/Cellar/musl-cross/0.9.8/libexec/bin/../lib/gcc/x86_64-linux-musl/6.4.0/../../../../x86_64-linux-musl/bin/ld: cannot find -lsqlite3
/usr/local/Cellar/musl-cross/0.9.8/libexec/bin/../lib/gcc/x86_64-linux-musl/6.4.0/../../../../x86_64-linux-musl/bin/ld: cannot find -lpcap
collect2: error: ld returned 1 exit status
I was able to solve the sqlite3 linker issue by adding features = ["bundled"] to my Cargo.toml file (similar to what is described here - https://users.rust-lang.org/t/linker-cannot-find-lsqlite3/23230/18) as that likely built it from source (which was great) but when I tried doing the same with pcap, it gave the following error:
the package `myProject` depends on `pcap`, with features: `bundled` but `pcap` does not have these features.
After reading somewhere I also tried (with low hopes) of providing the path to the installed libpcap on mac using RUSTPATH='-L/...' cargo build ... but that resulted, of course in undefined symbol errors.
Any ideas how can I get past this issue and cross compile my Rust project into a statically linked binary on macos to run on linux?
Cross compilation does not magically take care of libraries. You cannot just say "I want musl" and have something take care of all your dependencies.
The error message you are seeing is telling you exactly this: it cannot find libsqlite3 and libpcap.
The reason the error for sqlite disappears is because your sqlite library has a bundled feature, which replaces the linking with a built-in sqlite client. This, however, also requests the pcap bundled feature, which does not exist.
You have two options:
If you do not mind the performance loss in the bundled sqlite client, change your feature definition to target the feature of the dependency requiring sqlite
If you want the raw library itself, you will have to compile it for musl
No matter what happens, you will need to cross-compile libpcap for musl with the default sysroot provided by your musl compiler. As this varies per library, you will need to consult the libpcap documentation. once you have done so, you should be able to use the -lpcap flag, and the error will resolve itself.
Using Android NDK R10E, I am trying to build a shared library for all supported ABI's and I am getting the following error for some but not all ABI's:
[armeabi] SharedLibrary : libMyLib.so /home/user/android-ndk-r10e/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld:
fatal error: /home/user/source/MyLib/obj/local/armeabi/libMyLib.so: Input/output error
The project successfully builds for arm64-v8a, mips and mips64 but fails with the above error for armeabi, armeabi-v7a, x86 and x86_64.
I have a static library project and another shared library project and they both build successfully for all 7 ABI's.
If I compare the contents of obj/local/ for an ABI that builds and one that does not, they both contain all the same files except for libMyLib.so.
The difference between those two sets of ABIs is that the failing ones link using ld.gold and the working ones use ld.bfd.
Two things to try:
Use the 4.9 toolchain. It hopefully has the bug fix.
If that doesn't work, you can add -fuse-ld=bfd to your ldflags to use bfd even on the architectures that default to gold.
Same issue happened to me in r15c.
The fix was to copy
android-ndk-r15c/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld.bfd over ld.
I had to copy it because I could not easily find a way to specify this flag to CMake to use it while detecting the compiler features.
I am following this site to compile OpenCV for ARM.
It could not find my compiler so i hardcoded it into cmake file
find_program(CMAKE_C_COMPILER NAMES arm-linux-gnueabi-gcc-4.7)
find_program(CMAKE_CXX_COMPILER NAMES arm-linux-gnueabi-g++-4.7)
set(ARM_LINUX_SYSROOT /usr/arm-linux-gnueabi CACHE PATH "ARM cross compilation system root")
It compiles to aproximately 50% and then throws the following error:
Linking CXX shared library ../../lib/libopencv_viz.so
/usr/lib/libvtkCharts.so.5.8.0: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
I am not every experienced in cross compilation (or straight compilation for the matter). How do i fix this?
I think it is a mismatch between libopencv_viz and libvtkCharts. Some of your 3rdparty libs are built for another platform. These libraries themselves must be recompiled from source to match the details (ABI, dynamic system library dependencies, etc) of the system on which they are intended to be used.
Compiling OpenCV 2.4.10 worked for me. I did not have any preferred version. If you want to compile v3.0 see #Kornel's answer, that suggests to leave viz library out of compilation.
Use this command to checkout v2.4.10
git checkout 2.4.10
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!