Closed BenWibking closed 6 months ago
@BenWibking whenever I build on a mac with "special stuff" installed, I need to take explicit action to prevent build_visit
from using any of that. To do that, I do something like...
env PATH=/usr/local/bin:/usr/bin:/bin:/sbin build_visit
Not sure how we can defend against this - other than requesting that homebrew is not in PATH before using build_visit. Should we document this in some way?
Not sure how we can defend against this - other than requesting that homebrew is not in PATH before using build_visit. Should we document this in some way?
Maybe it could check whether the compiler identifies itself as "Apple clang" (and abort if not) when building on Mac?
$ ~ env PATH=/usr/local/bin:/usr/bin:/bin:/sbin clang -v
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: arm64-apple-darwin23.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ ~ clang -v
Homebrew clang version 17.0.6
Target: arm64-apple-darwin23.4.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
@BenWibking whenever I build on a mac with "special stuff" installed, I need to take explicit action to prevent
build_visit
from using any of that. To do that, I do something like...env PATH=/usr/local/bin:/usr/bin:/bin:/sbin build_visit
Strangely, I can't get it to build qwt
with this command. If I do brew uninstall llvm
and then build, it works, but setting the above PATH leads to a strange compiler error when building qwt.
Can you share the qwt build issue?
We are in a constant battle with packages that poke around the file system and find random installs. We try to be as explicit as we can about pointing our builds to our TPLs to avoid this, but is a challenge.
@cyrush This is the log for the qwt build error: build_visit_log.zip
I built with: env PATH=/usr/local/bin:/usr/bin:/bin:/sbin ./build_visit --qt6 --boxlib --adios2 --blosc2
I used the rel-mcm86-22mar24-more-341-darwin-fixes
branch with the following diff (copied from the main branch):
diff --git a/src/tools/dev/scripts/bv_support/bv_main.sh b/src/tools/dev/scripts/bv_support/bv_main.sh
index c0f16d5988..cd5f70401a 100644
--- a/src/tools/dev/scripts/bv_support/bv_main.sh
+++ b/src/tools/dev/scripts/bv_support/bv_main.sh
@@ -365,6 +365,14 @@ function initialize_build_visit()
export MACOSX_DEPLOYMENT_TARGET=11.0
elif [[ ${VER_MAJOR} == 21 ]] ; then
export MACOSX_DEPLOYMENT_TARGET=12.0
+ elif [[ ${VER_MAJOR} == 22 ]] ; then
+ export MACOSX_DEPLOYMENT_TARGET=13.0
+ elif [[ ${VER_MAJOR} == 23 ]] ; then
+ # keep 13 (ventura)
+ export MACOSX_DEPLOYMENT_TARGET=13.0
+ elif [[ ${VER_MAJOR} == 24 ]] ; then
+ # keep 13 (ventura)
+ export MACOSX_DEPLOYMENT_TARGET=13.0
else
echo "Unsupported Darwin major version, ${VER_MAJOR}."
echo "Maybe add a new case for MACOSX_DEPLOYMENT_TARGET"
Just after I posted that, I did some more digging and I think it's a CMake environment variable issue. Testing a possible fix now.
Ok, that was caused by having CMAKE_GENERATOR
set in my environment.
I fixed that, but now I'm getting a strange, apparently unrelated issue building Python:
checking if python is installed
python is not installed
Building Python (~3 minutes)
prepare_build_dir: Python-3.9.18 Python-3.9.18.tgz
Found Python-3.9.18 . . .
Configuring Python
+ ./configure 'OPT=-fno-common -fexceptions -O2' CXX=clang++ CC=clang 'LDFLAGS=-Wl,-rpath,/Users/benwibking/visIt/src/tools/dev/scripts/third_party/python/3.9.18/arm-apple-darwin23_clang/lib/ -pthread -L/Users/benwibking/visIt/src/tools/dev/scripts/third_party/zlib/1.2.13/arm-apple-darwin23_clang/lib' 'CPPFLAGS= -I/Users/benwibking/visIt/src/tools/dev/scripts/third_party/zlib/1.2.13/arm-apple-darwin23_clang/include' --enable-shared --prefix=/Users/benwibking/visIt/src/tools/dev/scripts/third_party/python/3.9.18/arm-apple-darwin23_clang --disable-ipv6
./bv_support//bv_python.sh: line 626: ./configure: No such file or directory
+ set +x
Building Python . . . (~3 minutes)
make: *** No targets specified and no makefile found. Stop.
Python build failed. Giving up
Unable to build or install Python. Bailing out.
Error in build process. See /Users/benwibking/visIt/src/tools/dev/scripts/build_visit_log for more information. If the error is unclear, please include /Users/benwibking/visIt/src/tools/dev/scripts/build_visit_log and contact the VisIt project via https://visit-help.llnl.gov. You may need to compress the /Users/benwibking/visIt/src/tools/dev/scripts/build_visit_log using a program like gzip so it will fit within the size limits for attachments.
Log file full path: /Users/benwibking/visIt/src/tools/dev/scripts//Users/benwibking/visIt/src/tools/dev/scripts/build_visit_log
Full log: build_visit_log.zip
The log doesn't suggest to me what the issue might be. In absence of another VisIt team member providing a different path forward, I would suggest starting a clean build if you haven't already. Sometimes when libraries fail to build and you restart, VisIt thinks the ones that failed actually succeeded and keeps chugging along, leading to mysterious errors further in the pipeline.
The log doesn't suggest to me what the issue might be. In absence of another VisIt team member providing a different path forward, I would suggest starting a clean build if you haven't already. Sometimes when libraries fail to build and you restart, VisIt thinks the ones that failed actually succeeded and keeps chugging along, leading to mysterious errors further in the pipeline.
Ah... that fixed it. I had to re-clone the repo, as git clean
was not sufficient. This might also have caused the qwt
build issue.
I'm glad. :) Dependencies can end up in our third party directory even if they fail to build, which confuses build_visit
. Sorry about that and glad you are set. Can we close the ticket?
So, I have homebrew on my system and I wind up having to go to great lenghts to ensure build_visit
doesn't find it. So, I do something like..
env PATH=/usr/local/bin:/usr/bin:/bin:/sbin build_visit
And, that only partially works because several of the packages build_visit
builds go off looking for stuff in common places and then finding things I don't want. Then, I have to go into those specific packages and find the knobs to disable that search or to force it to find the stuff where I want it to find it.
All that said, I am working on an update to build_visit
in #19412 that appears to work in the presence of homebrew on my Intel macOS 12.7.4 system.
I'm glad. :) Dependencies can end up in our third party directory even if they fail to build, which confuses
build_visit
. Sorry about that and glad you are set. Can we close the ticket?
Yes, the build finally finished successfully (using env PATH=/usr/local/bin:/usr/bin:/bin:/sbin ./build_visit --qt6 --boxlib --adios2 --blosc2
when starting from scratch).
Since things appear to compile on my system now, I'll close this ticket. However, I am still seeing the runtime issue in https://github.com/visit-dav/visit/issues/19415 that prevents the main viewer windows from opening.
Describe the bug
Compiling VisIt 3.4.1RC on macOS 14 fails when building qt6.
This appears to be because if LLVM is installed via Homebrew, build_visit uses libtool from the Homebrew installation, rather than from XCode.
This may be the same issue: https://github.com/telegramdesktop/tdesktop/issues/25058
To Reproduce
Steps to reproduce the behavior. For example:
./build_visit --qt6
The actual error from the logfile is:
Desktop
Additional context
Logfile: build_visit_log.zip