Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -66,3 +66,23 @@ and follow the above installation instructions as usual.

### Firmware Demo
[![asciicast](https://asciinema.org/a/96442.png)](https://asciinema.org/a/96442)

## OpenSSL (Linux)
In some cases users may want to use the switchtec-cli with a different/custom
version of OpenSSL that is not the default version packaged with the OS, whose
library files exist elsewhere in the host system and therefore is not expected
by the current switchtec-cli build system.

Users have observed the below error (or similar shared library errors) when
using OpenSSL commands after compiling the codebase.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused by this paragraph. Under what circumstances is this error being emitted? Is compiling a custom version of libssl the solution to whatever caused this?

Does switchtec-user depend on a specific version of libssl and commonly used systems have a version that is too old? What versions of libssl are affected? What operating systems are affected?

~~~
openssl: error while loading shared libraries: libssl.so.3: cannot open shared
object file: No such file or directory
~~~
To build the switchtec libraries to an alternate library path use the following
make flag when building:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on above, I was expecting some instructions that will build the project with a custom built OpenSSL library. But these are instructions that install the project, except places only the library outputs in a path of the user's choice. This doesn't seem all that advisable seeing the install command will also install the executables in the usual place but the executable won't be able to find the correct libraries it needs to run.

If the point is to put the libraries in a specific spot after compiling, I'd recommend just running make and then copying the libraries to where you want them. But this doesn't seem so widely applicable that I'd put it in the README. It'd likely just confuse users.

~~~
./configure
make
sudo make LIBDIR=<custom_lib_path> install
~~~