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!