ERROR: Target architecture mismatch

classic Classic list List threaded Threaded
15 messages Options
ABB
Reply | Threaded
Open this post in threaded view
|

ERROR: Target architecture mismatch

ABB
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
Reply | Threaded
Open this post in threaded view
|

Re: ERROR: Target architecture mismatch

Erik Schnetter
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 <[hidden email]> 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:


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



--
ABB
Reply | Threaded
Open this post in threaded view
|

Re: ERROR: Target architecture mismatch

ABB
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="Fzy4BGrVBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">austi...@...> 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:

<a href="https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ&#39;;return true;">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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="Fzy4BGrVBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">schn...@...> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/
Reply | Threaded
Open this post in threaded view
|

Re: ERROR: Target architecture mismatch

Erik Schnetter
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 <[hidden email]> 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 <[hidden email]> 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:


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



--



--
ABB
Reply | Threaded
Open this post in threaded view
|

Re: ERROR: Target architecture mismatch

ABB
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="vsk79wPXBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">austi...@...> 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: <a href="https://portal.tacc.utexas.edu/user-guides/stampede" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fportal.tacc.utexas.edu%2Fuser-guides%2Fstampede\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHlHy6H1G57qWMcybJCjxM9sXL8eQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fportal.tacc.utexas.edu%2Fuser-guides%2Fstampede\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHlHy6H1G57qWMcybJCjxM9sXL8eQ&#39;;return true;">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 <[hidden email]> 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:

<a href="https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ&#39;;return true;">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 <[hidden email]> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/



--
Erik Schnetter <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="vsk79wPXBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">schn...@...> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/
ABB
Reply | Threaded
Open this post in threaded view
|

Re: ERROR: Target architecture mismatch

ABB
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 ./<missing> (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 <[hidden email]> 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: <a href="https://portal.tacc.utexas.edu/user-guides/stampede" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fportal.tacc.utexas.edu%2Fuser-guides%2Fstampede\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHlHy6H1G57qWMcybJCjxM9sXL8eQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fportal.tacc.utexas.edu%2Fuser-guides%2Fstampede\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHlHy6H1G57qWMcybJCjxM9sXL8eQ&#39;;return true;">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 <[hidden email]> 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:

<a href="https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ&#39;;return true;">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 <[hidden email]> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/



--
Erik Schnetter <[hidden email]> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/
Reply | Threaded
Open this post in threaded view
|

Re: ERROR: Target architecture mismatch

Valentin Churavy
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 ./<missing> (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 <[hidden email]> 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: <a href="https://portal.tacc.utexas.edu/user-guides/stampede" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fportal.tacc.utexas.edu%2Fuser-guides%2Fstampede\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHlHy6H1G57qWMcybJCjxM9sXL8eQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fportal.tacc.utexas.edu%2Fuser-guides%2Fstampede\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHlHy6H1G57qWMcybJCjxM9sXL8eQ&#39;;return true;">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 <[hidden email]> 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:

<a href="https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ&#39;;return true;">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 <[hidden email]> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/



--
Erik Schnetter <[hidden email]> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/
Reply | Threaded
Open this post in threaded view
|

Re: ERROR: Target architecture mismatch

Erik Schnetter
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 <[hidden email]> 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 ./<missing> (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 <[hidden email]> 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 <[hidden email]> 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:


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



--



--



--
ABB
Reply | Threaded
Open this post in threaded view
|

Re: ERROR: Target architecture mismatch

ABB
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="WvEQUiQZBQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">v.ch...@...> 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 ./<missing> (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 <[hidden email]> 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: <a href="https://portal.tacc.utexas.edu/user-guides/stampede" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fportal.tacc.utexas.edu%2Fuser-guides%2Fstampede\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHlHy6H1G57qWMcybJCjxM9sXL8eQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fportal.tacc.utexas.edu%2Fuser-guides%2Fstampede\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHlHy6H1G57qWMcybJCjxM9sXL8eQ&#39;;return true;">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 <[hidden email]> 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:

<a href="https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ&#39;;return true;">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 <[hidden email]> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/



--
Erik Schnetter <[hidden email]> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/



--
Erik Schnetter <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="WvEQUiQZBQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">schn...@...> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/
Reply | Threaded
Open this post in threaded view
|

Re: ERROR: Target architecture mismatch

Erik Schnetter
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 <[hidden email]> 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 <[hidden email]> 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 ./<missing> (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 <[hidden email]> 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 <[hidden email]> 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:


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



--



--



--



--
ABB
Reply | Threaded
Open this post in threaded view
|

Re: ERROR: Target architecture mismatch

ABB
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="jyYHjesbBQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">austi...@...> 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 <[hidden email]> 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 ./<missing> (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 <[hidden email]> 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: <a href="https://portal.tacc.utexas.edu/user-guides/stampede" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fportal.tacc.utexas.edu%2Fuser-guides%2Fstampede\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHlHy6H1G57qWMcybJCjxM9sXL8eQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fportal.tacc.utexas.edu%2Fuser-guides%2Fstampede\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHlHy6H1G57qWMcybJCjxM9sXL8eQ&#39;;return true;">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 <[hidden email]> 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:

<a href="https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/forum/#!msg/julia-dev/Eqp0GhZWxME/3mGKX1l_L9gJ&#39;;return true;">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 <[hidden email]> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/



--
Erik Schnetter <[hidden email]> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/



--
Erik Schnetter <[hidden email]> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/



--
Erik Schnetter <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="jyYHjesbBQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">schn...@...> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/
ABB
Reply | Threaded
Open this post in threaded view
|

Re: ERROR: Target architecture mismatch

ABB
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.
Reply | Threaded
Open this post in threaded view
|

Re: ERROR: Target architecture mismatch

Erik Schnetter
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 <[hidden email]> 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.



--
ABB
Reply | Threaded
Open this post in threaded view
|

Re: ERROR: Target architecture mismatch

ABB
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="He79M8t0BQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">austi...@...> 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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="He79M8t0BQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">schn...@...> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/
ABB
Reply | Threaded
Open this post in threaded view
|

Re: ERROR: Target architecture mismatch

ABB
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=<unnamed>::Db]" at line 3042
            instantiation of "const char *parse_expression(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 1520
            instantiation of "const char *parse_array_type(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 1707
            instantiation of "const char *parse_type(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 3866
            instantiation of "const char *parse_special_name(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 4026
            instantiation of "const char *parse_encoding(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 4185
            instantiation of "void demangle(const char *, const char *, C &, int &) [with C=<unnamed>::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=<unnamed>::Db]" at line 3042
            instantiation of "const char *parse_expression(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 1520
            instantiation of "const char *parse_array_type(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 1707
            instantiation of "const char *parse_type(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 3866
            instantiation of "const char *parse_special_name(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 4026
            instantiation of "const char *parse_encoding(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 4185
            instantiation of "void demangle(const char *, const char *, C &, int &) [with C=<unnamed>::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=<unnamed>::Db]" at line 1000
            instantiation of "const char *parse_unresolved_name(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 3042
            instantiation of "const char *parse_expression(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 1520
            instantiation of "const char *parse_array_type(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 1707
            instantiation of "const char *parse_type(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 3866
            instantiation of "const char *parse_special_name(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 4026
            instantiation of "const char *parse_encoding(const char *, const char *, C &) [with C=<unnamed>::Db]" at line 4185
            instantiation of "void demangle(const char *, const char *, C &, int &) [with C=<unnamed>::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 <[hidden email]> 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 <[hidden email]> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.perimeterinstitute.ca%2Fpersonal%2Feschnetter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxlaNboZlt-tpAt8j3eV3SBzPUpg&#39;;return true;">http://www.perimeterinstitute.ca/personal/eschnetter/