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/
nanmiao11 has joined #ste||ar
<hkaiser>
tiagofg[m]: would you have a minimal full example?
<hkaiser>
so you are loading a shared library that has an HPX component dynamically
<hkaiser>
is HPX initialized from the executable or the shared library?
<hkaiser>
tiagofg[m]: I think I understand why in such a scenario the above error would show
hkaiser has quit [Quit: bye]
bita has joined #ste||ar
nanmiao11 has quit [Remote host closed the connection]
akheir has quit [Quit: Leaving]
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 256 seconds]
K-ballo1 is now known as K-ballo
bita has quit [Ping timeout: 240 seconds]
hkaiser has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
jbjnr_ has joined #ste||ar
jbjnr_ has quit [Ping timeout: 260 seconds]
jbjnr has joined #ste||ar
K-ballo has quit [Ping timeout: 246 seconds]
K-ballo has joined #ste||ar
<tiagofg[m]>
hkaiser: HPX is initialized from an executable and I'm loading a shared library that has an HPX component dynamically, I guess is that
<tiagofg[m]>
hkaiser: here is the minimal example that fail at runtime
<hkaiser>
you need this for all shared libraries that expose a component
<tiagofg[m]>
let me do that then
jbjnr has quit [Ping timeout: 264 seconds]
<hkaiser>
you might have to use HPX_REGISTER_DYNAMIC_MODULE(); instead as the shared library is dynamically loaded, pls try both (one at a time)
<hkaiser>
K-ballo: in my experience do all compilers today handle globals in shared libraries in the same way - the 'global' in this case means global to the code in the shared library
<hkaiser>
except if the data is dll-exported
<hkaiser>
what's your experience with this?
<hkaiser>
so if you're not careful you may run into ODR violations
<tiagofg[m]>
hkaiser: I had put hpx.component_paths wrong, it works with the correct path, without HPX_REGISTER_COMPONENT_MODULE() or HPX_REGISTER_DYNAMIC_MODULE()
<tiagofg[m]>
problem solved for now!! thanks
<hkaiser>
ahh, I think you should add that macro anyways (the DYNAMIC one)
<tiagofg[m]>
hkaiser: right
<tiagofg[m]>
thank you all for your time
<hkaiser>
most welcome
<hkaiser>
tiagofg[m]: as a hint - if you place the shared library in a ./hpx/ subdir to the executable you shouldn't need the command line option
<tiagofg[m]>
hkaiser: ok very nice
<tiagofg[m]>
hkaiser: so, what did you mean was create a directory named hpx inside the directory where executable is, and put the .so inside /hpx?
<hkaiser>
yes
<tiagofg[m]>
but if I run without --hpx:ini=... the error happens again, I think I'm doing it right
<hkaiser>
ok
<hkaiser>
even with the macro?
<tiagofg[m]>
with HPX_REGISTER_COMPONENT_MODULE() yes, I tried with HPX_REGISTER_DYNAMIC_MODULE() but fail at compiling
<tiagofg[m]>
let me see
<tiagofg[m]>
you mean put HPX_REGISTER_DYNAMIC_MODULE() with ; after?
<hkaiser>
you might need the ';'
<tiagofg[m]>
error: expected constructor, destructor, or type conversion before ‘;’