i'm working on ubuntu, and i'm developing a C++ library that uses OpenSSL.
So, the PC i use to develop the code has an OpenSSL version of 2010. I create the lib, compile it with a simple test program, and i execute it successfully.
Then, when i test the lib in other PC (which have the latest OpenSSL version - May 2012), i compile the simple test program successfully, but when i execute it they crashes.
I "solved" the problem updating the version of OpenSSL from 2010 to the last , but in future it is possible that this problem can occur again, if someone will use the lib with a recent OpenSSL version.
So, i would like to know if there is a possibility of, for example, create the lib with the OpenSSL necessary files, in order to the code execute regardless of the OpenSSL version of the PC that is compiling the lib with the simple test program.
For creating my lib, i compile my files into .obj files (for example: g++ -c fileA.c -o fileA.o), and then i create a libABC.a file (ar rcs libABC.a filaA.o fileB.o ...).
I only use the "-lssl" compile option to link my library with the rest of the code, for example: g++ simpleCode.o libABC.a -o Test -lssl
Best Regards,
Sérgio
Normally problems like this are solved by giving incompatible versions of the library a different soname (e.g. libssl.0.9.7 vs libssl.1.0.0). If your version of libssl.so doesn't have a versioned soname it is broken.
To check the library's soname, and the soname your program is linked with, execute these commands
ldd /path/to/your/program/Test | grep openssl
objdump --private-headers /usr/lib/libssl.so* | grep SONAME
If your program is linked with libssl.0.9.7 it will simply not start with any other version.
Related
My problem is as follows :
I have OpenSSL as static libraries (libcrypto.a and libssl.a).
Compiled on Windows with MSys2/MinGW64.
Besides that, I have a small self written library based on OpenSSL.
Now I want to "bundle" the Crypto lib from OpenSSL with My lib to a "big" static library for later statically compiling in other applications on Windows without deploying any library.
What would a CMakeLists.txt file looks like? And are the prerequisites (OpenSSL as static libs) correct?
Actually compiling this to a dynamic DLL works like a charm. But My static lib are only includes the symbols of My own library, not from OpenSSL too.
Actually I have no working CMake file, so I can't include an example. I'm just looking for a direction how to do it.
A short suggestion how to begin would be highly appreciated.
If what you really want to do is combine multiple static libraries into one, for the convenience of external consumers, you'll probably need to run a custom command to do this (as it's not something that's frequently done).
Using the GNU toolchain, the commands to do so might look something like this (untested though):
${CMAKE_COMMAND} -E make_directory tempdir
cd tempdir
${CMAKE_AR} x $<yourlib:TARGET_FILE>
${CMAKE_AR} x ${OPENSSL_CRYPTO_LIBRARY}
${CMAKE_AR} x ${OPENSSL_SSL_LIBRARY}
${CMAKE_AR} cf ${CMAKE_BINARY_DIR}/bin/libyourmegalib.a *.o
cd ..
${CMAKE_COMMAND} -E remove_directory tempdir
Then you would use add_custom_command() to create a target to run this script - either put those lines as COMMAND arguments, or create a script template, substitute values at CMake generation time using configure_file(), then have the custom command run that script.
That said, if the external consumers are all using CMake themselves, I would skip this entirely, and just have the installation process for your library generate CMake package configuration files that declare the dependencies on the OpenSSL libraries.
target_link_library() works both for add_executable() and add_library(), so you should be able to do:
add_library(yourlib STATIC ...)
target_link_libraries(yourlib lib1 lib2 ...)
(where yourlib is your library, and lib1, ... are the libraries you want to bundle.
I'm trying to build some software from ECMWF called ECCODES.
It builds fine on GNU/Linux.
It builds fine on Mac OS X.
It builds fine on Windows/Cygwin.
Unfortunately (Ugh!!), I must use Windows and I can't use Cygwin.
I have to use something like MinGW.
The build instructions use CMake. I am no expert at CMake. The Windows system I am on has:
cygwin64
mingw64
a bare-bones Visual Studio 14
I've tried every incantation and override of the CMake variables/options:
-DCMAKE_C_COMPILER=... \
-DCMAKE_CXX_COMPILER=... \
-DCMAKE_Fortran_COMPILER=... \
-DCMAKE_MAKE_PROGRAM=... \
-G ...
to get ECCODES to build using MinGW, with no luck. I know some will ask, "Why not contact ECMWF?" The short answer is, the response time is very long (months/years). The FAQ page is empty, and you can't post questions on their Jira site (it's locked).
Would it be possible for someone who knows CMake and MinGW well to download the .tar.gz, build ECCODES using MinGW, and tell us how you did it?
http://www.ecmwf.int/
https://software.ecmwf.int/wiki/display/ECC/ecCodes+Home
https://software.ecmwf.int/wiki/download/attachments/45757960/eccodes-0.13.0-Source.tar.gz?api=v2
I'm building a dll to use PocoNetSSL to get some data via an HTTPS endpoint. I need to call that dll via C# in Unity which runs an old version of Mono.
I am using mingw-w64 shell to build my dll. There is a package of the Poco libraries available via the package manager pacman and I am using that.
$ pacman -Qs 'poco'
local/mingw-w64-x86_64-poco 1.6.0-2
POrtable COmponents C++ Libraries (mingw-w64)
I can build an executable and it builds fine & runs fine hitting the https endpoint. I have openssl installed somewhere or it may have come with mingw.
My problem is that I cannot open the dll with LoadLibrary. I get a null pointer and I'm guessing it's a dependency problem. Here's my build commands and a snapshot of dependency walker. Is there anything I am missing here. I think I should be able to do this but maybe not?
sburke#sburke-pc MINGW64 ~/sandbox/hitaws
$ scons
scons: Reading SConscript files ...
msys
scons: done reading SConscript files.
scons: Building targets ...
g++ -o gdoaws.os -c -Wall -DPOCO_WIN32_UTF8 -I/mingw64/include gdoaws.cpp
g++ -o gdoaws.dll -Wl,-no-undefined -shared -Wl,--out-implib=libgdoaws.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--whole-archive gdoaws.os -Wl,--no-whole-archive -L/mingw64/lib -lPocoNetSSL.dll -lPocoNet.dll -lPocoUtil.dll -lPocoFoundation.dll
scons: done building targets.
Assuming your loading a dynamic library code is correct your app is very likely trying to load different version of openssl dlls than Poco was built against.
In msys2 you can check a dynamic library dependencies by:
ldd /mingw64/bin/libPocoNetSSL.dll
which depends on:
LIBEAY32.dll => /mingw64/bin/LIBEAY32.dll
SSLEAY32.dll => /mingw64/bin/SSLEAY32.dll
Is this what you see in dependency walker?
The best workround for this problem is to copy above dlls to the folder where your executable is and always distribute them with your software.
I'm trying to use CppUTest in Windows, first step is to get it to work and I already have problems. These are the things I've tried:
First Approach
With CMake, using the cmake GUI I can do the configure and generate command and I get something in the output directory, but no binaries and no libraries, just a bunch of cmakefiles. The CMake GUI says everything went OK during the configuration and generation steps, however the libraries (.lib files) are not generated in the output directory... is there something I am missing? I've never used CMake before.
Second approach
With MinGW and msys alone, running cmd in Windows and executing a MinGW shell by typing sh in the Windows terminal, afterwards I execute the following commands:
cd <CppUTest folder>
mount c:\mingw /mingw
./autogen.sh
./configure
make
The build process starts but it fails with a message indicating that pthread.h was not found in MinGW directory. If I install the pthread-win32 package with the MinGW package manager and repeat the same steps as above the build process starts but fails with a message indicating that the structure timespec is defined in time.h and pthread.h.
I've tried to follow this same procedure with CppUTest 3.6 and it works perfectly fine, I get the .lib files, so I guess I will have to continue with this for now.
Does anyone know how to build CppUTest 3.7 (latest release) with MinGW or CMake?
In the end I used Cygwin to compile it, I couldn't find a way to compile it with MinGW properly, I added a dirty trick to make it compile under MinGW (handled the timespec redifinition) but chances are that is going to cause issues.
Just make sure that you use Cygwin aswell to compile your tests, something that I found out after making this question (https://www.youtube.com/watch?v=oVmd0P85D8o).
I started to learn Rust programming language and I use Linux. I'd like to build a cross-platform application using this language.
The question might not be related to Rust language in particular, but nonetheless, how do I do that? I'm interested in building a "Hello World" cross-platform application as well as for more complicated ones. I just need to get the idea.
So what do I do?
UPDATE:
What I want to do is the ability to run a program on 3 different platforms without changing the sources. Do I have to build a new binary file for each platform from the sources? Just like I could do in C
To run on multiple platforms you need to build an executable for each as #huon-dbauapp commented.
This is fairly straightforward with Rust. You use "--target=" with rustc to tell it what you want to build. The same flag works with Cargo.
For example, this builds for an ARM target:
cargo build --target=arm-unknown-linux-gnueabihf
See the Rust Flexible Target Specification for more about targets.
However, Rust doesn't ship with the std Crate compiled for ARM (as of June 2015). If this is the case for your target, you'll first need to compile the std Crates for the target yourself, which involves compiling the Rust compiler from source, and specifying the target for that build!
For information, most of this is copied from: https://github.com/japaric/ruststrap/blob/master/1-how-to-cross-compile.md
The following instructions are for gcc, so if you don't have this you'll need to install it. You'll also need the corresponding cross compiler tools, so for gcc:
sudo apt-get install gcc-arm-linux-gnueabihf
Compile Rust std Crate For ARM
The following example assumes you've already installed the current Rust Nightly, so we'll just get the sources and compile for ARM. If you are using a different version of the compiler, you'll need to get that to ensure your ARM libraries match the version of the compiler you're using to build your projects.
mkdir ~/toolchains
cd ~/toolchains
git clone https://github.com/rust-lang/rust.git
cd rust
git update
Build rustc for ARM
cd ~/toolchains/rust
./configure --target=arm-unknown-linux-gnueabihf,x86_64-unknown-linux-gnu
make -j4
sudo make install
Note "-j4" needs at least 8GB RAM, so if you hit a problem above try "make" instead.
Install ARM rustc libraries In native rustc build
sudo ln -s $HOME/src/rust/arm-unknown-linux-gnueabihf /usr/lib/rustlib/arm-unknown-linux-gnueabihf
Create hello.rs containing:
pub fn main() {
println!("Hello, world!");
}
Compile hello.rs, and tell rustc the name of the cross-compiler (which must be in your PATH):
rustc -C linker=arm-linux-gnueabihf-gcc-4.9 --target=arm-unknown-linux-gnueabihf hello.rs
Check that the produced binary is really an ARM binary:
$ file hello
hello: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), (..)
SUCCESS!!!:
Check: the binary should work on an ARM device
$ scp hello me#arm:~
$ ssh me#arm ./hello
Hello, world!
I've used this to build and link a Rust project with a separate C library as well. Instructions similar to the above on how to do this, dynamically or statically are in a separate post, but I've used my link quota up already!
The best way to figure this out is to download the source code for Servo and explore it on your own. Servo is absolutely a cross-platform codebase, so it will have to address all of these questions, whether they be answered in build/configuration files, or the Rust source itself.
It looks like the rust compiler might not be ready to build standalone binaries for windows yet (see the windows section here), so this probably can't be done yet.
For posix systems it should mostly Just Work unless you're trying to do GUI stuff.
Yes, you won't need to change the source, unless you are using specific libraries that are not cross-platform.
But as #dbaupp said native executables are different on each platform, *nix uses ELF, Windows PE, and OSX Mach-O. So you will need to compile it for each platform.
I don't know the state of cross-compiling in rust, but if they already implemented it, then you should be able to build all the binaries in the same platform, if not, you will have to build each binary on it's platform.