Closed ghost closed 5 months ago
How are you going about upgrading Boost? I can't compile
Also, have you tried GUIX with this?
How are you going about upgrading Boost? I can't compile
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
I am getting further build errors now & can't compile:
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.
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.
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.
How are you going about upgrading Boost? I can't compile
Also, have you tried GUIX with this?
Yes. There is nothing changed in GUIX. Because Guix already use boost 1.84.0. because of pr194
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:
Changed line to
AC_PATH_PROGS([PYTHON], [python3.9 python3.10 python3.11 python3.12 python3 python])
How are you going about upgrading Boost? I can't compile 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.
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
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
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.
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.
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:Changed line to
AC_PATH_PROGS([PYTHON], [python3.9 python3.10 python3.11 python3.12 python3 python])
I pulled this change from here, am testing python functional tests now:
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.
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
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
The native route took 1 min, 58 seconds (dependencies already manually configured before):
./autogen.sh
./configure
make -j 8
make deploy
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
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.
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: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
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
make HOST=x86_64-linux-gnu -j 8
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.
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. :)
FYI all Python Functional tests pass as well.
utACK
sqlite3 >= 3.45.2 https://github.com/DigiByte-Core/digibyte/pull/204
Boost >= 1.84.0 https://github.com/DigiByte-Core/digibyte/pull/194