<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
It's a bit funny that I can't really tell exactly if I'm on a
multi-architectural <br>
installation
or not. I'm also relatively new to Unix type of systems.There <br>
must be a way checking that, I'm sure. I would be happy if you could
<br>
suggest one such method for me.<br>
<br>
But, naively, I would suspect it is a multi-arch installation that I
<br>
have here. Running the command "apt-file search <phrase>"<br>
with i386, and x86_64-linus-gnu (amd64), gives a lot of things
(mostly<br>
stuff inside /usr/lib/....) that relate to both of these in my
machine.<br>
So, I just suppose it might be the case that I'm on a multi-arch<br>
installation. That is as far as softwares (applications) are
concerned.<br>
<br>
On the hardware side, my laptop in a 64-bit capable machine<br>
(Lenovo ThinkPadX240, Intel i7 core). I have quickly taken a look<br>
at this link here for some brief exaplanations of terminology:<br>
<a class="moz-txt-link-freetext" href="https://help.ubuntu.com/community/32bit_and_64bit">https://help.ubuntu.com/community/32bit_and_64bit</a> .<br>
<br>
Here is a command they suggested for me to use, adding that <br>
" If this command returns lm (<strong>L</strong>ong <strong>M</strong>ode)
as one of the flags, then your <br>
processor is capable of 64-bit." :<br>
<br>
grep --color=always -iw lm /proc/cpuinfo<br>
<br>
The output does confirm that the processor of my machine is 64-bit.<br>
Here is part of the output:<br>
<br>
$ grep --color=always -iw lm /proc/cpuinfo<br>
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp <font color="#ff6600">lm</font>
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc ap<br>
<br>
Regards<br>
<br>
<br>
Dumsani<br>
<br>
<div class="moz-cite-prefix">On 26/06/2014 22:39, Frank Loeffler
wrote:<br>
</div>
<blockquote cite="mid:20140626203948.GC5556@topf.wg" type="cite">
<pre wrap="">On Thu, Jun 26, 2014 at 10:19:22PM +0200, Dumsani Ndzinisa wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Yes, the file libhwloc.la doesn't seem to exist anywhere in my
machine despite the fact that I have libhwloc-dev installed.
I have no idea why this is the case.
</pre>
</blockquote>
<pre wrap="">
This can be perfectly normal. The .la files are not necessary.
</pre>
<blockquote type="cite">
<pre wrap="">$ ls /usr/lib/x86_64-linux-gnu/libnuma.*
/usr/lib/x86_64-linux-gnu/libnuma.a /usr/lib/x86_64-linux-gnu/libnuma.so.1
/usr/lib/x86_64-linux-gnu/libnuma.so
</pre>
</blockquote>
<pre wrap="">
So you now do actually have everything you should need. Strange. If
-lnuma still isn't found, /usr/lib/x86_64-linux-gnu is not in your
standard search path (which would be odd, but possible. Do you by any
chance try this on a multi-arch installation with i386 being the default
(so that the numa library that is x86_64 cannot be linked, and you would
need to install the corresponding i386 library instead - not that I
would suggest that).
</pre>
<blockquote type="cite">
<pre wrap="">Of course, it would help to eventually understand why -lnuma also
comes into the liking sequence.
</pre>
</blockquote>
<pre wrap="">
True. From the configuration script and the absence of the .la file I
would think it needs to be something else than that.
On a single machine (like a workstation or laptop), I found that _not_
using hwloc can actually be an advantage anyway in some circumstances
(multiple MPI jobs _not_ all tied to the first core).
Frank
</pre>
</blockquote>
<br>
</body>
</html>