Tag Archives: gcc

Continuing to Debug a OpenSSL Build

Leave a reply

Continuing to tinker with the OpenSSL problems I’ve been having. Have a chunk of software whose building requires the older version of OpenSSL to be installed. But I want the newest OpenSSL dev package on my machine. We’re not going to get along.

I discovered I could selectively static link some of the libraries into the program. This was completely mind blowing feature to me. I started using the GCC linker way way back and was quite disconcerted by the -lfoo syntax which would find libfoo.a for linking.

In trying to force this software to build against a local copy of the older OpenSSL, I found problems with the final program trying to find the OpenSSL dynamic libraries. LD_LIBRARY_PATH would allow me to aim the software at my local lib but I was hoping there would be something simpler (that didn’t require setting that env var every time). Could I static link the executable? It’s been a while since I tried to static link a Linux app.

Quick google and found an even better answer:

https://stackoverflow.com/questions/6578484/telling-gcc-directly-to-link-a-library-statically

In the Makefile, I simply had to use -l:filename to link directly to a specific static library. With the -L flag, I could aim at a specific library location.

LDFLAGS += -lffi -lutil -lz -lm -lpthread -l:libssl.a -l:libcrypto.a -lrt -ldl

I had no idea this was possible with the linker. I’ve been using the GNU compilers for so many years and had no idea this was possible.

 

 

Debugging an OpenSSL Version Problem.

Leave a reply

I’m working in a system using an older version of OpenSSL. The system builds both a cross compiled version of Python and the same version of Python built for the host. Having the same version of python both in the embedded host and the local host allows me to run the Python scripts locally on the same exact same version of Python. I can test my Python scripts locally without having to push them to the remote firmware, which is slow and expensive.

Python uses OpenSSL. The embedded Python build used a local repo copy of the 1.0.x series OpenSSL. Consequently, the host Python build also needs to use the same older 1.0.x series OpenSSL. But the host Python build used the system (default) installed dev version of OpenSSL. I would have had to remove the current version of OpenSSL and install the older version. I was troubled by that requirement.

I built the OpenSSL 1.0.x, installed it to a $HOME tree. I then had to do the hard part of aiming the system’s host Python build at the older version. Seemed simple enough: find where CFLAGS and LDFLAGS was defined, change those to aim at my local OpenSSL.

CFLAGS+=$(HOME)/include/openssl

LDFLAGS+=$(HOME)/lib

But it wasn’t working. I knew it wasn’t working because the Python link would report not being able to find the newer OpenSSL symbol names so I knew the build was still using the newer version of header files.

I needed to debug my changes to the build. Along the way, I found some useful GCC options.

Debugging a header file include problem is straightforward: sabotage the build. I added “#error foo” to the host’s /usr/include/openssl/rsa.h and “#error bar” to the old openssl/rsa.h   Fun “make -B Modules/_ssl.o” and see which include file was being hit.  (The -B flag to make forces Make to rebuild the file regardless of timestamp.)  The build would fail with “error foo”. I was still getting the system header. I needed to see where GCC was finding its header files.

https://stackoverflow.com/questions/344317/where-does-gcc-look-for-c-and-c-header-files

specifically https://stackoverflow.com/a/41718748/39766

The set of paths where the compiler looks for the header files can be checked by the command:-

cpp -v

I added the ‘-v’ flag to the build, asking GCC to pass it along to the preprocessor.

gcc -Xpreprocessor -v $(CFLAGS) -c [etcetera]

Output looks like:

#include "..." search starts here:
#include <...> search starts here:
/home/dpoole/include/openssl
...
/usr/lib/gcc/x86_64-linux-gnu/7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.

Oops. First include should have been /home/dpoole/include not /home/dpoole/include/openssl   Fixed my CFLAGS and I’m now building Python against my local copy of openssl.

Python crashes on startup but progress!