<p>I'm not sure if this question is better suited in the context of Autotools, but since it's about Bitcoin Core, I'll try to ask it here.<br />
I am trying to Compile/Link libsecp256k1 as a shared library with Bitcoin Core.</p>
<p>configure.ac is calling configure of libsecp256k1 but just removing &quot;-disable-shared&quot; isn't engough
<a href="https://github.com/bitcoin/bitcoin/blob/7ff64311bee570874c4f0dfa18f518552188df08/configure.ac#L1637" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/7ff64311bee570874c4f0dfa18f518552188df08/configure.ac#L1637</a></p>
<p>And here it looks like it is static compiling.
<a href="https://github.com/bitcoin/bitcoin/blob/7ff64311bee570874c4f0dfa18f518552188df08/src/Makefile.am#L61" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/7ff64311bee570874c4f0dfa18f518552188df08/src/Makefile.am#L61</a></p>
<p>Could someone point out to me if this is even possible in a simple way and if so how.</p>
<p>Thanks a lot</p>

CC BY-SA 4.0
2020-12-11T01:36:37.500Z
Why on earth would you want to be dynamic linking a security and safety critical library?
Claris
CC BY-SA 4.0
2020-12-11T02:12:08.080Z
It is not a productive system!
But even if it were a productive system.
Isn't it obscurity rather than security.
I suspect the reason was optimization
of course a LD_PRELOAD or similar would be possible.
But then we are talking about a deeper system level security problem
and such a system is the wrong place for your coins in the first place.
But I am open to other points of view.
Tom
CC BY-SA 4.0
2020-12-11T02:14:12.147Z
No, the reason why Bitcoin Core is distributed as a static binary is due to security concerns, not "security by obscurity". What we've seen in the past is that many distributions of packages tend to be providing hilariously outdated versions of core libraries like OpenSSL, which for a time was consensus critical. Two versions of Bitcoin Core that are otherwise identical could become out of sync with one another just due to minor changes within its dependent libraries.
Claris
CC BY-SA 4.0
2020-12-11T02:15:09.380Z
The only reason for dynamic dependencies in software at all is for space saving, which is not a consideration today with the size of modern storage, and the fact that the several megabyte `bitcoind` binary will probably be downloading 300GB of data shortly after installation.
Claris
CC BY-SA 4.0
2020-12-11T02:29:47.390Z
Ok I get the point, but this could be fixed with rpath and a separate directories.
Anyway. I just wanted to benchmark different modifications.
Without recompiling the whole thing by swapping symlinks :)
Tom
CC BY-SA 4.0
2020-12-11T02:31:41.867Z
There's inbuilt benchmarking for libsecp256k1, but be aware that it's not the purpose of the library to be fast for signing or key generation. There's many functions which are made intentionally, seemingly arbitrarily slow to avoid secret dependent memory accesses and other secret leaks through timing.
Claris
<bitcoin-core><bitcoin-core-development><compiling><secp256k1>
Linking libsecp256k1 as shared library to Bitcoin Core
Tom
# Linking libsecp256k1 as shared library to Bitcoin Core

(Asked by: username_0 on 2020-12-10)

I'm not sure if this question is better suited in the context of Autotools, but since it's about Bitcoin Core, I'll try to ask it here.  
I am trying to Compile/Link libsecp256k1 as a shared library with Bitcoin Core.

configure.ac is calling configure of libsecp256k1 but just removing "-disable-shared" isn't engough
<https://github.com/bitcoin/bitcoin/blob/7ff64311bee570874c4f0dfa18f518552188df08/configure.ac#L1637>

And here it looks like it is static compiling.
<https://github.com/bitcoin/bitcoin/blob/7ff64311bee570874c4f0dfa18f518552188df08/src/Makefile.am#L61>

Could someone point out to me if this is even possible in a simple way and if so how.

Thanks a lot

**Tags:** bitcoin-core, bitcoin-core-development, compiling, secp256k1

> **Comments:**
> **username_1**: Why on earth would you want to be dynamic linking a security and safety critical library?  
> **username_0**: It is not a productive system! But even if it were a productive system. Isn't it obscurity rather than security. I suspect the reason was optimization of course a LD_PRELOAD or similar would be possible. But then we are talking about a deeper system level security problem and such a system is the wrong place for your coins in the first place. But I am open to other points of view.  
> **username_1**: No, the reason why Bitcoin Core is distributed as a static binary is due to security concerns, not "security by obscurity". What we've seen in the past is that many distributions of packages tend to be providing hilariously outdated versions of core libraries like OpenSSL, which for a time was consensus critical. Two versions of Bitcoin Core that are otherwise identical could become out of sync with one another just due to minor changes within its dependent libraries.  
> **username_1**: The only reason for dynamic dependencies in software at all is for space saving, which is not a consideration today with the size of modern storage, and the fact that the several megabyte `bitcoind` binary will probably be downloading 300GB of data shortly after installation.  
> **username_0**: Ok I get the point, but this could be fixed with rpath and a separate directories. Anyway. I just wanted to benchmark different modifications. Without recompiling the whole thing by swapping symlinks :)  
> **username_1**: There's inbuilt benchmarking for libsecp256k1, but be aware that it's not the purpose of the library to be fast for signing or key generation. There's many functions which are made intentionally, seemingly arbitrarily slow to avoid secret dependent memory accesses and other secret leaks through timing.  

---

## 0 answers

