K-ballo changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
<tiagofg[m]> Hello, is there some code on hpx examples or tests that illustrates how to spawn a new process(locality) remotely, at runtime?
<hkaiser> tiagofg[m]: there is a process component that can be used to spawn a process remotely, it requires having a hpx locality running on the target node, however
<tiagofg[m]> hkaiser: humm ok, thanks!
<tiagofg[m]> hkaiser: and if I wanted to launch a new locality on another node without any locality running there? I think I have to use an external library to create a process remotely, like libssh, I am rigth?
<hkaiser> yes
<tiagofg[m]> hkaiser: thanks, you save my day!
bita__ has quit [Ping timeout: 240 seconds]
hkaiser has quit [Quit: bye]
bita__ has joined #ste||ar
bita__ has quit [Ping timeout: 264 seconds]
shahrzad has quit [Quit: Leaving]
hkaiser has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
akheir has joined #ste||ar
shahrzad has joined #ste||ar
nanmiao11 has joined #ste||ar
bita has joined #ste||ar
<gonidelis[m]> any ideas why `make -j tests.unit.modules.algorithms` fails?
<gonidelis[m]> I `cmake`d with `exapmles=off`
jaafar has quit [Quit: Konversation terminated!]
jaafar has joined #ste||ar
nanmiao11 has quit [Remote host closed the connection]
<gonidelis[m]> Do algorithms compile for you guys?
<gonidelis[m]> that's my error
<K-ballo> isn't that the same linker error you got a few days back? or was it someone else?
<K-ballo> one that happens only on gcc/release build
<gonidelis[m]> no that's different
<gonidelis[m]> should i build with clang then?
<gonidelis[m]> is there any issue for that?
<K-ballo> they look identical to me
<K-ballo> oh, you reused the old gist
<K-ballo> still, look the same than the ones from your earlier revision
<K-ballo> I'd give you the same issue link you got the other day
<gonidelis[m]> uhh you are right
<gonidelis[m]> i was thinking of the error i produced with my code last time
<gonidelis[m]> yeah sorry
<gonidelis[m]> thus compiling with exapmles=off does not help
<gonidelis[m]> Should I use clang or sth?
<K-ballo> the issue says all tested clang versions are ok, so that's always an option too
<gonidelis[m]> ok... let's see how that goes
<gonidelis[m]> that's my first time using clang
<gonidelis[m]> (embarassed face)
<gonidelis[m]> Do I use the `-DCMAKE_C_COMPILER ` flag along with the `-DCMAKE_CXX_COMPILER=clang++ \`?
<gonidelis[m]> ah I don't thinkg so
<K-ballo> CC=clang CXX=clang++ cmake ... will do, for a clean configuration
<gonidelis[m]> ahh K-ballo
<gonidelis[m]> no CC=clang ref here
<K-ballo> no CXX=clang++ there either
<gonidelis[m]> ` -DCMAKE_CXX_COMPILER=clang++ \` ??
<K-ballo> that's a lot more letters
<K-ballo> and that's a cmake cache var, not an environment variable
<K-ballo> you are not meant to set CMAKE_[LANG]_COMPILER directly, you set the env vars and the default toolchain picks them up and configures itself accordingly
<gonidelis[m]> wow
<gonidelis[m]> that's cool
<gonidelis[m]> didnt know that
nanmiao11 has joined #ste||ar
<gonidelis[m]> thanks a lot
<gonidelis[m]> 1. it compiled [finally]
<gonidelis[m]> 2. cool thing to know
nanmiao11 has quit [Remote host closed the connection]
weilewei has joined #ste||ar
<weilewei> I wonder how to handle hwloc related issues, undefined reference: https://gist.github.com/weilewei/dbb12dc934fc51e019bfd231931d5c27
<hkaiser> weilewei: this is not related to hwloc at all, it's rather an c++ standard compatibility issue between hpx and your application
<hkaiser> one is c++11 the other is something else or v.v.
<hkaiser> well, the missing hwloc symbols come from openmpi
<weilewei> This is the error when I was building hpx on arm a64fx
<hkaiser> could also be a c++17 issue (as filesystem is involved
<weilewei> hmm I enabled cxx 17 in hpx
<hkaiser> one is c++14, the other c++17 perhaps
<weilewei> Oh, maybe I need to rebuild boost? I have not configured it cxx17 explicitly
<hkaiser> could be, but no boost symbols are involved
<weilewei> Yea, I also did not see boost problems there
<weilewei> otherwise I do not know where can cause different c++ standards
<zao> Notable about <filesystem> is that GCC (libstdc++) has the filesystem bits in a separate library, libstdc++fs
<hkaiser> zao: ahh, I thought that did change
<hkaiser> depends on the compiler version, perhaps
<zao> Possibly, I forget with what release I ran into it the other month.
<weilewei> I use gcc-10.2.0/
<hkaiser> that would explain the missing symbols, though
<hkaiser> ok
<hkaiser> compile it with c++14 then and create a ticket, pls
<zao> Supposedly merged in GCC9.
<hkaiser> what cmake version do you use weilewei?
<zao> (my debian host has 8.3.0)
<weilewei> hkaiser cmake 3.18.2
<hkaiser> ok
<hkaiser> well, I dont know
<hkaiser> the easiest would be to configure hpx with c++14 (the default)
<weilewei> hmm can I compile hpx with c++14 and then dca++ has C++17 version? Do they work with each other?
<hkaiser> that should work, yes
<hkaiser> (famous last words...)
<weilewei> ok, compatibility
<weilewei> maybe I need to ignore compatibility
<weilewei> aha, let me try then
<hkaiser> yeah, you might have to supress the warning
<hkaiser> is that on wombat?
<weilewei> Yes, wombat a64fx node
<hkaiser> ok
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 256 seconds]
K-ballo1 is now known as K-ballo
weilewei has quit [Remote host closed the connection]
weilewei has joined #ste||ar
<weilewei> After configure hpx with cxx14, I still got similar error but the filesystem error is gone: https://gist.github.com/weilewei/dbb12dc934fc51e019bfd231931d5c27#gistcomment-3517679
<K-ballo> odd, filesystem comes with c++17
<weilewei> But it seems like error with hwloc?
<zao> Smells a bit like either mismatched headers/libraries or missing libraries on the link command line.
<zao> Hard to tell as you didn't include that command line :D
<gnikunj[m]> weilewei by any chance, do you have multiple hwloc versions on the system?
<weilewei> gnikunj[m] that's very possible, but I pass explicit path to hwloc
<gnikunj[m]> Yea that won't help still. Looks like it is an Arm machine. I faced multiple issues with hwloc when I was building hpx on JSC's Arm clusters. All of them where due to multiple hwloc versions.
<weilewei> hmm I did saw the HWLOC path in CMakeCache.Lists is pointing to arm machine hwloc path
<weilewei> not the one I passed to the script
<gnikunj[m]> Haha that's what I'm talking about
<weilewei> How can I overwrite it, preventing hpx links to built-in hwloc
<gnikunj[m]> If I had known that, I wouldn't have used 1.11 on my Arm paper ;-)
<weilewei> gnikunj[m] shocked. do you mean hpx 1.11?
<gnikunj[m]> No hwloc versionsm
<gnikunj[m]> 1.1 I guess
<gnikunj[m]> Hwloc current release is at 2.1 iirc
<zao> Protip - enclose your comments on gists in ``` to try to avoid the system interpreting and mangling them as markdown, or add scripts as actual files in the gist.
<gnikunj[m]> 2.2 should be on its way as well. But we used 1.1 or similar old version.
<weilewei> hmmm the system one is 1.11.11 from the system, but that is built in gcc 8.2.1... what my gcc is 10.2.0
<weilewei> zao good suggestion
<gnikunj[m]> zao noted
<gnikunj[m]> > hmmm the system one is 1.11.11 from the system, but that is built in gcc 8.2.1... what my gcc is 10.2.0
<gnikunj[m]> Just use the standard RHEL that the system comes with?
<zao> As for troubleshooting builds, you _really_ want your make/ninja to print command lines so you can tell what actually is passed to the compiler/linker.
<zao> The hardcoded paths to software seem a bit odd but I guess Spack might not offer anything better. Maybe things would work better if you activated views and relied on CPATH/LIBRARY_PATH/etc.?
<zao> You may want to verify that the layout of the roots you specify look right and that the CMake process actually looks at the right place and finds what it expects.
<weilewei> Sure, I will try it out
<zao> Also watch out for things like static libraries, as their link order is significant and they may not be suitable in a when building shared libraries as their symbols do not propagate.
<zao> (not saying they're involved here, but hard to tell without command lines)
<zao> You may also want to compare against a build on a known good system.
hkaiser has quit [Quit: bye]
weilewei has quit [Remote host closed the connection]