hkaiser 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/ | GSoC2018: https://wp.me/p4pxJf-k1
<nikunj>
what does this error mean: symbol lookup error: ./bin/hello_world: undefined symbol: _ZN3hpx4lcos6detail16future_data_baseINS_6traits6detail16future_data_voidEE19handle_on_completedIN5boost9container12small_vectorINS_4util15unique_functionIFvvELb0EEELm3ENS9_13new_allocatorISE_EEEEEEvOT_
<K-ballo>
there was discussion of dropping the small_vector in the shared state recently, did that happen?
<zao>
Not enough cats.
<nikunj>
I'm getting these errors while running make test
<nikunj>
most of the tests are failing due to some or the error symbol lookup error
<nikunj>
has something changed recently with the current master?
<nikunj>
or does it have something to do with my PC?
<K-ballo>
small_vector still in use
<K-ballo>
could it be some great boost version messup? the code uses vector conditionally when small_vector is not available
<K-ballo>
though nothing I can think of would explain failure linking within a single build
<nikunj>
I'm using boost 1.66 and it was working fine when I last tested
<nikunj>
HPX tests ran perfectly as well. I was checking my patch for #3426 when tests started to fail. I thought maybe it has to do something with the patch, but current master behaved the same.
aserio has joined #ste||ar
<nikunj>
zao, yt?
<nikunj>
K-ballo, on a deeper look it seems like _ZN3hpx4lcos6detail16future_data_baseINS_6traits6detail16future_data_voidEE19handle_on_completedIN5boost9container12small_vectorINS_4util15unique_functionIFvvELb0EEELm3ENS9_13new_allocatorISE_EEEEEEvOT_ is the only function that is giving this error
<nikunj>
Every error seems to come up due to this very function
<nikunj>
Have we done something with it recently?
<K-ballo>
if we had it would reflect in your build, wouldn't it?
<K-ballo>
unless something was so messed up with the build that you somehow ended up linking stale binaries
<nikunj>
true
<nikunj>
I think I should build everything from scratch to confirm if it's just my build
<zao>
Stale build or stale install?
<nikunj>
I did a build not install
david_pfander has quit [Ping timeout: 276 seconds]
<zao>
K-ballo: How about mismatching Boost std=c++?
<zao>
Could it possibly heck things up?
<zao>
I still don't know if to build HPX with 14 or something else, I keep forgetting why I workaround.
<K-ballo>
it could, but not within a single build, could it?
<K-ballo>
no way the tests use a different boost than the one used for building core
<zao>
I guess.
<nikunj>
should I add a cmake tag to make it build with 14?
<zao>
I'm just pondering.
<zao>
nikunj: I would recommend setting up _another_ build tree, build there, and see if it works.
<zao>
Keeping the previous one for investigations like looking at what symbols are in libs/objs, and whatnot.
aserio has quit [Read error: Connection reset by peer]
aserio has joined #ste||ar
aserio has quit [Ping timeout: 252 seconds]
Vir has quit [*.net *.split]
nanashi55 has quit [*.net *.split]
Guest82434 has joined #ste||ar
<jbjnr__>
is there a command line option to say, use all cores, but not hyperthreads, (so on my laptop, use 4 threads not 8) without knowing how many ocres there are etc
<simbergm>
jbjnr__: --hpx:bind might get you what you want but I don't think there's a nice, easy to remember option
<jbjnr__>
I can do it if I say --hpx:threads=4 --hpx:bind=thread:0-3=core:0-3.pu:0 but that assumes I know the core count beforehand
<jbjnr__>
I think I'd better add an --hpx:bind=cores option to just do one thread per core regardless of num sockets, hyperthreads etc etc