Peerplays_Blockchain/peerplays_migrated

Fork 0

Draft: #568 Static Link Libbitcoin #834

Open

bgerze wants to merge 1 commit from feature/568-static-libbitcoin into develop

bgerze commented

2023-11-06 16:10:28 +00:00

(Migrated from gitlab.com)

Changes for CMake files to enable static linking of libbitcoin libraries.

Assumes libbitcoin was built and installed according to readme doc.

Changes for CMake files to enable static linking of libbitcoin libraries. Assumes libbitcoin was built and installed according to readme doc.

bgerze commented

2023-11-06 16:10:28 +00:00

(Migrated from gitlab.com)

requested review from @vampik

vampik commented

2023-11-08 13:49:38 +00:00

(Migrated from gitlab.com)

marked this merge request as draft

marked this merge request as **draft**

vampik commented

2023-11-08 13:49:38 +00:00

(Migrated from gitlab.com)

assigned to @vampik

vampik commented

2023-11-08 13:52:11 +00:00

(Migrated from gitlab.com)

@bgerze @christophersanborn

We shouldn't use absolute path to libraries, like this: /usr/local/lib/
We should make the build with static libraries optional.
If we introduce static build, we should have this for all the libraries

In our dev team we are not sure, that time should be spent on this task.

@bgerze @christophersanborn - We shouldn't use absolute path to libraries, like this: `/usr/local/lib/` - We should make the build with static libraries optional. - If we introduce static build, we should have this for all the libraries In our dev team we are not sure, that time should be spent on this task.

bobinson commented

2023-11-18 18:53:00 +00:00

(Migrated from gitlab.com)

mainnet build : https://gitlab.com/PBSA/peerplays/-/jobs/5469593392/artifacts/browse/build

christophersanborn commented

2024-01-04 15:06:20 +00:00

(Migrated from gitlab.com)

@vampik Bumping this convo in the hopes that we can get this one merge-worthy, and ideally, included in the next release. Here are some responses to your previous points:

We shouldn't use absolute paths to libraries, like this: /usr/local/lib/

Agreed that this feels wrong. Would it be acceptable to parameterize it so the user can pass the library location in a CMake flag, e.g. -DLIBBITCOIN=/usr/local/lib/ or similar? (Or is there some standard formalism for this kind of thing that we should follow?). We could maybe have a default value of `/usr/local/lib/` so that it needn't be specified unless the location differs.

We should make the build with static libraries optional.

This makes sense, but if we make it optional, can we either (a) have the static build be the default, or (b) have the gitlab CI process setup to build it static? Reason is, the main motivation for this ticket is the simplification of doing a remote install using the gitlab artifacts. I.e, a user should be able to wget the binary to a cloud host and just run it without having to track down difficult libraries. (Here "difficult" means libraries that can't be trivially installed with an apt-get command.)

If we introduce static build, we should have this for all the libraries

Agreed in principle, and I think this could/should be a long-term goal. Note though, we did some experimenting with this, and there are definitely a few additional libraries that could be linked statically. However there are also a few that are very difficult to link static (because, iirc, they themselves depend on other dynamic libraries). So, to simplify, we just proposed static linking of the library that is most difficult for a user to acquire. (There's currently no apt-get command for LibBitcoin, unfortunately, using standard package repositories, so libBitcoin is the major headache to a remote install.)

A different alternative to consider:

Although static linking does solve a number of user headaches, one negative side effect is it increases the size of the binary. (Less so than a full dynamic libBitcoin install, however, so only really a problem if user keeps multiple copies or versions of witness node on a remote machine or needs to transmit the file over the network repeatedly.)

One potential other approach to simplifying remote install from gitlab artifacts, would be to make the entire peerplays_sidechain plugin an optional compile, disabled by default. If I've understood the code structure correctly, this plugin is the only part of the code that uses LibBitcoin. Also, this plugin is only needed by SON operators, not SON users. As the SON operators are a small minority, and they already undertake additional technical challenges to run a SON, it seems we could save headaches for most users by requiring only this small subset to ever need or build libBitcoin.

Would this latter approach be preferable, from a dev perspective?

@vampik Bumping this convo in the hopes that we can get this one merge-worthy, and ideally, included in the next release. Here are some responses to your previous points: > * We shouldn't use absolute paths to libraries, like this: `/usr/local/lib/` Agreed that this feels wrong. Would it be acceptable to parameterize it so the user can pass the library location in a CMake flag, e.g. `-DLIBBITCOIN=/usr/local/lib/` or similar? (Or is there some standard formalism for this kind of thing that we should follow?). We could maybe have a default value of \`/usr/local/lib/\` so that it needn't be specified unless the location differs. > * We should make the build with static libraries optional. This makes sense, but if we make it optional, can we either (a) have the static build be the default, or (b) have the gitlab CI process setup to build it static? Reason is, the main motivation for this ticket is the simplification of doing a remote install using the gitlab artifacts. I.e, a user should be able to `wget` the binary to a cloud host and just run it without having to track down difficult libraries. (Here "difficult" means libraries that can't be trivially installed with an `apt-get` command.) > * If we introduce static build, we should have this for all the libraries Agreed in principle, and I think this could/should be a long-term goal. Note though, we did some experimenting with this, and there are definitely a few additional libraries that could be linked statically. However there are also a few that are very difficult to link static (because, iirc, they themselves depend on other dynamic libraries). So, to simplify, we just proposed static linking of the library that is most difficult for a user to acquire. (There's currently no `apt-get` command for LibBitcoin, unfortunately, using standard package repositories, so libBitcoin is the major headache to a remote install.) ### A different alternative to consider: Although static linking does solve a number of user headaches, one negative side effect is it increases the size of the binary. (Less so than a full dynamic libBitcoin install, however, so only really a problem if user keeps multiple copies or versions of witness node on a remote machine or needs to transmit the file over the network repeatedly.) One potential other approach to simplifying remote install from gitlab artifacts, would be to make the entire `peerplays_sidechain` plugin an optional compile, disabled by default. If I've understood the code structure correctly, this plugin is the only part of the code that uses LibBitcoin. Also, this plugin is only needed by SON _operators_, not SON _users_. As the SON operators are a small minority, and they already undertake additional technical challenges to run a SON, it seems we could save headaches for most users by requiring only this small subset to ever need or build libBitcoin. Would this latter approach be preferable, from a dev perspective?

prandnum commented

2024-01-26 15:10:58 +00:00

(Migrated from gitlab.com)

@vampik could you please provide the verification steps.

vampik commented

2024-01-26 15:14:17 +00:00

(Migrated from gitlab.com)

We wouldn't merge this MR in its current state.

This pull request can be merged automatically.

You are not authorized to merge this pull request.

View command line instructions