与共享动态库交叉编译

Question

In my C++ project, I'm compiling and linking against a library that makes use of OpenSSL.

I need to compile this project for my BeagleBone which has openssl installed by default. I have downloaded libssl-dev on my development machine.

Thus, I can compile the project fine if I'm compiling for my development machine on x86_64 , but I am not able to successfully cross compile:

/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lssl
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lcrypto

This indicates I need to have armhf binaries for OpenSSL, which seems a bit of a waste really since I have them on my BeagleBone if it can just be patient and wait until I deploy it .

Is the only way around this cross-compiling OpenSSL myself? Where would I then need to install the .so files (I guess make install would be a bad idea?)

Answer 1

This indicates I need to have armhf binaries for OpenSSL

Correct.

which seems a bit of a waste really since I have them on my BeagleBone if it can just be patient and wait until I deploy it.

You appear to think that shared libraries are only needed at runtime, but that is not the case.

ELF stands for executable and linking format. The .so is very much needed at static link time to construct various tables in the main executable, which will then be used by the loader at runtime to resolve references from the main executable to the .so .

If you are familiar with Win32, you can think of .so as a combination of Win32 .LIB and .DLL packed into a single file.