Skip to content

Conversation

@yanovich
Copy link
Contributor

If any executable loads gost.so, the executable already either has
libcrypto.so loaded or is statically linked against libcrypto.a.
Anyway it already has all libcrypto (and libssl) symbols present.

Without this patch gost.so is linked against libcrypto.so. As
a result, a diamond dependency is introduced. If gost.so is then
loaded by an executable which is statically linked against libcrypto,
ld will insist on loading libcripto.so, despite the executable
already having all necessary symbols. When the executable is statically
linked, shared objects for libcrypto and libssl are usually not built,
ld won't find them, and the caller will crush.

The patch removes this unnecessary link dependency in gost.so,
allowing it to be used by executables which are statically linked
against libcrypto.

If any executable loads `gost.so`, the executable already either has
`libcrypto.so` loaded or is statically linked against `libcrypto.a`.
Anyway it already has all libcrypto (and libssl) symbols present.

Without this patch `gost.so` is linked against `libcrypto.so`. As
a result, a diamond dependency is introduced. If `gost.so` is then
loaded by an executable which is statically linked against libcrypto,
`ld` will insist on loading `libcripto.so`, despite the executable
already having all necessary symbols. When the executable is statically
linked, shared objects for libcrypto and libssl are usually not built,
`ld` won't find them, and the caller will crush.

The patch removes this unnecessary link dependency in `gost.so`,
allowing it to be used by executables which are statically linked
against libcrypto.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant