DigiByte-Core / digibyte

DigiByte Core 7.17.3 - CURRENT (5-12-2021) - 8.22.0 Development
https://digibyte.org
MIT License
98 stars 61 forks source link

Set minimal sqlite3 >= 3.45.2 && Boost >= 1.84.0 #230

Closed ghost closed 5 months ago

ghost commented 6 months ago

sqlite3 >= 3.45.2 https://github.com/DigiByte-Core/digibyte/pull/204

Boost >= 1.84.0 https://github.com/DigiByte-Core/digibyte/pull/194

min

JaredTate commented 5 months ago

How are you going about upgrading Boost? I can't compile

Screenshot 2024-04-09 at 9 00 38 AM

Also, have you tried GUIX with this?

JaredTate commented 5 months ago

How are you going about upgrading Boost? I can't compile

Screenshot 2024-04-09 at 9 00 38 AM

Also, have you tried GUIX with this?

Looks like a simple

brew install boost

That worked to get latest 1.84 and upgrade.

Also running

brew upgrade
brew update
JaredTate commented 5 months ago

I am getting further build errors now & can't compile:

Screenshot 2024-04-09 at 9 36 12 AM

JaredTate commented 5 months ago

After a fresh clone and reboot I can now get it to compile, but now make deploy fails, I think it's a Python env issue.

Screenshot 2024-04-09 at 10 00 05 AM

saltedlolly commented 5 months ago

image

I have just tested this on Apple Silicon. It compiled fine and runs.

@JaredTate I think you are not using the depends folder, if you have to use brew.

JaredTate commented 5 months ago

image

I have just tested this on Apple Silicon. It compiled fine and runs.

@jaredctate I think you are not using the depends folder, if you have to use brew.

Yes it compiled for me too, it was make deploy to create the dmg that was failing, I just fixed it, we need to bump python -v in configure.ac.

ghost commented 5 months ago

How are you going about upgrading Boost? I can't compile

Screenshot 2024-04-09 at 9 00 38 AM

Also, have you tried GUIX with this?

Screenshot from 2024-04-09 18-01-26

Yes. There is nothing changed in GUIX. Because Guix already use boost 1.84.0. because of pr194

JaredTate commented 5 months ago

I had to bump python version in this line in configure.ac to get things to work locally with my Python env for make deploy to work:

https://github.com/DigiByte-Core/digibyte/blob/99ed14a35cd31163a311ec98a96769b3c248443c/configure.ac#L104

Changed line to

AC_PATH_PROGS([PYTHON], [python3.9 python3.10 python3.11 python3.12 python3 python])

Screenshot 2024-04-09 at 10 12 20 AM

ghost commented 5 months ago

How are you going about upgrading Boost? I can't compile Screenshot 2024-04-09 at 9 00 38 AM Also, have you tried GUIX with this?

Lookis like a simple

brew install boost

That worked to get latest 1.84 and upgrade.

Also running

brew upgrade
brew update

Why not using local depends folder? With include boost 1.84.0 since pr194.

JaredTate commented 5 months ago

Why not using local depends folder? With include boost 1.84.0 since pr194.

I have found for speed of testing and development, to rapidly test changes using this build instructions locally: https://github.com/DigiByte-Core/digibyte/blob/develop/doc/build-osx.md

ghost commented 5 months ago

Why not using local depends folder? With include boost 1.84.0 since pr194.

I have found for speed of testing and development, to rapidly test changes using this build instructions locally: https://github.com/DigiByte-Core/digibyte/blob/develop/doc/build-osx.md


Use this. ( Linux example )

cd digibyte/depends

//Linux make HOST=x86_64-linux-gnu -j12

cd ..

./autogen.sh

CONFIG_SITE=$PWD/depends/x86_64-linux-gnu/share/config.site ./configure

make -j12


//Windows make HOST=x86_64-w64-mingw32 -j12

//Windows CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure

JaredTate commented 5 months ago

Why not using local depends folder? With include boost 1.84.0 since pr194.

I have found for speed of testing and development, to rapidly test changes using this build instructions locally: https://github.com/DigiByte-Core/digibyte/blob/develop/doc/build-osx.md

Use this. ( Linux example )

cd digibyte/depends

//Linux make HOST=x86_64-linux-gnu -j12

cd ..

./autogen.sh

CONFIG_SITE=$PWD/depends/x86_64-linux-gnu/share/config.site ./configure

make -j12

//Windows make HOST=x86_64-w64-mingw32 -j12

//Windows CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure

Yes, I am aware & but I am on a Mac. For speed testing & compiling/ testing fixes quicker the traditional local mac build route is faster and I find troubleshooting issues with more flexibility.

ghost commented 5 months ago

Why not using local depends folder? With include boost 1.84.0 since pr194.

I have found for speed of testing and development, to rapidly test changes using this build instructions locally: https://github.com/DigiByte-Core/digibyte/blob/develop/doc/build-osx.md

Use this. ( Linux example ) cd digibyte/depends //Linux make HOST=x86_64-linux-gnu -j12 cd .. ./autogen.sh CONFIG_SITE=$PWD/depends/x86_64-linux-gnu/share/config.site ./configure make -j12 //Windows make HOST=x86_64-w64-mingw32 -j12 //Windows CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure

Yes, I am aware & but I am on a Mac. For speed testing & compiling/ testing fixes quicker the traditional local mac build route is faster and I find troubleshooting issues with more flexibility.

For troubleshooting we obviously always want to use the same libraries. Now you are using the old libraries with PR194 which is what was giving you the problems with this PR - the libraries are not the correct versions.

When we do not change the depends folder between versions, you can always make a backup of it, to save you from having to rebuild it every time. So https://github.com/DigiByte-Core/digibyte/blob/develop/doc/build-osx.md is not faster, and may cause issues with incorrect libraries. By using the depends folder, the libraries will always be the same for every build. This is what GUIX uses.

JaredTate commented 5 months ago

I had to bump python version in this line in configure.ac to get things to work locally with my Python env for make deploy to work:

https://github.com/DigiByte-Core/digibyte/blob/99ed14a35cd31163a311ec98a96769b3c248443c/configure.ac#L104

Changed line to

AC_PATH_PROGS([PYTHON], [python3.9 python3.10 python3.11 python3.12 python3 python])

Screenshot 2024-04-09 at 10 12 20 AM

I pulled this change from here, am testing python functional tests now:

https://github.com/bitcoin/bitcoin/blob/0b4218e43cb1d3e149a0adfbf12aa9b4636f70c3/configure.ac#L122C1-L122C85

JaredTate commented 5 months ago

For troubleshooting it is nice to use the same libraries. Now you are using since PR194 the old libraries. And got problems with this pr. Because of not using the correct libraries. When we not change the depends folder you can always make a backup of it. So https://github.com/DigiByte-Core/digibyte/blob/develop/doc/build-osx.md is not faster

I agree, we need to use same deps, but real world that wont always be case and others will run into issues too. Once I updated my local environment to match, it compiled and I discovered we needed to bump Python V in configure.ac. Real world issue.

Also Mac with depends it is a pain in the arse.. you have to manually extract the SDK because of apple licensing. Why do that when I can already have the built-in xcode SDK functionality native to my OS after I do OSX updates. Much quicker to use build-osx when natively on a mac. Especially when recompiling over and over and over again.

Screenshot 2024-04-09 at 10 40 55 AM

Guess where depends instructions send you, same place as GUIX oSX install: https://github.com/DigiByte-Core/digibyte/blob/develop/contrib/macdeploy/README.md#sdk-extraction

JaredTate commented 5 months ago

Ok, I just timed & tested multiple ways to build several times, running make clean between them. The depends method took me 11 min & 13 seconds from start to finish:

Note you still need to make deploy to build the DMG on Mac with depends which still fails for this commit without the python version bump. For a beginner or 1 time compilation the depends route is for sure faster.

cd depends
make HOST=x86_64-apple-darwin18 -j8
cd ..
./autogen.sh
CONFIG_SITE=$PWD/depends/x86_64-apple-darwin18/share/config.site ./configure
make -j 8
make -deploy

Screenshot 2024-04-09 at 11 06 22 AM

The native route took 1 min, 58 seconds (dependencies already manually configured before):

./autogen.sh
./configure
make -j 8
make deploy

Screenshot 2024-04-09 at 11 42 42 AM

Depends route after the initial host configuration, 2 min, 11 seconds:

./autogen.sh
CONFIG_SITE=$PWD/depends/x86_64-apple-darwin18/share/config.site ./configure
make -j 8
make deploy

Screenshot 2024-04-09 at 11 50 19 AM

So to conclude, depends route is slightly slower for me after a make clean but for ease of use typing ./configure way easier vs CONFIG_SITE=$PWD/depends/x86_64-apple-darwin18/share/config.site ./configure adds up over time.

JaredTate commented 5 months ago

I had to bump python version in this line in configure.ac to get things to work locally with my Python env for make deploy to work:

https://github.com/DigiByte-Core/digibyte/blob/99ed14a35cd31163a311ec98a96769b3c248443c/configure.ac#L104

Changed line to

AC_PATH_PROGS([PYTHON], [python3.9 python3.10 python3.11 python3.12 python3 python])

This change is still needed to get make deploy to work on Mac for me, even with the depends build process. This is still relying on users' local build env.

./autogen.sh
CONFIG_SITE=$PWD/depends/x86_64-apple-darwin18/share/config.site ./configure
make -j 8
make deploy

Screenshot 2024-04-09 at 11 57 25 AM

JaredTate commented 5 months ago

For the record, another reason I have never relied on depends build process, is that I could never get anything but Apple to build on a Mac. I get various failures when trying to build hosts for Windows or Linux on my Intel Mac:

make HOST=x86_64-w64-mingw32 -j 8

Screenshot 2024-04-09 at 12 05 57 PM

make HOST=x86_64-linux-gnu -j 8

Screenshot 2024-04-09 at 12 13 25 PM

Has anyone ever been able to successfully cross-compile build for Windows & Linux on a Mac? I know there is a reason the final GUIX builds happen inside a Linux Docker container, much easier cross-compilation.

JaredTate commented 5 months ago

ACK. Great work, compiles, runs & make check all tests pass. Learned some valuable insights on this one into some compiler stuff. I definitely need to make sure local build dependencies are up to speed, but that's why configure.ac enforce's deps. :)

Screenshot 2024-04-09 at 12 25 59 PM

FYI all Python Functional tests pass as well.

gto90 commented 5 months ago

utACK