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/
