Re: [julia-users] ERROR: Target architecture mismatch
I think this is the actual error: /home1/04179/abean/julia/deps/srccache/llvm-svn/lib/Demangle/ItaniumDemangle.cpp(946): error #303: explicit type is missing ("int" assumed) auto args = db.names.back().move_full(); ^ detected during: instantiation of "const char *parse_unresolved_name(const char *, const char *, C &) [with C=::Db]" at line 3042 instantiation of "const char *parse_expression(const char *, const char *, C &) [with C=::Db]" at line 1520 instantiation of "const char *parse_array_type(const char *, const char *, C &) [with C=::Db]" at line 1707 instantiation of "const char *parse_type(const char *, const char *, C &) [with C=::Db]" at line 3866 instantiation of "const char *parse_special_name(const char *, const char *, C &) [with C=::Db]" at line 4026 instantiation of "const char *parse_encoding(const char *, const char *, C &) [with C=::Db]" at line 4185 instantiation of "void demangle(const char *, const char *, C &, int &) [with C=::Db]" at line 4267 /home1/04179/abean/julia/deps/srccache/llvm-svn/lib/Demangle/ItaniumDemangle.cpp(948): error: namespace "std" has no member "move" db.names.back().first += std::move(args); ^ detected during: instantiation of "const char *parse_unresolved_name(const char *, const char *, C &) [with C=::Db]" at line 3042 instantiation of "const char *parse_expression(const char *, const char *, C &) [with C=::Db]" at line 1520 instantiation of "const char *parse_array_type(const char *, const char *, C &) [with C=::Db]" at line 1707 instantiation of "const char *parse_type(const char *, const char *, C &) [with C=::Db]" at line 3866 instantiation of "const char *parse_special_name(const char *, const char *, C &) [with C=::Db]" at line 4026 instantiation of "const char *parse_encoding(const char *, const char *, C &) [with C=::Db]" at line 4185 instantiation of "void demangle(const char *, const char *, C &, int &) [with C=::Db]" at line 4267 /home1/04179/abean/julia/deps/srccache/llvm-svn/lib/Demangle/ItaniumDemangle.cpp(3476): error: namespace "std" has no member "move" db.names.push_back(std::move(args)); ^ detected during: instantiation of "const char *parse_base_unresolved_name(const char *, const char *, C &) [with C=::Db]" at line 1000 instantiation of "const char *parse_unresolved_name(const char *, const char *, C &) [with C=::Db]" at line 3042 instantiation of "const char *parse_expression(const char *, const char *, C &) [with C=::Db]" at line 1520 instantiation of "const char *parse_array_type(const char *, const char *, C &) [with C=::Db]" at line 1707 instantiation of "const char *parse_type(const char *, const char *, C &) [with C=::Db]" at line 3866 instantiation of "const char *parse_special_name(const char *, const char *, C &) [with C=::Db]" at line 4026 instantiation of "const char *parse_encoding(const char *, const char *, C &) [with C=::Db]" at line 4185 instantiation of "void demangle(const char *, const char *, C &, int &) [with C=::Db]" at line 4267 compilation aborted for /home1/04179/abean/julia/deps/srccache/llvm-svn/lib/Demangle/ItaniumDemangle.cpp (code 4) make[4]: *** [lib/Demangle/CMakeFiles/LLVMDemangle.dir/ItaniumDemangle.cpp.o] Error 4 make[3]: *** [lib/Demangle/CMakeFiles/LLVMDemangle.dir/all] Error 2 make[2]: *** [all] Error 2 make[1]: *** [scratch/llvm-svn/build_Release/build-compiled] Error 2 make: *** [julia-deps] Error 2 On Saturday, October 15, 2016 at 1:54:54 PM UTC-5, ABB wrote: > > How smart of me. I was confused because it looked like the version of > curl was the correct one. I'll run it again and see where it messes up > this time. Thanks for fixing that. > > On Saturday, October 15, 2016 at 1:51:28 PM UTC-5, Erik Schnetter wrote: >> >> You didn't show the actual error message. Debugging is easier if (after >> seeing an error) you re-run with "make -j1", so that the error message >> doesn't scroll away. >> >> -erik >> >> On Sat, Oct 15, 2016 at 1:41 PM, ABB wrote: >> >>> I'm getting a new error. This is with the following make.user: >>> >>> LLVM_VER=svn >>> USEICC=1 >>> USEIFC=1 >>> USE_INTEL_MKL=1 >>> USE_INTEL_MKL_FFT=1 >>> USE_INTEL_LIBM=1 >>> >>> >>> building directly on the (KNL) compute node (in parallel: make -j 68) >>> >>> configure: amending tests/server/Makefile >>> configure: amending tests/libtest/Makefile >>> configure: amending docs/examples/Makefile >>> configure: Configured to build curl/libcurl: >>> >>> curl version: 7.50.1 >>> Host setup: x86_64-unknown-linux-gnu >>> Install prefix: /home1/04179/abean/julia/usr >>>
Re: [julia-users] ERROR: Target architecture mismatch
How smart of me. I was confused because it looked like the version of curl was the correct one. I'll run it again and see where it messes up this time. Thanks for fixing that. On Saturday, October 15, 2016 at 1:51:28 PM UTC-5, Erik Schnetter wrote: > > You didn't show the actual error message. Debugging is easier if (after > seeing an error) you re-run with "make -j1", so that the error message > doesn't scroll away. > > -erik > > On Sat, Oct 15, 2016 at 1:41 PM, ABB > > wrote: > >> I'm getting a new error. This is with the following make.user: >> >> LLVM_VER=svn >> USEICC=1 >> USEIFC=1 >> USE_INTEL_MKL=1 >> USE_INTEL_MKL_FFT=1 >> USE_INTEL_LIBM=1 >> >> >> building directly on the (KNL) compute node (in parallel: make -j 68) >> >> configure: amending tests/server/Makefile >> configure: amending tests/libtest/Makefile >> configure: amending docs/examples/Makefile >> configure: Configured to build curl/libcurl: >> >> curl version: 7.50.1 >> Host setup: x86_64-unknown-linux-gnu >> Install prefix: /home1/04179/abean/julia/usr >> Compiler: icc >> SSL support: enabled (mbedTLS) >> SSH support: enabled (libSSH2) >> zlib support: no (--with-zlib) >> GSS-API support: no (--with-gssapi) >> TLS-SRP support: no (--enable-tls-srp) >> resolver: default (--enable-ares / --enable-threaded-resolver) >> IPv6 support: enabled >> Unix sockets support: enabled >> IDN support: no (--with-{libidn,winidn}) >> Build libcurl:Shared=yes, Static=yes >> Built-in manual: enabled >> --libcurl option: enabled (--disable-libcurl-option) >> Verbose errors: enabled (--disable-verbose) >> SSPI support: no (--enable-sspi) >> ca cert bundle: /etc/pki/tls/certs/ca-bundle.crt >> ca cert path: no >> ca fallback: no >> LDAP support: no (--enable-ldap / --with-ldap-lib / >> --with-lber-lib) >> LDAPS support:no (--enable-ldaps) >> RTSP support: enabled >> RTMP support: no (--with-librtmp) >> metalink support: no (--with-libmetalink) >> PSL support: no (--with-libpsl) >> HTTP2 support:disabled (--with-nghttp2) >> Protocols:DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS POP3 >> POP3S RTSP SCP SFTP SMTP SMTPS TELNET TFTP >> >> make: *** [julia-deps] Error 2 >> >> >> Does anyone have any advice for this one? I didn't find previous >> discussion of this problem. >> > > > > -- > Erik Schnetter > > http://www.perimeterinstitute.ca/personal/eschnetter/ >
Re: [julia-users] ERROR: Target architecture mismatch
You didn't show the actual error message. Debugging is easier if (after seeing an error) you re-run with "make -j1", so that the error message doesn't scroll away. -erik On Sat, Oct 15, 2016 at 1:41 PM, ABB wrote: > I'm getting a new error. This is with the following make.user: > > LLVM_VER=svn > USEICC=1 > USEIFC=1 > USE_INTEL_MKL=1 > USE_INTEL_MKL_FFT=1 > USE_INTEL_LIBM=1 > > > building directly on the (KNL) compute node (in parallel: make -j 68) > > configure: amending tests/server/Makefile > configure: amending tests/libtest/Makefile > configure: amending docs/examples/Makefile > configure: Configured to build curl/libcurl: > > curl version: 7.50.1 > Host setup: x86_64-unknown-linux-gnu > Install prefix: /home1/04179/abean/julia/usr > Compiler: icc > SSL support: enabled (mbedTLS) > SSH support: enabled (libSSH2) > zlib support: no (--with-zlib) > GSS-API support: no (--with-gssapi) > TLS-SRP support: no (--enable-tls-srp) > resolver: default (--enable-ares / --enable-threaded-resolver) > IPv6 support: enabled > Unix sockets support: enabled > IDN support: no (--with-{libidn,winidn}) > Build libcurl:Shared=yes, Static=yes > Built-in manual: enabled > --libcurl option: enabled (--disable-libcurl-option) > Verbose errors: enabled (--disable-verbose) > SSPI support: no (--enable-sspi) > ca cert bundle: /etc/pki/tls/certs/ca-bundle.crt > ca cert path: no > ca fallback: no > LDAP support: no (--enable-ldap / --with-ldap-lib / > --with-lber-lib) > LDAPS support:no (--enable-ldaps) > RTSP support: enabled > RTMP support: no (--with-librtmp) > metalink support: no (--with-libmetalink) > PSL support: no (--with-libpsl) > HTTP2 support:disabled (--with-nghttp2) > Protocols:DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS POP3 > POP3S RTSP SCP SFTP SMTP SMTPS TELNET TFTP > > make: *** [julia-deps] Error 2 > > > Does anyone have any advice for this one? I didn't find previous > discussion of this problem. > -- Erik Schnetter http://www.perimeterinstitute.ca/personal/eschnetter/
Re: [julia-users] ERROR: Target architecture mismatch
I'm getting a new error. This is with the following make.user: LLVM_VER=svn USEICC=1 USEIFC=1 USE_INTEL_MKL=1 USE_INTEL_MKL_FFT=1 USE_INTEL_LIBM=1 building directly on the (KNL) compute node (in parallel: make -j 68) configure: amending tests/server/Makefile configure: amending tests/libtest/Makefile configure: amending docs/examples/Makefile configure: Configured to build curl/libcurl: curl version: 7.50.1 Host setup: x86_64-unknown-linux-gnu Install prefix: /home1/04179/abean/julia/usr Compiler: icc SSL support: enabled (mbedTLS) SSH support: enabled (libSSH2) zlib support: no (--with-zlib) GSS-API support: no (--with-gssapi) TLS-SRP support: no (--enable-tls-srp) resolver: default (--enable-ares / --enable-threaded-resolver) IPv6 support: enabled Unix sockets support: enabled IDN support: no (--with-{libidn,winidn}) Build libcurl:Shared=yes, Static=yes Built-in manual: enabled --libcurl option: enabled (--disable-libcurl-option) Verbose errors: enabled (--disable-verbose) SSPI support: no (--enable-sspi) ca cert bundle: /etc/pki/tls/certs/ca-bundle.crt ca cert path: no ca fallback: no LDAP support: no (--enable-ldap / --with-ldap-lib / --with-lber-lib) LDAPS support:no (--enable-ldaps) RTSP support: enabled RTMP support: no (--with-librtmp) metalink support: no (--with-libmetalink) PSL support: no (--with-libpsl) HTTP2 support:disabled (--with-nghttp2) Protocols:DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS POP3 POP3S RTSP SCP SFTP SMTP SMTPS TELNET TFTP make: *** [julia-deps] Error 2 Does anyone have any advice for this one? I didn't find previous discussion of this problem.
Re: [julia-users] ERROR: Target architecture mismatch
Ok - thanks for the clarification. I will try to compile on the compute node, not the login node. I will submit a ticket to TACC and ask about cmake too. The version on the compute node is 2.8.11. On Friday, October 14, 2016 at 10:42:51 AM UTC-5, Erik Schnetter wrote: > > Julia runs some of the code it generates as part of its bootstrapping > procedure. That is, traditional cross-compiling won't work. I think there's > a way around it, but it's not trivial. I would avoid this in the beginning. > > -erik > > On Fri, Oct 14, 2016 at 11:28 AM, ABB > > wrote: > >> I was building on the (Haswell) front end. From some of the other issues >> I looked at it appeared that I could specify the architecture even if I was >> not actually building on that kind of system. But that could be totally >> wrong, so I can try it on the KNL node if that's required. >> >> When I put "LLVM_VER := svn" and tried this morning (again on the front >> end) the error I got was: >> >> JULIA_CPU_TARGET = knl >> >> >> lib/CodeGen/SelectionDAG/DAGCombiner.cpp | 13 + >> >> test/CodeGen/X86/negate-shift.ll | 16 >> >> 2 files changed, 17 insertions(+), 12 deletions(-) >> >> CMake Error at CMakeLists.txt:3 (cmake_minimum_required): >> >> CMake 3.4.3 or higher is required. You are running version 2.8.11 >> >> >> >> -- Configuring incomplete, errors occurred! >> >> make[1]: *** [build/llvm-svn/build_Release/CMakeCache.txt] Error 1 >> >> make: *** [julia-deps] Error 2 >> >> >> >> >> On Friday, October 14, 2016 at 9:51:56 AM UTC-5, Erik Schnetter wrote: >>> >>> Were you building on a KNL node or on the frontend? What architecture >>> did you specify? >>> >>> -erik >>> >>> On Thu, Oct 13, 2016 at 9:38 PM, Valentin Churavy >>> wrote: >>> Since KNL is just a new platform the default version of the LLVM compiler that Julia is based on does not support it properly. During our testing at MIT we found that we needed to switch to the current upstream of LLVM (or if anybody reads this at a later time LLVM 4.0) You can do that by putting LLVM_VER:=svn into your Make.user. - Valentin On Friday, 14 October 2016 09:55:16 UTC+9, ABB wrote: > > Sigh... build failed. I'm including the last part that worked and the > error message which followed: > > JULIA usr/lib/julia/inference.ji > essentials.jl > generator.jl > reflection.jl > options.jl > promotion.jl > tuple.jl > range.jl > expr.jl > error.jl > bool.jl > number.jl > int.jl > > signal (4): Illegal instruction > while loading int.jl, in expression starting on line 193 > ! at ./bool.jl:16 > jl_call_method_internal at > /home1/04179/abean/julia/src/julia_internal.h:189 > jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 > anonymous at ./ (unknown line) > jl_call_method_internal at > /home1/04179/abean/julia/src/julia_internal.h:189 > jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:569 > jl_parse_eval_all at /home1/04179/abean/julia/src/ast.c:717 > jl_load at /home1/04179/abean/julia/src/toplevel.c:596 > jl_load_ at /home1/04179/abean/julia/src/toplevel.c:605 > include at ./boot.jl:231 > jl_call_method_internal at > /home1/04179/abean/julia/src/julia_internal.h:189 > jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 > do_call at /home1/04179/abean/julia/src/interpreter.c:66 > eval at /home1/04179/abean/julia/src/interpreter.c:190 > jl_interpret_toplevel_expr at > /home1/04179/abean/julia/src/interpreter.c:31 > jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:558 > jl_eval_module_expr at /home1/04179/abean/julia/src/toplevel.c:196 > jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:465 > jl_toplevel_eval at /home1/04179/abean/julia/src/toplevel.c:580 > jl_toplevel_eval_in_warn at /home1/04179/abean/julia/src/builtins.c:590 > jl_toplevel_eval_in at /home1/04179/abean/julia/src/builtins.c:556 > eval at ./boot.jl:234 > jl_call_method_internal at > /home1/04179/abean/julia/src/julia_internal.h:189 > jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 > do_call at /home1/04179/abean/julia/src/interpreter.c:66 > eval at /home1/04179/abean/julia/src/interpreter.c:190 > jl_interpret_toplevel_expr at > /home1/04179/abean/julia/src/interpreter.c:31 > jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:558 > jl_parse_eval_all at /home1/04179/abean/julia/src/ast.c:717 > jl_load at /home1/04179/abean/julia/src/toplevel.c:596 > exec_program at /home1/04179/abean/julia/ui/repl.c:66 > true_main at /home1/04179/abean/julia/ui/repl.c:119 > main at /home1/04179/abean/julia/ui/repl.c:232 > __libc_start_main at /usr/lib64/libc.so.6 (unknown line) > unknown function (ip: 0x
Re: [julia-users] ERROR: Target architecture mismatch
Julia runs some of the code it generates as part of its bootstrapping procedure. That is, traditional cross-compiling won't work. I think there's a way around it, but it's not trivial. I would avoid this in the beginning. -erik On Fri, Oct 14, 2016 at 11:28 AM, ABB wrote: > I was building on the (Haswell) front end. From some of the other issues > I looked at it appeared that I could specify the architecture even if I was > not actually building on that kind of system. But that could be totally > wrong, so I can try it on the KNL node if that's required. > > When I put "LLVM_VER := svn" and tried this morning (again on the front > end) the error I got was: > > JULIA_CPU_TARGET = knl > > > lib/CodeGen/SelectionDAG/DAGCombiner.cpp | 13 + > > test/CodeGen/X86/negate-shift.ll | 16 > > 2 files changed, 17 insertions(+), 12 deletions(-) > > CMake Error at CMakeLists.txt:3 (cmake_minimum_required): > > CMake 3.4.3 or higher is required. You are running version 2.8.11 > > > > -- Configuring incomplete, errors occurred! > > make[1]: *** [build/llvm-svn/build_Release/CMakeCache.txt] Error 1 > > make: *** [julia-deps] Error 2 > > > > > On Friday, October 14, 2016 at 9:51:56 AM UTC-5, Erik Schnetter wrote: >> >> Were you building on a KNL node or on the frontend? What architecture did >> you specify? >> >> -erik >> >> On Thu, Oct 13, 2016 at 9:38 PM, Valentin Churavy >> wrote: >> >>> Since KNL is just a new platform the default version of the LLVM >>> compiler that Julia is based on does not support it properly. >>> During our testing at MIT we found that we needed to switch to the >>> current upstream of LLVM (or if anybody reads this at a later time LLVM 4.0) >>> You can do that by putting >>> LLVM_VER:=svn >>> into your Make.user. >>> >>> - Valentin >>> >>> On Friday, 14 October 2016 09:55:16 UTC+9, ABB wrote: Sigh... build failed. I'm including the last part that worked and the error message which followed: JULIA usr/lib/julia/inference.ji essentials.jl generator.jl reflection.jl options.jl promotion.jl tuple.jl range.jl expr.jl error.jl bool.jl number.jl int.jl signal (4): Illegal instruction while loading int.jl, in expression starting on line 193 ! at ./bool.jl:16 jl_call_method_internal at /home1/04179/abean/julia/src/j ulia_internal.h:189 jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 anonymous at ./ (unknown line) jl_call_method_internal at /home1/04179/abean/julia/src/j ulia_internal.h:189 jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:569 jl_parse_eval_all at /home1/04179/abean/julia/src/ast.c:717 jl_load at /home1/04179/abean/julia/src/toplevel.c:596 jl_load_ at /home1/04179/abean/julia/src/toplevel.c:605 include at ./boot.jl:231 jl_call_method_internal at /home1/04179/abean/julia/src/j ulia_internal.h:189 jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 do_call at /home1/04179/abean/julia/src/interpreter.c:66 eval at /home1/04179/abean/julia/src/interpreter.c:190 jl_interpret_toplevel_expr at /home1/04179/abean/julia/src/i nterpreter.c:31 jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:558 jl_eval_module_expr at /home1/04179/abean/julia/src/toplevel.c:196 jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:465 jl_toplevel_eval at /home1/04179/abean/julia/src/toplevel.c:580 jl_toplevel_eval_in_warn at /home1/04179/abean/julia/src/builtins.c:590 jl_toplevel_eval_in at /home1/04179/abean/julia/src/builtins.c:556 eval at ./boot.jl:234 jl_call_method_internal at /home1/04179/abean/julia/src/j ulia_internal.h:189 jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 do_call at /home1/04179/abean/julia/src/interpreter.c:66 eval at /home1/04179/abean/julia/src/interpreter.c:190 jl_interpret_toplevel_expr at /home1/04179/abean/julia/src/i nterpreter.c:31 jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:558 jl_parse_eval_all at /home1/04179/abean/julia/src/ast.c:717 jl_load at /home1/04179/abean/julia/src/toplevel.c:596 exec_program at /home1/04179/abean/julia/ui/repl.c:66 true_main at /home1/04179/abean/julia/ui/repl.c:119 main at /home1/04179/abean/julia/ui/repl.c:232 __libc_start_main at /usr/lib64/libc.so.6 (unknown line) unknown function (ip: 0x401928) Allocations: 100373 (Pool: 100371; Big: 2); GC: 0 /bin/sh: line 1: 15078 Illegal instruction /home1/04179/abean/julia/usr/bin/julia-debug -C knl --output-ji /home1/04179/abean/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl make[1]: *** [/home1/04179/abean/julia/usr/lib/julia/inference.ji] Error 132 make: *** [julia-inference] Error 2 Any advice
Re: [julia-users] ERROR: Target architecture mismatch
I was building on the (Haswell) front end. From some of the other issues I looked at it appeared that I could specify the architecture even if I was not actually building on that kind of system. But that could be totally wrong, so I can try it on the KNL node if that's required. When I put "LLVM_VER := svn" and tried this morning (again on the front end) the error I got was: JULIA_CPU_TARGET = knl lib/CodeGen/SelectionDAG/DAGCombiner.cpp | 13 + test/CodeGen/X86/negate-shift.ll | 16 2 files changed, 17 insertions(+), 12 deletions(-) CMake Error at CMakeLists.txt:3 (cmake_minimum_required): CMake 3.4.3 or higher is required. You are running version 2.8.11 -- Configuring incomplete, errors occurred! make[1]: *** [build/llvm-svn/build_Release/CMakeCache.txt] Error 1 make: *** [julia-deps] Error 2 On Friday, October 14, 2016 at 9:51:56 AM UTC-5, Erik Schnetter wrote: > > Were you building on a KNL node or on the frontend? What architecture did > you specify? > > -erik > > On Thu, Oct 13, 2016 at 9:38 PM, Valentin Churavy > wrote: > >> Since KNL is just a new platform the default version of the LLVM compiler >> that Julia is based on does not support it properly. >> During our testing at MIT we found that we needed to switch to the >> current upstream of LLVM (or if anybody reads this at a later time LLVM 4.0) >> You can do that by putting >> LLVM_VER:=svn >> into your Make.user. >> >> - Valentin >> >> On Friday, 14 October 2016 09:55:16 UTC+9, ABB wrote: >>> >>> Sigh... build failed. I'm including the last part that worked and the >>> error message which followed: >>> >>> JULIA usr/lib/julia/inference.ji >>> essentials.jl >>> generator.jl >>> reflection.jl >>> options.jl >>> promotion.jl >>> tuple.jl >>> range.jl >>> expr.jl >>> error.jl >>> bool.jl >>> number.jl >>> int.jl >>> >>> signal (4): Illegal instruction >>> while loading int.jl, in expression starting on line 193 >>> ! at ./bool.jl:16 >>> jl_call_method_internal at >>> /home1/04179/abean/julia/src/julia_internal.h:189 >>> jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 >>> anonymous at ./ (unknown line) >>> jl_call_method_internal at >>> /home1/04179/abean/julia/src/julia_internal.h:189 >>> jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:569 >>> jl_parse_eval_all at /home1/04179/abean/julia/src/ast.c:717 >>> jl_load at /home1/04179/abean/julia/src/toplevel.c:596 >>> jl_load_ at /home1/04179/abean/julia/src/toplevel.c:605 >>> include at ./boot.jl:231 >>> jl_call_method_internal at >>> /home1/04179/abean/julia/src/julia_internal.h:189 >>> jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 >>> do_call at /home1/04179/abean/julia/src/interpreter.c:66 >>> eval at /home1/04179/abean/julia/src/interpreter.c:190 >>> jl_interpret_toplevel_expr at >>> /home1/04179/abean/julia/src/interpreter.c:31 >>> jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:558 >>> jl_eval_module_expr at /home1/04179/abean/julia/src/toplevel.c:196 >>> jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:465 >>> jl_toplevel_eval at /home1/04179/abean/julia/src/toplevel.c:580 >>> jl_toplevel_eval_in_warn at /home1/04179/abean/julia/src/builtins.c:590 >>> jl_toplevel_eval_in at /home1/04179/abean/julia/src/builtins.c:556 >>> eval at ./boot.jl:234 >>> jl_call_method_internal at >>> /home1/04179/abean/julia/src/julia_internal.h:189 >>> jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 >>> do_call at /home1/04179/abean/julia/src/interpreter.c:66 >>> eval at /home1/04179/abean/julia/src/interpreter.c:190 >>> jl_interpret_toplevel_expr at >>> /home1/04179/abean/julia/src/interpreter.c:31 >>> jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:558 >>> jl_parse_eval_all at /home1/04179/abean/julia/src/ast.c:717 >>> jl_load at /home1/04179/abean/julia/src/toplevel.c:596 >>> exec_program at /home1/04179/abean/julia/ui/repl.c:66 >>> true_main at /home1/04179/abean/julia/ui/repl.c:119 >>> main at /home1/04179/abean/julia/ui/repl.c:232 >>> __libc_start_main at /usr/lib64/libc.so.6 (unknown line) >>> unknown function (ip: 0x401928) >>> Allocations: 100373 (Pool: 100371; Big: 2); GC: 0 >>> /bin/sh: line 1: 15078 Illegal instruction >>> /home1/04179/abean/julia/usr/bin/julia-debug -C knl --output-ji >>> /home1/04179/abean/julia/usr/lib/julia/inference.ji --startup-file=no >>> coreimg.jl >>> make[1]: *** [/home1/04179/abean/julia/usr/lib/julia/inference.ji] Error >>> 132 >>> make: *** [julia-inference] Error 2 >>> >>> >>> >>> Any advice for debugging that? I don't find any previous issues which >>> are helpful. >>> >>> Thanks - >>> >>> Austin >>> >>> On Thursday, October 13, 2016 at 1:49:24 PM UTC-5, ABB wrote: Awesome. Thanks. I'll try it again then. I appreciate the help. (Austin is also my name. I save space in my memory by going to school at, living in and being a guy with the same name.) >
Re: [julia-users] ERROR: Target architecture mismatch
Were you building on a KNL node or on the frontend? What architecture did you specify? -erik On Thu, Oct 13, 2016 at 9:38 PM, Valentin Churavy wrote: > Since KNL is just a new platform the default version of the LLVM compiler > that Julia is based on does not support it properly. > During our testing at MIT we found that we needed to switch to the current > upstream of LLVM (or if anybody reads this at a later time LLVM 4.0) > You can do that by putting > LLVM_VER:=svn > into your Make.user. > > - Valentin > > On Friday, 14 October 2016 09:55:16 UTC+9, ABB wrote: >> >> Sigh... build failed. I'm including the last part that worked and the >> error message which followed: >> >> JULIA usr/lib/julia/inference.ji >> essentials.jl >> generator.jl >> reflection.jl >> options.jl >> promotion.jl >> tuple.jl >> range.jl >> expr.jl >> error.jl >> bool.jl >> number.jl >> int.jl >> >> signal (4): Illegal instruction >> while loading int.jl, in expression starting on line 193 >> ! at ./bool.jl:16 >> jl_call_method_internal at /home1/04179/abean/julia/src/j >> ulia_internal.h:189 >> jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 >> anonymous at ./ (unknown line) >> jl_call_method_internal at /home1/04179/abean/julia/src/j >> ulia_internal.h:189 >> jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:569 >> jl_parse_eval_all at /home1/04179/abean/julia/src/ast.c:717 >> jl_load at /home1/04179/abean/julia/src/toplevel.c:596 >> jl_load_ at /home1/04179/abean/julia/src/toplevel.c:605 >> include at ./boot.jl:231 >> jl_call_method_internal at /home1/04179/abean/julia/src/j >> ulia_internal.h:189 >> jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 >> do_call at /home1/04179/abean/julia/src/interpreter.c:66 >> eval at /home1/04179/abean/julia/src/interpreter.c:190 >> jl_interpret_toplevel_expr at /home1/04179/abean/julia/src/i >> nterpreter.c:31 >> jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:558 >> jl_eval_module_expr at /home1/04179/abean/julia/src/toplevel.c:196 >> jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:465 >> jl_toplevel_eval at /home1/04179/abean/julia/src/toplevel.c:580 >> jl_toplevel_eval_in_warn at /home1/04179/abean/julia/src/builtins.c:590 >> jl_toplevel_eval_in at /home1/04179/abean/julia/src/builtins.c:556 >> eval at ./boot.jl:234 >> jl_call_method_internal at /home1/04179/abean/julia/src/j >> ulia_internal.h:189 >> jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 >> do_call at /home1/04179/abean/julia/src/interpreter.c:66 >> eval at /home1/04179/abean/julia/src/interpreter.c:190 >> jl_interpret_toplevel_expr at /home1/04179/abean/julia/src/i >> nterpreter.c:31 >> jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:558 >> jl_parse_eval_all at /home1/04179/abean/julia/src/ast.c:717 >> jl_load at /home1/04179/abean/julia/src/toplevel.c:596 >> exec_program at /home1/04179/abean/julia/ui/repl.c:66 >> true_main at /home1/04179/abean/julia/ui/repl.c:119 >> main at /home1/04179/abean/julia/ui/repl.c:232 >> __libc_start_main at /usr/lib64/libc.so.6 (unknown line) >> unknown function (ip: 0x401928) >> Allocations: 100373 (Pool: 100371; Big: 2); GC: 0 >> /bin/sh: line 1: 15078 Illegal instruction >> /home1/04179/abean/julia/usr/bin/julia-debug -C knl --output-ji >> /home1/04179/abean/julia/usr/lib/julia/inference.ji --startup-file=no >> coreimg.jl >> make[1]: *** [/home1/04179/abean/julia/usr/lib/julia/inference.ji] Error >> 132 >> make: *** [julia-inference] Error 2 >> >> >> >> Any advice for debugging that? I don't find any previous issues which >> are helpful. >> >> Thanks - >> >> Austin >> >> On Thursday, October 13, 2016 at 1:49:24 PM UTC-5, ABB wrote: >>> >>> Awesome. Thanks. I'll try it again then. I appreciate the help. >>> >>> (Austin is also my name. I save space in my memory by going to school >>> at, living in and being a guy with the same name.) >>> >>> On Thursday, October 13, 2016 at 1:40:09 PM UTC-5, Erik Schnetter wrote: AB You're speaking of Stampede, if I might guess from the "austin" prefix in your email address. I would treat the old and the new section of the machines as separate, since they are not binary compatible. If you are really interested in the KNL part, then I'd concentrate on these, and use the development mode to always log in, build on, and run on the KNL nodes, and ignore everything else. Mixing different architectures in a single Julia environment is something I'd tackle much later, if at all. Alternatively you can use "haswell" as CPU architecture (instead of "core2" above), which should work both on the front end as well as the KNL nodes. However, this way you will lose speed on the KNL nodes, except for linear algebra operations. -erik On Thu, Oct 13, 2016 at 2:26 PM, ABB wrote: > This is great - thanks for getting back to me so quickly. > > To follow up, I
Re: [julia-users] ERROR: Target architecture mismatch
Since KNL is just a new platform the default version of the LLVM compiler that Julia is based on does not support it properly. During our testing at MIT we found that we needed to switch to the current upstream of LLVM (or if anybody reads this at a later time LLVM 4.0) You can do that by putting LLVM_VER:=svn into your Make.user. - Valentin On Friday, 14 October 2016 09:55:16 UTC+9, ABB wrote: > > Sigh... build failed. I'm including the last part that worked and the > error message which followed: > > JULIA usr/lib/julia/inference.ji > essentials.jl > generator.jl > reflection.jl > options.jl > promotion.jl > tuple.jl > range.jl > expr.jl > error.jl > bool.jl > number.jl > int.jl > > signal (4): Illegal instruction > while loading int.jl, in expression starting on line 193 > ! at ./bool.jl:16 > jl_call_method_internal at > /home1/04179/abean/julia/src/julia_internal.h:189 > jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 > anonymous at ./ (unknown line) > jl_call_method_internal at > /home1/04179/abean/julia/src/julia_internal.h:189 > jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:569 > jl_parse_eval_all at /home1/04179/abean/julia/src/ast.c:717 > jl_load at /home1/04179/abean/julia/src/toplevel.c:596 > jl_load_ at /home1/04179/abean/julia/src/toplevel.c:605 > include at ./boot.jl:231 > jl_call_method_internal at > /home1/04179/abean/julia/src/julia_internal.h:189 > jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 > do_call at /home1/04179/abean/julia/src/interpreter.c:66 > eval at /home1/04179/abean/julia/src/interpreter.c:190 > jl_interpret_toplevel_expr at /home1/04179/abean/julia/src/interpreter.c:31 > jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:558 > jl_eval_module_expr at /home1/04179/abean/julia/src/toplevel.c:196 > jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:465 > jl_toplevel_eval at /home1/04179/abean/julia/src/toplevel.c:580 > jl_toplevel_eval_in_warn at /home1/04179/abean/julia/src/builtins.c:590 > jl_toplevel_eval_in at /home1/04179/abean/julia/src/builtins.c:556 > eval at ./boot.jl:234 > jl_call_method_internal at > /home1/04179/abean/julia/src/julia_internal.h:189 > jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 > do_call at /home1/04179/abean/julia/src/interpreter.c:66 > eval at /home1/04179/abean/julia/src/interpreter.c:190 > jl_interpret_toplevel_expr at /home1/04179/abean/julia/src/interpreter.c:31 > jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:558 > jl_parse_eval_all at /home1/04179/abean/julia/src/ast.c:717 > jl_load at /home1/04179/abean/julia/src/toplevel.c:596 > exec_program at /home1/04179/abean/julia/ui/repl.c:66 > true_main at /home1/04179/abean/julia/ui/repl.c:119 > main at /home1/04179/abean/julia/ui/repl.c:232 > __libc_start_main at /usr/lib64/libc.so.6 (unknown line) > unknown function (ip: 0x401928) > Allocations: 100373 (Pool: 100371; Big: 2); GC: 0 > /bin/sh: line 1: 15078 Illegal instruction > /home1/04179/abean/julia/usr/bin/julia-debug -C knl --output-ji > /home1/04179/abean/julia/usr/lib/julia/inference.ji --startup-file=no > coreimg.jl > make[1]: *** [/home1/04179/abean/julia/usr/lib/julia/inference.ji] Error > 132 > make: *** [julia-inference] Error 2 > > > > Any advice for debugging that? I don't find any previous issues which are > helpful. > > Thanks - > > Austin > > On Thursday, October 13, 2016 at 1:49:24 PM UTC-5, ABB wrote: >> >> Awesome. Thanks. I'll try it again then. I appreciate the help. >> >> (Austin is also my name. I save space in my memory by going to school >> at, living in and being a guy with the same name.) >> >> On Thursday, October 13, 2016 at 1:40:09 PM UTC-5, Erik Schnetter wrote: >>> >>> AB >>> >>> You're speaking of Stampede, if I might guess from the "austin" prefix >>> in your email address. I would treat the old and the new section of the >>> machines as separate, since they are not binary compatible. If you are >>> really interested in the KNL part, then I'd concentrate on these, and use >>> the development mode to always log in, build on, and run on the KNL nodes, >>> and ignore everything else. Mixing different architectures in a single >>> Julia environment is something I'd tackle much later, if at all. >>> >>> Alternatively you can use "haswell" as CPU architecture (instead of >>> "core2" above), which should work both on the front end as well as the KNL >>> nodes. However, this way you will lose speed on the KNL nodes, except for >>> linear algebra operations. >>> >>> -erik >>> >>> >>> On Thu, Oct 13, 2016 at 2:26 PM, ABB wrote: >>> This is great - thanks for getting back to me so quickly. To follow up, I have two small questions: - To build specifically for the KNL system I should include something like "JULIA_CPU_TARGET = knl" in the Make.user file? - Part of the system is KNL, part of it is "Intel Xeon E5 Sandy Bridge and the Intel K
Re: [julia-users] ERROR: Target architecture mismatch
Sigh... build failed. I'm including the last part that worked and the error message which followed: JULIA usr/lib/julia/inference.ji essentials.jl generator.jl reflection.jl options.jl promotion.jl tuple.jl range.jl expr.jl error.jl bool.jl number.jl int.jl signal (4): Illegal instruction while loading int.jl, in expression starting on line 193 ! at ./bool.jl:16 jl_call_method_internal at /home1/04179/abean/julia/src/julia_internal.h:189 jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 anonymous at ./ (unknown line) jl_call_method_internal at /home1/04179/abean/julia/src/julia_internal.h:189 jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:569 jl_parse_eval_all at /home1/04179/abean/julia/src/ast.c:717 jl_load at /home1/04179/abean/julia/src/toplevel.c:596 jl_load_ at /home1/04179/abean/julia/src/toplevel.c:605 include at ./boot.jl:231 jl_call_method_internal at /home1/04179/abean/julia/src/julia_internal.h:189 jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 do_call at /home1/04179/abean/julia/src/interpreter.c:66 eval at /home1/04179/abean/julia/src/interpreter.c:190 jl_interpret_toplevel_expr at /home1/04179/abean/julia/src/interpreter.c:31 jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:558 jl_eval_module_expr at /home1/04179/abean/julia/src/toplevel.c:196 jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:465 jl_toplevel_eval at /home1/04179/abean/julia/src/toplevel.c:580 jl_toplevel_eval_in_warn at /home1/04179/abean/julia/src/builtins.c:590 jl_toplevel_eval_in at /home1/04179/abean/julia/src/builtins.c:556 eval at ./boot.jl:234 jl_call_method_internal at /home1/04179/abean/julia/src/julia_internal.h:189 jl_apply_generic at /home1/04179/abean/julia/src/gf.c:1942 do_call at /home1/04179/abean/julia/src/interpreter.c:66 eval at /home1/04179/abean/julia/src/interpreter.c:190 jl_interpret_toplevel_expr at /home1/04179/abean/julia/src/interpreter.c:31 jl_toplevel_eval_flex at /home1/04179/abean/julia/src/toplevel.c:558 jl_parse_eval_all at /home1/04179/abean/julia/src/ast.c:717 jl_load at /home1/04179/abean/julia/src/toplevel.c:596 exec_program at /home1/04179/abean/julia/ui/repl.c:66 true_main at /home1/04179/abean/julia/ui/repl.c:119 main at /home1/04179/abean/julia/ui/repl.c:232 __libc_start_main at /usr/lib64/libc.so.6 (unknown line) unknown function (ip: 0x401928) Allocations: 100373 (Pool: 100371; Big: 2); GC: 0 /bin/sh: line 1: 15078 Illegal instruction /home1/04179/abean/julia/usr/bin/julia-debug -C knl --output-ji /home1/04179/abean/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl make[1]: *** [/home1/04179/abean/julia/usr/lib/julia/inference.ji] Error 132 make: *** [julia-inference] Error 2 Any advice for debugging that? I don't find any previous issues which are helpful. Thanks - Austin On Thursday, October 13, 2016 at 1:49:24 PM UTC-5, ABB wrote: > > Awesome. Thanks. I'll try it again then. I appreciate the help. > > (Austin is also my name. I save space in my memory by going to school at, > living in and being a guy with the same name.) > > On Thursday, October 13, 2016 at 1:40:09 PM UTC-5, Erik Schnetter wrote: >> >> AB >> >> You're speaking of Stampede, if I might guess from the "austin" prefix in >> your email address. I would treat the old and the new section of the >> machines as separate, since they are not binary compatible. If you are >> really interested in the KNL part, then I'd concentrate on these, and use >> the development mode to always log in, build on, and run on the KNL nodes, >> and ignore everything else. Mixing different architectures in a single >> Julia environment is something I'd tackle much later, if at all. >> >> Alternatively you can use "haswell" as CPU architecture (instead of >> "core2" above), which should work both on the front end as well as the KNL >> nodes. However, this way you will lose speed on the KNL nodes, except for >> linear algebra operations. >> >> -erik >> >> >> On Thu, Oct 13, 2016 at 2:26 PM, ABB wrote: >> >>> This is great - thanks for getting back to me so quickly. >>> >>> To follow up, I have two small questions: >>> >>> - To build specifically for the KNL system I should include something >>> like "JULIA_CPU_TARGET = knl" in the Make.user file? >>> >>> - Part of the system is KNL, part of it is "Intel Xeon E5 Sandy Bridge >>> and the Intel Knights Corner (KNC) coprocessor" (the exact system is >>> this one: https://portal.tacc.utexas.edu/user-guides/stampede ). Is >>> there a way to build for both of the architectures? I think I read in >>> another issue somewhere that it wasn't possible to support the Knights >>> Corner because of (if I recall correctly) lack of LLVM support or something >>> (maybe I am completely making that up) so if it's not possible I wouldn't >>> be surprised. (The two sections of Stampede run different versions of >>> Linux too, if that makes it even more complicated. I'd just be happy
Re: [julia-users] ERROR: Target architecture mismatch
Awesome. Thanks. I'll try it again then. I appreciate the help. (Austin is also my name. I save space in my memory by going to school at, living in and being a guy with the same name.) On Thursday, October 13, 2016 at 1:40:09 PM UTC-5, Erik Schnetter wrote: > > AB > > You're speaking of Stampede, if I might guess from the "austin" prefix in > your email address. I would treat the old and the new section of the > machines as separate, since they are not binary compatible. If you are > really interested in the KNL part, then I'd concentrate on these, and use > the development mode to always log in, build on, and run on the KNL nodes, > and ignore everything else. Mixing different architectures in a single > Julia environment is something I'd tackle much later, if at all. > > Alternatively you can use "haswell" as CPU architecture (instead of > "core2" above), which should work both on the front end as well as the KNL > nodes. However, this way you will lose speed on the KNL nodes, except for > linear algebra operations. > > -erik > > > On Thu, Oct 13, 2016 at 2:26 PM, ABB > > wrote: > >> This is great - thanks for getting back to me so quickly. >> >> To follow up, I have two small questions: >> >> - To build specifically for the KNL system I should include something >> like "JULIA_CPU_TARGET = knl" in the Make.user file? >> >> - Part of the system is KNL, part of it is "Intel Xeon E5 Sandy Bridge >> and the Intel Knights Corner (KNC) coprocessor" (the exact system is >> this one: https://portal.tacc.utexas.edu/user-guides/stampede ). Is >> there a way to build for both of the architectures? I think I read in >> another issue somewhere that it wasn't possible to support the Knights >> Corner because of (if I recall correctly) lack of LLVM support or something >> (maybe I am completely making that up) so if it's not possible I wouldn't >> be surprised. (The two sections of Stampede run different versions of >> Linux too, if that makes it even more complicated. I'd just be happy to >> get it running one way or the other.) >> >> Thanks again! >> >> AB >> >> >> On Thursday, October 13, 2016 at 1:10:48 PM UTC-5, Erik Schnetter wrote: >>> >>> AB >>> >>> Using "core2" is a fallback that will work on very old machines. In your >>> case -- if this happens to be a more modern, uniform HPC system -- you >>> might want to use a different architecture. For example, if you're building >>> on the compute nodes, and never run on the front end, then the default >>> should already work for you. Otherwise, choosing "knl" as architecture >>> should also work (and would also make it impossible to run on the front >>> end). >>> >>> -erik >>> >>> >>> On Thu, Oct 13, 2016 at 1:18 PM, ABB wrote: >>> I built Julia Version 0.5.1-pre+2 on a cluster I have access to. The login node on which I executed the build has this architecture: Intel Core i7-5000 Extreme Edition (Haswell R2) / Xeon E5-x600 v3 (Haswell-EP C1/M1/R2), 22nm The compute node has this architecture: Intel Xeon Phi Coprocessor (Knights Landing), 14nm (Those are each the last line of the output of "cpuid") when I try to run anything, I get the error: ERROR: Target architecture mismatch. Please delete or regenerate sys.{so,dll,dylib}. I found this old discussion: https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ which recommends using JULIA_CPU_TARGET = core2 in the Make.user file. Since that discussion is 2 years old, I am just double checking to see if that's still the best advice or if there is something else I should try first and/or instead. Thanks! AB >>> >>> >>> >>> -- >>> Erik Schnetter >>> http://www.perimeterinstitute.ca/personal/eschnetter/ >>> >> > > > -- > Erik Schnetter > > http://www.perimeterinstitute.ca/personal/eschnetter/ >
Re: [julia-users] ERROR: Target architecture mismatch
AB You're speaking of Stampede, if I might guess from the "austin" prefix in your email address. I would treat the old and the new section of the machines as separate, since they are not binary compatible. If you are really interested in the KNL part, then I'd concentrate on these, and use the development mode to always log in, build on, and run on the KNL nodes, and ignore everything else. Mixing different architectures in a single Julia environment is something I'd tackle much later, if at all. Alternatively you can use "haswell" as CPU architecture (instead of "core2" above), which should work both on the front end as well as the KNL nodes. However, this way you will lose speed on the KNL nodes, except for linear algebra operations. -erik On Thu, Oct 13, 2016 at 2:26 PM, ABB wrote: > This is great - thanks for getting back to me so quickly. > > To follow up, I have two small questions: > > - To build specifically for the KNL system I should include something like > "JULIA_CPU_TARGET = knl" in the Make.user file? > > - Part of the system is KNL, part of it is "Intel Xeon E5 Sandy Bridge > and the Intel Knights Corner (KNC) coprocessor" (the exact system is > this one: https://portal.tacc.utexas.edu/user-guides/stampede ). Is > there a way to build for both of the architectures? I think I read in > another issue somewhere that it wasn't possible to support the Knights > Corner because of (if I recall correctly) lack of LLVM support or something > (maybe I am completely making that up) so if it's not possible I wouldn't > be surprised. (The two sections of Stampede run different versions of > Linux too, if that makes it even more complicated. I'd just be happy to > get it running one way or the other.) > > Thanks again! > > AB > > > On Thursday, October 13, 2016 at 1:10:48 PM UTC-5, Erik Schnetter wrote: >> >> AB >> >> Using "core2" is a fallback that will work on very old machines. In your >> case -- if this happens to be a more modern, uniform HPC system -- you >> might want to use a different architecture. For example, if you're building >> on the compute nodes, and never run on the front end, then the default >> should already work for you. Otherwise, choosing "knl" as architecture >> should also work (and would also make it impossible to run on the front >> end). >> >> -erik >> >> >> On Thu, Oct 13, 2016 at 1:18 PM, ABB wrote: >> >>> I built Julia Version 0.5.1-pre+2 on a cluster I have access to. >>> >>> The login node on which I executed the build has this architecture: >>> >>> Intel Core i7-5000 Extreme Edition (Haswell R2) / Xeon E5-x600 v3 >>> (Haswell-EP C1/M1/R2), 22nm >>> >>> The compute node has this architecture: >>> >>> Intel Xeon Phi Coprocessor (Knights Landing), 14nm >>> >>> (Those are each the last line of the output of "cpuid") >>> >>> when I try to run anything, I get the error: >>> >>> ERROR: Target architecture mismatch. Please delete or regenerate >>> sys.{so,dll,dylib}. >>> >>> I found this old discussion: >>> >>> https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ >>> >>> which recommends using >>> >>> JULIA_CPU_TARGET = core2 >>> >>> in the Make.user file. >>> >>> Since that discussion is 2 years old, I am just double checking to see >>> if that's still the best advice or if there is something else I should try >>> first and/or instead. >>> >>> Thanks! >>> >>> AB >>> >> >> >> >> -- >> Erik Schnetter http://www.perimeterinstitute. >> ca/personal/eschnetter/ >> > -- Erik Schnetter http://www.perimeterinstitute.ca/personal/eschnetter/
Re: [julia-users] ERROR: Target architecture mismatch
This is great - thanks for getting back to me so quickly. To follow up, I have two small questions: - To build specifically for the KNL system I should include something like "JULIA_CPU_TARGET = knl" in the Make.user file? - Part of the system is KNL, part of it is "Intel Xeon E5 Sandy Bridge and the Intel Knights Corner (KNC) coprocessor" (the exact system is this one: https://portal.tacc.utexas.edu/user-guides/stampede ). Is there a way to build for both of the architectures? I think I read in another issue somewhere that it wasn't possible to support the Knights Corner because of (if I recall correctly) lack of LLVM support or something (maybe I am completely making that up) so if it's not possible I wouldn't be surprised. (The two sections of Stampede run different versions of Linux too, if that makes it even more complicated. I'd just be happy to get it running one way or the other.) Thanks again! AB On Thursday, October 13, 2016 at 1:10:48 PM UTC-5, Erik Schnetter wrote: > > AB > > Using "core2" is a fallback that will work on very old machines. In your > case -- if this happens to be a more modern, uniform HPC system -- you > might want to use a different architecture. For example, if you're building > on the compute nodes, and never run on the front end, then the default > should already work for you. Otherwise, choosing "knl" as architecture > should also work (and would also make it impossible to run on the front > end). > > -erik > > > On Thu, Oct 13, 2016 at 1:18 PM, ABB > > wrote: > >> I built Julia Version 0.5.1-pre+2 on a cluster I have access to. >> >> The login node on which I executed the build has this architecture: >> >> Intel Core i7-5000 Extreme Edition (Haswell R2) / Xeon E5-x600 v3 >> (Haswell-EP C1/M1/R2), 22nm >> >> The compute node has this architecture: >> >> Intel Xeon Phi Coprocessor (Knights Landing), 14nm >> >> (Those are each the last line of the output of "cpuid") >> >> when I try to run anything, I get the error: >> >> ERROR: Target architecture mismatch. Please delete or regenerate >> sys.{so,dll,dylib}. >> >> I found this old discussion: >> >> https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ >> >> which recommends using >> >> JULIA_CPU_TARGET = core2 >> >> in the Make.user file. >> >> Since that discussion is 2 years old, I am just double checking to see if >> that's still the best advice or if there is something else I should try >> first and/or instead. >> >> Thanks! >> >> AB >> > > > > -- > Erik Schnetter > > http://www.perimeterinstitute.ca/personal/eschnetter/ >
Re: [julia-users] ERROR: Target architecture mismatch
AB Using "core2" is a fallback that will work on very old machines. In your case -- if this happens to be a more modern, uniform HPC system -- you might want to use a different architecture. For example, if you're building on the compute nodes, and never run on the front end, then the default should already work for you. Otherwise, choosing "knl" as architecture should also work (and would also make it impossible to run on the front end). -erik On Thu, Oct 13, 2016 at 1:18 PM, ABB wrote: > I built Julia Version 0.5.1-pre+2 on a cluster I have access to. > > The login node on which I executed the build has this architecture: > > Intel Core i7-5000 Extreme Edition (Haswell R2) / Xeon E5-x600 v3 > (Haswell-EP C1/M1/R2), 22nm > > The compute node has this architecture: > > Intel Xeon Phi Coprocessor (Knights Landing), 14nm > > (Those are each the last line of the output of "cpuid") > > when I try to run anything, I get the error: > > ERROR: Target architecture mismatch. Please delete or regenerate > sys.{so,dll,dylib}. > > I found this old discussion: > > https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ > > which recommends using > > JULIA_CPU_TARGET = core2 > > in the Make.user file. > > Since that discussion is 2 years old, I am just double checking to see if > that's still the best advice or if there is something else I should try > first and/or instead. > > Thanks! > > AB > -- Erik Schnetter http://www.perimeterinstitute.ca/personal/eschnetter/
[julia-users] ERROR: Target architecture mismatch
I built Julia Version 0.5.1-pre+2 on a cluster I have access to. The login node on which I executed the build has this architecture: Intel Core i7-5000 Extreme Edition (Haswell R2) / Xeon E5-x600 v3 (Haswell-EP C1/M1/R2), 22nm The compute node has this architecture: Intel Xeon Phi Coprocessor (Knights Landing), 14nm (Those are each the last line of the output of "cpuid") when I try to run anything, I get the error: ERROR: Target architecture mismatch. Please delete or regenerate sys.{so,dll,dylib}. I found this old discussion: https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ which recommends using JULIA_CPU_TARGET = core2 in the Make.user file. Since that discussion is 2 years old, I am just double checking to see if that's still the best advice or if there is something else I should try first and/or instead. Thanks! AB