Hi everyone,
I have a fresh checkout of the latest stable release of the Einstein Toolkit (ET_2014_05) which I'm trying to build on my laptop. The laptop is running on Linux Mint 17, and I have adapted configuration options from the bundled "ubuntu.cfg" file. On my machine, I have gcc version 4.8.2, g++ version 4.8.2, and gfortran 4.8.2 as well.
However, when building the toolkit (using the thornlist "einsteintoolkit.th) the build always fails no matter what I try. For instance, on my very first attempt, I didn't use any of my locally installed libraries but opted for the ones bundled with the toolkit. There was one error message in that case pointing to the PAPI library having failed to get configured. I then decided to comment out this thorn from the thornlist (in the .th file). From there on, still building with the bundled external libraries, I have been persistently getting an error message (in the linking stage) to the effect a certain library (lnuma) could not be found. Below is the error message that gets returned onto the screen:
/usr/bin/ld: cannot find -lnuma collect2: error: ld returned 1 exit status /home/dumsani/Cactus/lib/make/make.configuration:147: recipe for target '/home/dumsani/Cactus/exe/cactus_test-ET6' failed make[1]: *** [/home/dumsani/Cactus/exe/cactus_test-ET6] Error 1 Makefile:254: recipe for target 'test-ET6' failed make: *** [test-ET6] Error 2
I would appreciate if anyone with some idea came to my rescue here. Cactus and the ET are still very new to me. I've been stuck on this for almost a week now. And I am of the idea that it shouldn't be taking me that long. Together with my advisor, we have made a checkout of Cactus (Llama thornlist) earlier and he did oriente me to the process until we had a successful build (we got the executable) for the llama thornlist. So, now the idea is for me to get some more practice with Cactus/ET by checking out the full toolkit, configuring, building and then running some example simulations provided in the toolkit.
Thank you in advance for your help.
On 26 Jun 2014, at 11:56, Dumsani Ndzinisa g14n8326@campus.ru.ac.za wrote:
Hi everyone,
I have a fresh checkout of the latest stable release of the Einstein Toolkit (ET_2014_05) which I'm trying to build on my laptop. The laptop is running on Linux Mint 17, and I have adapted configuration options from the bundled "ubuntu.cfg" file. On my machine, I have gcc version 4.8.2, g++ version 4.8.2, and gfortran 4.8.2 as well.
However, when building the toolkit (using the thornlist "einsteintoolkit.th) the build always fails no matter what I try. For instance, on my very first attempt, I didn't use any of my locally installed libraries but opted for the ones bundled with the toolkit. There was one error message in that case pointing to the PAPI library having failed to get configured. I then decided to comment out this thorn from the thornlist (in the .th file). From there on, still building with the bundled external libraries, I have been persistently getting an error message (in the linking stage) to the effect a certain library (lnuma) could not be found. Below is the error message that gets returned onto the screen:
/usr/bin/ld: cannot find -lnuma collect2: error: ld returned 1 exit status /home/dumsani/Cactus/lib/make/make.configuration:147: recipe for target '/home/dumsani/Cactus/exe/cactus_test-ET6' failed make[1]: *** [/home/dumsani/Cactus/exe/cactus_test-ET6] Error 1 Makefile:254: recipe for target 'test-ET6' failed make: *** [test-ET6] Error 2
I would appreciate if anyone with some idea came to my rescue here. Cactus and the ET are still very new to me. I've been stuck on this for almost a week now. And I am of the idea that it shouldn't be taking me that long. Together with my advisor, we have made a checkout of Cactus (Llama thornlist) earlier and he did oriente me to the process until we had a successful build (we got the executable) for the llama thornlist. So, now the idea is for me to get some more practice with Cactus/ET by checking out the full toolkit, configuring, building and then running some example simulations provided in the toolkit.
Hi,
Can you try commenting out the thorn "hwloc" from your thornlist? Grepping through the source for "numa", the only use of this library seems to be hwloc. hwloc is a thorn which assists in binding software threads to physical computational cores and processes to processor sockets for efficiency, but it is not necessary for the toolkit to run.
There might be something wrong with the hwloc configure script (Cactus/arrangements/ExternalLibraries/hwloc/configure.sh). The relevant lines appear to be
# Add libnuma manually, if necessary if grep -q '[-]lnuma' ${HWLOC_LIB_DIR}/libhwloc.la 2>/dev/null; then if ! echo '' ${HWLOC_LIBS} '' | grep -q ' numa '; then HWLOC_LIBS="${HWLOC_LIBS} numa" fi fi
This seems to be attempting to add the numa library to the link line if it is found in libhwloc.la. The error message indicates that numa has been added to the link line, but the library is not available on the link path.
The most recent change to hwloc, in April (i.e. before the release), is:
"Correct detecting whether -lnuma is necessary" (http://git.barrywardell.net/?p=arrangements/ExternalLibraries/hwloc.git;a=co...) author eschnett eschnett@152c557c-6d84-4bc7-9b1a-dfca721279c7 Sat, 19 Apr 2014 23:07:32 +0200 (21:07 +0000) committer eschnett eschnett@152c557c-6d84-4bc7-9b1a-dfca721279c7 Sat, 19 Apr 2014 23:07:32 +0200 (21:07 +0000)
Probably Erik has some insight into this.
We have an automated build and test process running under Ubuntu 12.04, and this is working fine. It also builds hwloc from source, rather than relying on the Ubuntu version. Do you happen to have hwloc installed? Maybe it is conflicting with the self-built version?
dpkg -l hwloc
We should probably upgrade the build and test system to Ubuntu 14.04, as that is now the latest stable release. Maybe something in Ubuntu has changed with the hwloc library.
Hi
First of all - try disabling the hwloc thorn. You don't necessarily need it. It might not be the best solution, but the fastest for now.
On Thu, Jun 26, 2014 at 12:22:50PM +0200, Ian Hinder wrote:
# Add libnuma manually, if necessary if grep -q '[-]lnuma' ${HWLOC_LIB_DIR}/libhwloc.la 2>/dev/null; then
This only greps ${HWLOC_LIB_DIR}/libhwloc.la which might not be present. I am not sure about your distribution, but Debian doesn't ship with this file at all, which should make the above test always fail. While this doesn't seem right, it shouldn't cause the problem you describe.
What I could imagine is that this test triggers for you, and you do have libnuma installed, but not libnuma-dev. This would mean libhwloc seems to (?) need linkage against libnuma, that is also installed, but the relevant development files are not. In that case, either the test is wrong (no explicit linkage to libnuma would in fact be required), or you need to install the development files for libnuma (likely the libnuma-dev package).
It would be good to know a couple of things about your installation, in particular the following (with results shown for my Debian workstation):
HWLOC_DIR=/usr/lib/x86_64-linux-gnu
$ pkg-config hwloc --static --libs -lhwloc -lxml2 -lz -lm -lpci
(Note that numa is missing here, but the shared library in fact requires it. This works because libnuma is installed in a standard location. Adding -lnuma to the link line would probably make linking fail, since I don't have libnuma.so installed - while of couse libnuma.so.1 is.)
ls $HWLOC_DIR/libhwloc.* /usr/lib/x86_64-linux-gnu/libhwloc.a /usr/lib/x86_64-linux-gnu/libhwloc.so.3 /usr/lib/x86_64-linux-gnu/libhwloc.so /usr/lib/x86_64-linux-gnu/libhwloc.so.4 /usr/lib/x86_64-linux-gnu/libhwloc.so.0 /usr/lib/x86_64-linux-gnu/libhwloc.so.5 /usr/lib/x86_64-linux-gnu/libhwloc.so.1 /usr/lib/x86_64-linux-gnu/libhwloc.so.5.0.1 /usr/lib/x86_64-linux-gnu/libhwloc.so.2
$ ldd $HWLOC_DIR/libhwloc.so | grep numa libnuma.so.1 => /usr/lib/libnuma.so.1 (0x00007fd82c17d000)
$ nm $HWLOC_DIR/libhwloc.a | grep -i numa
$ nm -D $HWLOC_DIR/libhwloc.so | grep -i numa
$ ls /usr/lib/libnuma.* /usr/lib/libnuma.so.1
$ dpkg -l '*libhwloc*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-===================-==============-==============-=========================================== ii libhwloc-dev 1.4.1-4 amd64 Hierarchical view of the machine - static l un libhwloc0 <none> (no description available) un libhwloc1 <none> (no description available) un libhwloc2 <none> (no description available) un libhwloc3 <none> (no description available) un libhwloc4 <none> (no description available) ii libhwloc5:amd64 1.4.1-4 amd64 Hierarchical view of the machine - shared l
$ dpkg -l '*libnuma*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-===================-==============-==============-=========================================== ii libnuma1 2.0.8~rc4-1 amd64 Libraries for controlling NUMA policy
Frank
Hi,
Concerning the few points of interest which Frank raised about my distribution/installation, I have the results below.
$ HWLOC_DIR=/usr/lib/x86_64-linux-gnu
[ I didn't know if this was also part of the commands you suggested for me. I just typed it on the terminal anyway.
$ pgk-config hwloc --static --libs No command 'pgk-config' found, did you mean: Command 'pkg-config' from package 'pkg-config' (main) Command 'pkg-config' from package 'pkgconf' (universe) pgk-config: command not found $ pgk-config hwloc --static --libs -lhwloc -lxml2 -lz -lm -lpci No command 'pgk-config' found, did you mean: Command 'pkg-config' from package 'pkgconf' (universe) Command 'pkg-config' from package 'pkg-config' (main) pgk-config: command not found]
$ ls $HWLOC_DIR/libhwloc.* /usr/lib/x86_64-linux-gnu/libhwloc.a /usr/lib/x86_64-linux-gnu/libhwloc.so /usr/lib/x86_64-linux-gnu/libhwloc.so.0 /usr/lib/x86_64-linux-gnu/libhwloc.so.1 /usr/lib/x86_64-linux-gnu/libhwloc.so.2 /usr/lib/x86_64-linux-gnu/libhwloc.so.3 /usr/lib/x86_64-linux-gnu/libhwloc.so.4 /usr/lib/x86_64-linux-gnu/libhwloc.so.5 /usr/lib/x86_64-linux-gnu/libhwloc.so.5.4.0
$ ldd $HWLOC_DIR/libhwloc.so | grep numa libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f84d1bf7000)
$ nm $HWLOC_DIR/libhwloc.a | grep -i numa $ nm -D $HWLOC_DIR/libhwloc.so | grep -i numa $ ls /usr/lib/libnuma.* ls: cannot access /usr/lib/libnuma.*: No such file or directory
$ dpkg -l '*libhwloc*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============-============-============-================================= un libhwloc-contr <none> <none> (no description available) ii libhwloc-dev:a 1.8-1ubuntu1 amd64 Hierarchical view of the machine un libhwloc-plugi <none> <none> (no description available) un libhwloc0 <none> <none> (no description available) un libhwloc1 <none> <none> (no description available) un libhwloc2 <none> <none> (no description available) un libhwloc3 <none> <none> (no description available) un libhwloc4 <none> <none> (no description available) ii libhwloc5:amd6 1.8-1ubuntu1 amd64 Hierarchical view of the machine
$ dpkg -l '*libnuma*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============-============-============-================================= ii libnuma1:amd64 2.0.9~rc5-1u amd64 Libraries for controlling NUMA po
Regards,
Dumsani
On 26/06/2014 17:01, Frank Loeffler wrote:
Hi
First of all - try disabling the hwloc thorn. You don't necessarily need it. It might not be the best solution, but the fastest for now.
On Thu, Jun 26, 2014 at 12:22:50PM +0200, Ian Hinder wrote:
# Add libnuma manually, if necessary if grep -q '[-]lnuma' ${HWLOC_LIB_DIR}/libhwloc.la 2>/dev/null; then
This only greps ${HWLOC_LIB_DIR}/libhwloc.la which might not be present. I am not sure about your distribution, but Debian doesn't ship with this file at all, which should make the above test always fail. While this doesn't seem right, it shouldn't cause the problem you describe.
What I could imagine is that this test triggers for you, and you do have libnuma installed, but not libnuma-dev. This would mean libhwloc seems to (?) need linkage against libnuma, that is also installed, but the relevant development files are not. In that case, either the test is wrong (no explicit linkage to libnuma would in fact be required), or you need to install the development files for libnuma (likely the libnuma-dev package).
It would be good to know a couple of things about your installation, in particular the following (with results shown for my Debian workstation):
HWLOC_DIR=/usr/lib/x86_64-linux-gnu
$ pkg-config hwloc --static --libs -lhwloc -lxml2 -lz -lm -lpci
(Note that numa is missing here, but the shared library in fact requires it. This works because libnuma is installed in a standard location. Adding -lnuma to the link line would probably make linking fail, since I don't have libnuma.so installed - while of couse libnuma.so.1 is.)
ls $HWLOC_DIR/libhwloc.* /usr/lib/x86_64-linux-gnu/libhwloc.a /usr/lib/x86_64-linux-gnu/libhwloc.so.3 /usr/lib/x86_64-linux-gnu/libhwloc.so /usr/lib/x86_64-linux-gnu/libhwloc.so.4 /usr/lib/x86_64-linux-gnu/libhwloc.so.0 /usr/lib/x86_64-linux-gnu/libhwloc.so.5 /usr/lib/x86_64-linux-gnu/libhwloc.so.1 /usr/lib/x86_64-linux-gnu/libhwloc.so.5.0.1 /usr/lib/x86_64-linux-gnu/libhwloc.so.2
$ ldd $HWLOC_DIR/libhwloc.so | grep numa libnuma.so.1 => /usr/lib/libnuma.so.1 (0x00007fd82c17d000)
$ nm $HWLOC_DIR/libhwloc.a | grep -i numa
$ nm -D $HWLOC_DIR/libhwloc.so | grep -i numa
$ ls /usr/lib/libnuma.* /usr/lib/libnuma.so.1
$ dpkg -l '*libhwloc*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-===================-==============-==============-=========================================== ii libhwloc-dev 1.4.1-4 amd64 Hierarchical view of the machine - static l un libhwloc0 <none> (no description available) un libhwloc1 <none> (no description available) un libhwloc2 <none> (no description available) un libhwloc3 <none> (no description available) un libhwloc4 <none> (no description available) ii libhwloc5:amd64 1.4.1-4 amd64 Hierarchical view of the machine - shared l
$ dpkg -l '*libnuma*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-===================-==============-==============-=========================================== ii libnuma1 2.0.8~rc4-1 amd64 Libraries for controlling NUMA policy
Frank
Hi
On Thu, Jun 26, 2014 at 05:42:48PM +0200, Dumsani Ndzinisa wrote:
$ pgk-config hwloc --static --libs No command 'pgk-config' found, did you mean:
Ok. That is not a problem.
$ ls $HWLOC_DIR/libhwloc.* /usr/lib/x86_64-linux-gnu/libhwloc.a /usr/lib/x86_64-linux-gnu/libhwloc.so /usr/lib/x86_64-linux-gnu/libhwloc.so.0 /usr/lib/x86_64-linux-gnu/libhwloc.so.1 /usr/lib/x86_64-linux-gnu/libhwloc.so.2 /usr/lib/x86_64-linux-gnu/libhwloc.so.3 /usr/lib/x86_64-linux-gnu/libhwloc.so.4 /usr/lib/x86_64-linux-gnu/libhwloc.so.5 /usr/lib/x86_64-linux-gnu/libhwloc.so.5.4.0
Apparently no libhwloc.la - as here too.
$ ldd $HWLOC_DIR/libhwloc.so | grep numa libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f84d1bf7000)
$ nm $HWLOC_DIR/libhwloc.a | grep -i numa $ nm -D $HWLOC_DIR/libhwloc.so | grep -i numa
$ ls /usr/lib/libnuma.* ls: cannot access /usr/lib/libnuma.*: No such file or directory
Ok, here this would probably need to be
$ ls /usr/lib/x86_64-linux-gnu/libnuma.*
$ dpkg -l '*libhwloc*' ii libhwloc-dev:a 1.8-1ubuntu1 amd64 Hierarchical view of the machine ii libhwloc5:amd6 1.8-1ubuntu1 amd64 Hierarchical view of the machine
$ dpkg -l '*libnuma*' ii libnuma1:amd64 2.0.9~rc5-1u amd64 Libraries for controlling NUMA po
Theoretically, the mentioned test in the configure script should not trigger for you, as there is no .la file. Something on the other hand seems to add -lnuma to your link line. It would be interesting to know what this is - because this is what makes this fail - you don't have libnuma1-dev (or libnuma-dev) installed, so there is no .so file (just the .so.1), which then lets the linker fail.
Frank
Hi,
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.
Also, even after installing libnuma-dev (on the command line) still the following command returns the same output as it did before installing the package.
$ldd $HWLOC_DIR/libhwloc.so | grep numa libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007fad44aec000)
I also corrected the following command and it gives the output shown hereafter: $ 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
Of course, it would help to eventually understand why -lnuma also comes into the liking sequence. Probably someone else will be able to figure it out, or it will come out in time.
Many thanks to all of you for your kind assistance.
On 26/06/2014 17:52, Frank Loeffler wrote:
Hi
On Thu, Jun 26, 2014 at 05:42:48PM +0200, Dumsani Ndzinisa wrote:
$ pgk-config hwloc --static --libs No command 'pgk-config' found, did you mean:Ok. That is not a problem.
$ ls $HWLOC_DIR/libhwloc.* /usr/lib/x86_64-linux-gnu/libhwloc.a /usr/lib/x86_64-linux-gnu/libhwloc.so /usr/lib/x86_64-linux-gnu/libhwloc.so.0 /usr/lib/x86_64-linux-gnu/libhwloc.so.1 /usr/lib/x86_64-linux-gnu/libhwloc.so.2 /usr/lib/x86_64-linux-gnu/libhwloc.so.3 /usr/lib/x86_64-linux-gnu/libhwloc.so.4 /usr/lib/x86_64-linux-gnu/libhwloc.so.5 /usr/lib/x86_64-linux-gnu/libhwloc.so.5.4.0
Apparently no libhwloc.la - as here too.
$ ldd $HWLOC_DIR/libhwloc.so | grep numa libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f84d1bf7000)
$ nm $HWLOC_DIR/libhwloc.a | grep -i numa $ nm -D $HWLOC_DIR/libhwloc.so | grep -i numa $ ls /usr/lib/libnuma.* ls: cannot access /usr/lib/libnuma.*: No such file or directory
Ok, here this would probably need to be
$ ls /usr/lib/x86_64-linux-gnu/libnuma.*
$ dpkg -l '*libhwloc*' ii libhwloc-dev:a 1.8-1ubuntu1 amd64 Hierarchical view of the machine ii libhwloc5:amd6 1.8-1ubuntu1 amd64 Hierarchical view of the machine
$ dpkg -l '*libnuma*' ii libnuma1:amd64 2.0.9~rc5-1u amd64 Libraries for controlling NUMA po
Theoretically, the mentioned test in the configure script should not trigger for you, as there is no .la file. Something on the other hand seems to add -lnuma to your link line. It would be interesting to know what this is - because this is what makes this fail - you don't have libnuma1-dev (or libnuma-dev) installed, so there is no .so file (just the .so.1), which then lets the linker fail.
Frank
On Thu, Jun 26, 2014 at 10:19:22PM +0200, Dumsani Ndzinisa wrote:
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.
This can be perfectly normal. The .la files are not necessary.
$ 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
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).
Of course, it would help to eventually understand why -lnuma also comes into the liking sequence.
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
Hi,
It's a bit funny that I can't really tell exactly if I'm on a multi-architectural installation or not. I'm also relatively new to Unix type of systems.There must be a way checking that, I'm sure. I would be happy if you could suggest one such method for me.
But, naively, I would suspect it is a multi-arch installation that I have here. Running the command "apt-file search <phrase>" with i386, and x86_64-linus-gnu (amd64), gives a lot of things (mostly stuff inside /usr/lib/....) that relate to both of these in my machine. So, I just suppose it might be the case that I'm on a multi-arch installation. That is as far as softwares (applications) are concerned.
On the hardware side, my laptop in a 64-bit capable machine (Lenovo ThinkPadX240, Intel i7 core). I have quickly taken a look at this link here for some brief exaplanations of terminology: https://help.ubuntu.com/community/32bit_and_64bit .
Here is a command they suggested for me to use, adding that " If this command returns lm (*L*ong *M*ode) as one of the flags, then your processor is capable of 64-bit." :
grep --color=always -iw lm /proc/cpuinfo
The output does confirm that the processor of my machine is 64-bit. Here is part of the output:
$ grep --color=always -iw lm /proc/cpuinfo 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 lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc ap
Regards
Dumsani
On 26/06/2014 22:39, Frank Loeffler wrote:
On Thu, Jun 26, 2014 at 10:19:22PM +0200, Dumsani Ndzinisa wrote:
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.
This can be perfectly normal. The .la files are not necessary.
$ 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
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).
Of course, it would help to eventually understand why -lnuma also comes into the liking sequence.
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
users@lists.einsteintoolkit.org
-
Dumsani Ndzinisa -
Frank Loeffler -
Ian Hinder