hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
ct-clmsn has joined #ste||ar
hkaiser has quit [Ping timeout: 246 seconds]
hkaiser has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: Bye!]
ct-clmsn has quit [Quit: This computer has gone to sleep]
hkaiser has joined #ste||ar
K-ballo has joined #ste||ar
<zao>
I took a look at Google's Marl while not being able to build HPX. Looks kind of cute but unmaintained and extremely underdocumented and sparsely used.
<zao>
Gonna have to take the vcpkg build and make a registry with my own ports bumped to 1.9.0 (.1?) and see if it still builds.
<zao>
Maybe in the weekend.
<hkaiser>
zao: yah, we need to update the hpx port in vcpkg :/
<hkaiser>
only needs a new sha256 key
<zao>
That was what I was curious about, if the build and their patches still work as they should.
<zao>
Heaven knows what you people do between releases ;)
<zao>
I expect all sorts of hilarious breakages.
<hkaiser>
zao: in theory all should be well ;-)
hkaiser has quit [Quit: Bye!]
hkaiser has joined #ste||ar
<zao>
oh for crying out loud. Building HPX in my VM with 16 GiB of RAM got the whole VM killed by the oom killer :D
ct-clmsn has joined #ste||ar
<zao>
hkaiser: having dinner atm but it seems like 1.9.1 completed the build process
<hkaiser>
nice!
<zao>
`-- Configuring done (1317.6s)`
ct-clmsn has quit [Quit: This computer has gone to sleep]
ct-clmsn has joined #ste||ar
ct-clmsn has quit [Client Quit]
ct-clmsn has joined #ste||ar
<zao>
grmbhl... I wonder if this always was broken, vcpkg on Linux keeps reusing binary artifacts when I change kits to use different compilers, triggering HPX's compiler matching logic.
<zao>
Maybe it always builds with GCC by design and I could/should override the HPX compiler compatibility thing.
hkaiser has quit [Quit: Bye!]
ct-clmsn has quit [Quit: This computer has gone to sleep]
<zao>
There seems to be a linker command line order problem, where `libhpx_naming.a` occurs before `libhpx_naming_base.a`
<zao>
My code doesn't call any HPX stuff yet, just includes `hpx/hpx.hpp`.
<hkaiser>
zao: well, we don't test static libraries on linux - anything could happen
<zao>
Was just gonna ask if anyone tests and uses them :D
<hkaiser>
so any insights (like the one above) are helpful
<hkaiser>
also, isnt' it correct for a library to appear first if it depends on the second?
<zao>
Missing symbols are gathered from earlier libraries, to be satisfied by later libraries indeed.
<zao>
Here the symbol is defined in libhpx_naming.a (and then discarded as no uses has occurred yet), followed by an use in libhpx_naming_base.a which then doesn't get any satisfaction.
<hkaiser>
naming should depend on naming_base, something is wrong if there is an dependency the other way around
<hkaiser>
zao: do you know what symbol is missing?
<zao>
It's there on line 8 of the output: `hpx::naming::detail::gid_managed_deleter(hpx::naming::detail::id_type_impl*)`
<hkaiser>
uhh, not good - can you give me the log, please? I'll try to have a look
<zao>
Not sure if have a VM somewhere I can pollute with enough dependencies to build HPX myself.
diehlpk_work has joined #ste||ar
ct-clmsn has joined #ste||ar
hkaiser_ has joined #ste||ar
hkaiser has quit [Ping timeout: 240 seconds]
<zao>
hkaiser_: Doesn't even need my code involved to trigger a problem, linking of `bin/executor_with_thread_hooks` fails on another library, `agas` vs. `agas_base`.