I recently first attempted to build my project with the AMD Math Libraries instead of the system default BLAS/LAPACK or Intel's MKL and I got this error.
In file included from ~/opt/chapel/runtime/etc/rtmain.c:24:
In file included from ~/opt/chapel/runtime/include/stdchpl.h:51:
In file included from ~/opt/chapel/runtime/include/chpl-file-utils.h:24:
~/opt/chapel/runtime/include/qio/qio_error.h:33:13: error: typedef redefinition with different types ('int' vs 'enum err_t')
typedef int err_t;
^
/opt/AMD/aocl/aocl-linux-aocc-3.1.0/include/cblas.h:2268:3: note: previous definition is here
} err_t;
^
1 error generated.
error: error running clang during code generation
Does anyone have any clue about how to solve this? I intent on testing compilation with the AMD Compiler next, which is based on LLVM 13, but I don´t expect to have any issues with that.
chpl --version
chpl version 1.26.0
built with LLVM version 13.0.1
Copyright 2020-2022 Hewlett Packard Enterprise Development LP
Copyright 2004-2019 Cray Inc.
(See LICENSE file for more details)
That looks like we're assuming the name err_t is okay to use in our
runtime code, when it doesn't appear to be compatible with that version
of CBLAS. I dunno that this is something you'd be able to resolve
yourself without some trouble, so I'd recommend logging it as an issue
on our Github page.
@RedHatTurtle : I was curious whether it would be easy for you to rename the Chapel err_t variable to work around this, but in checking, it felt just as easy to do it myself. Would you see if the following branch resolves your issue: GitHub - bradcray/chapel at rename-err_t
I had a problem with my system's LLVM updating to 14.0 last night so I tried building Chapel with the bundled LLVM and using GNU compilers but I got several "file not found" errors on includes. It's also happening with the 1.26 release, is the include flag in the compilation command supposed to be -I.?
/home/fabio/opt/chapel-bradcray-rename-err_t/chapel-rename-err_t/third-party/llvm/install/linux64-x86_64-gnu/bin/clang++ -c -o obj/util/rune.o -std=c++11 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I. -DNDEBUG -O3 -DNDEBUG util/rune.cc
/home/fabio/opt/chapel-bradcray-rename-err_t/chapel-rename-err_t/third-party/llvm/install/linux64-x86_64-gnu/bin/clang++ -c -o obj/util/strutil.o -std=c++11 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I. -DNDEBUG -O3 -DNDEBUG util/strutil.cc
/home/fabio/opt/chapel-bradcray-rename-err_t/chapel-rename-err_t/third-party/llvm/install/linux64-x86_64-gnu/bin/clang++ -c -o obj/re2/bitstate.o -std=c++11 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I. -DNDEBUG -O3 -DNDEBUG re2/bitstate.cc
/home/fabio/opt/chapel-bradcray-rename-err_t/chapel-rename-err_t/third-party/llvm/install/linux64-x86_64-gnu/bin/clang++ -c -o obj/re2/compile.o -std=c++11 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I. -DNDEBUG -O3 -DNDEBUG re2/compile.cc
/home/fabio/opt/chapel-bradcray-rename-err_t/chapel-rename-err_t/third-party/llvm/install/linux64-x86_64-gnu/bin/clang++ -c -o obj/re2/dfa.o -std=c++11 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I. -DNDEBUG -O3 -DNDEBUG re2/dfa.cc
/home/fabio/opt/chapel-bradcray-rename-err_t/chapel-rename-err_t/third-party/llvm/install/linux64-x86_64-gnu/bin/clang++ -c -o obj/re2/filtered_re2.o -std=c++11 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I. -DNDEBUG -O3 -DNDEBUG re2/filtered_re2.cc
/home/fabio/opt/chapel-bradcray-rename-err_t/chapel-rename-err_t/third-party/llvm/install/linux64-x86_64-gnu/bin/clang++ -c -o obj/re2/file_strings.o -std=c++11 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I. -DNDEBUG -O3 -DNDEBUG re2/file_strings.cc
/home/fabio/opt/chapel-bradcray-rename-err_t/chapel-rename-err_t/third-party/llvm/install/linux64-x86_64-gnu/bin/clang++ -c -o obj/re2/mimics_pcre.o -std=c++11 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I. -DNDEBUG -O3 -DNDEBUG re2/mimics_pcre.cc
/home/fabio/opt/chapel-bradcray-rename-err_t/chapel-rename-err_t/third-party/llvm/install/linux64-x86_64-gnu/bin/clang++ -c -o obj/re2/onepass.o -std=c++11 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I. -DNDEBUG -O3 -DNDEBUG re2/onepass.cc
/home/fabio/opt/chapel-bradcray-rename-err_t/chapel-rename-err_t/third-party/llvm/install/linux64-x86_64-gnu/bin/clang++ -c -o obj/re2/nfa.o -std=c++11 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I. -DNDEBUG -O3 -DNDEBUG re2/nfa.cc
In file included from re2/filtered_re2.cc:5:
./re2/filtered_re2.h:24:10: fatal error: 'memory' file not found
#include <memory>
^~~~~~~~
In file included from re2/file_strings.cc:1:
re2/stringpiece.h:29:10: fatal error: 'algorithm' file not found
#include <algorithm>
^~~~~~~~~~~
re2/compile.cc:13:10: fatal error: 'unordered_map' file not found
#include <unordered_map>
^~~~~~~~~~~~~~~
re2/bitstate.cc:23:10: fatal error: 'limits' file not found
#include <limits>
^~~~~~~~
In file included from util/strutil.cc:8:
./util/strutil.h:8:10: fatal error: 'string' file not found
#include <string>
^~~~~~~~
re2/onepass.cc:55:10: fatal error: 'algorithm' file not found
#include <algorithm>
^~~~~~~~~~~
re2/dfa.cc:28:10: fatal error: 'algorithm' file not found
#include <algorithm>
^~~~~~~~~~~
re2/nfa.cc:29:10: fatal error: 'algorithm' file not found
#include <algorithm>
^~~~~~~~~~~
In file included from re2/mimics_pcre.cc:26:
./util/logging.h:13:10: fatal error: 'ostream' file not found
#include <ostream>
^~~~~~~~~
Arriving late to today's exchange, but a few comments:
note that LLVM 14 isn't yet supported by Chapel, so even if your system install went well, we wouldn't be able to make use of it.
if you're working from the same source tree as before, and your C++ compiler is generally working well, my first thought was whether there could be anything in the build tree that encoded paths from the previous attempts which are now invalid (?). Trying a make clobber followed by a make (or starting from a fresh unpacking of the Chapel source) would be ways to try this. If this was with fresh source, though, then I don't have any thoughts beyond what Michael has already said.
Well, sorry for the delay but I only managed to solve the build problems today, at least using the bundled LLVM. I think the make clobber might have been the trick to fixing the default paths.
@bradcray The build you linked worked flawlessly with the AMD libraries as far as I can test, thank for the fast fix.
@mppf I'm on openSUSE Tumbleweed so stuff is never really stable. I think I've had this problem of clang not finding the standard libraries months ago with 1.25, didn't know there was a variable for that. Probably gonna be helpfull for the future, thank you.