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/
parsa has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
jaafar has quit [Ping timeout: 244 seconds]
hkaiser has quit [Quit: bye]
ravibitsgoa has joined #ste||ar
<ravibitsgoa>
Hi everyone, is this a good place to ask queries about building hpx?
ravibitsgoa has quit [Ping timeout: 256 seconds]
nanashi55 has quit [Ping timeout: 268 seconds]
nanashi55 has joined #ste||ar
parsa has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
jaafar has joined #ste||ar
ravibitsgoa has joined #ste||ar
<ravibitsgoa>
While running make for hpx, I am getting the following error: [ 39%] Linking CXX shared library ../lib/libhpx.dylib Undefined symbols for architecture x86_64: "boost::system::detail::system_category_instance"
<ravibitsgoa>
Can anyone help with this?
<K-ballo>
ravibitsgoa: are you using boost 1.68.0?
<K-ballo>
has it been build for C++98/11, and is being consumed from a 14/17/2a codebase?
jaafar has quit [Ping timeout: 264 seconds]
<ravibitsgoa>
I am using boost 1.68.0 built from source.
<ravibitsgoa>
but I think I got something wrong while building it.
<K-ballo>
I'm guessing you went with the default flags, rather than specifying C++14 or 17 or
<ravibitsgoa>
@K-ballo: I am not sure. I gave c++14 as standard, but it still doesn't work.
<K-ballo>
maybe there was a typo in the flag, that's a known 1.68 11/14 abi compatibility
<K-ballo>
or maybe it's trying to link to a different boost build, perhaps the system one?
<K-ballo>
did you do something like b2 cxxflags=-std=c++14?
ravibitsgoa has quit [Ping timeout: 256 seconds]
mdiers_1 has joined #ste||ar
mdiers_ has quit [Read error: Connection reset by peer]
<ste||ar-github>
hpx/fix_guided_exec 88b843f John Biddiscombe: Fix order of template params in execution::post
ste||ar-github has left #ste||ar [#ste||ar]
<jbjnr_>
heller_: I had a vtk-m PR to get it merged with the master, but they merged some other changes first that broke it - this happened around the time I was transferred into the other group here at CSCS and viz stuff got dropped, so my branch needs a few tweaks to get going. Have not been following the vtkm development for a while, so not sure what else has changed in the meantime.
<ste||ar-github>
hpx/fix_guided_exec dbeb6a8 John Biddiscombe: Disable stealing of low-priority threads
ste||ar-github has left #ste||ar [#ste||ar]
<simbergm>
jbjnr_ (IRC): you've been working hard, thanks!
<simbergm>
did changing to an older hwloc help?
<jbjnr_>
yes. With my fixes (pushed more this morning) it works fine on the hwloc 1.11.x release chain, but our implementation of hwloc 2.x is not correct. I kind of knew that when someone fixed things for hwloc 2.x a few months ago becuase it just didn't look right, but I didn't have any proof.
<ste||ar-github>
hpx/master 0e66257 Mikael Simberg: Merge pull request #3536 from STEllAR-GROUP/update_lsu_support...
ste||ar-github has left #ste||ar [#ste||ar]
ravibitsgoa has joined #ste||ar
<ravibitsgoa>
K-ballo: Yes, I used c++14 flag while compiling boost
<ravibitsgoa>
Can it be due to some other reason?
<ravibitsgoa>
building*
<jbjnr_>
ravibitsgoa: can you confirm that the boost detected by cmake in your build is the right one? it's not accidentally linking to the system boost is it?
<ravibitsgoa>
jbjnr_: I think it is linking to the right boost only. How do I verify the same?
<heller_>
look at the command line of the link step
<jbjnr_>
make VERBOSE=1
<jbjnr_>
^^ use theat command line to see the full compile and link flags
<jbjnr_>
or "make <target> VERBOSE=1"
<jbjnr_>
(VERBOSE=1 only works with cmake generated projects)
<jbjnr_>
if the link step is calling another cmake generated script, then you can look at the contents directly with any old editor, or cat
<jbjnr_>
OR ...
<jbjnr_>
run ccmake, press "T" to look at advanced options, and then manaully inspect all the boost flags and libs that are detected
ravibitsgoa has quit [Ping timeout: 256 seconds]
<simbergm>
jbjnr_ (IRC): never mind or still something?
<jbjnr_>
I was going to ask if yu could trigger a clang build on pycicle of my fix_guided_exec branch, but I triggered one on rostam instead
<simbergm>
okeydokey
<simbergm>
jbjnr_ (IRC): how about we recommend hwloc < 2 for the release and mention the numa issues in the notes, leaves us (you...) more time look into the changes in hwloc 2?
<ste||ar-github>
hpx/release 113c426 Mikael Simberg: Add note about hwloc 2 NUMA domain handling to build instructions
ste||ar-github has left #ste||ar [#ste||ar]
<simbergm>
jbjnr_ (IRC): ^]
<jbjnr_>
simbergm: probably the best thing to do is recommend hwloc 1.11.x rather than 2.x for now. I had to go out over lunch, so stopped looking in to it. Hopefully the fix is reasonably straightforward, but we don't want to delay a release at this stage.
<jbjnr_>
Please do merge my guided_exec_fix if the builds pass though
<jbjnr_>
can't see anything on rostam yet
<simbergm>
I meant the commit ^
<simbergm>
I updated the build instructions to recommend hwloc < 2
<simbergm>
guided exec can go in if it passes, but otherwise it'll have to wait
<simbergm>
main goal was to get it into master, bug fixes can come later ;)
<simbergm>
oh, you mean don't merge if it passes?
<simbergm>
ok, I can't read
<simbergm>
"do merge if builds pass", will do
<jbjnr_>
aha. I see your note. yes. good idea. No DO merge my stuff if it passes. It'd be great if cholesky runs on master
<jbjnr_>
can't see any clang build results
<simbergm>
yes, it would be great
<simbergm>
rostam seems stuck on configure for a couple of hours
<simbergm>
my pycicle has some builds about to start soon
<zao>
So I'm guessing that if ravibitsgoa has installed both an old tagged/system build of Boost and a versioned build of Boost, the new libraries will not be used?
<zao>
Do you have a CMakeCache.txt?
<ravibitsgoa>
yeah, I have a system build and a versioned build of boost, but I found a workaround, by manually copying the versioned files into the normal location :P
<ravibitsgoa>
Does that work?
<zao>
As our documentation explicitly advises having a versioned installation, if it doesn't work out of the box something ought to be done about it.
<ravibitsgoa>
It's still giving the same linking error.
<zao>
Could you please make a Boost installation into a separate location (--prefix=$HOME/opt/boost-cxx14 to b2) and when configuring HPX, run -DBOOST_ROOT=$HOME/opt/boost-cxx14 ?
<zao>
[100%] Built target core
<zao>
With your broken setup, did a -DHPX_WITH_CXX11=ON succeed or fail as well?
<ravibitsgoa>
with my setup, -DHPX_WITH_CXX11=ON also failed.
<ravibitsgoa>
Now I will try with separate location.
<K-ballo>
what's the output?
<ravibitsgoa>
the output was same as the previous one.
<K-ballo>
it can't be
<K-ballo>
it ought to either compile, or fail with a different error
<K-ballo>
depending on whether boost was built for 11 or 14
<ravibitsgoa>
Currently, I am trying with different location.
<ravibitsgoa>
in the previous case, hpx was compiling, but not linking.
<K-ballo>
what was the linker error?
<ravibitsgoa>
Undefined symbols for architecture x86_64: "boost::system::detail::system_category_instance",
<K-ballo>
are you positive you are linking against boost 1.68?
<ravibitsgoa>
yes
<K-ballo>
does not compute to me, I'll pass it along to boost people
<zao>
K-ballo: Built three combinations thus far, matched HPX and Boost C++ standards work for 11 and 14. HPX C++11 w/ Boost C++14 succeds building core.
<zao>
HPX C++14 w/ Boost C++11 is building currently.
<zao>
(all on macos)
<K-ballo>
so far so good.. the current build ought to fail, it is not supported anymore
<jbjnr_>
hkaiser: I know that you don't want to hear it, but these kind of boost related issues are why people tell me they will not use hpx as long as it depnds on boost. If we have boost as a subdir in hpx and can control the build reliably, then we'll be fine. We must start experimenting with the modularized cmakeified boost if it exists yet.
jaafar has quit [Ping timeout: 276 seconds]
<jbjnr_>
it should be easy and straightforward, but I'venoticed recently that my boost layout=versioned doesn't get picked up properly on every system and i've had to drop down to tagged and system layouts sometimes.
<hkaiser>
jbjnr_: sure, not my fault, though
<jbjnr_>
noone is blaming you
<jbjnr_>
certainly not me
<jbjnr_>
are you at SC?
<jbjnr_>
oops. not till sunday
<hkaiser>
and I'm not against removing boost dependencies where possible, I'm just against a blind 'boost is bad' attitude
<hkaiser>
jayeshbadwaik: yes, I'll be at SC
<jbjnr_>
better that than a blind HPX is bad attitude!
<hkaiser>
shrug
<hkaiser>
your call
<K-ballo>
this one in particular is not boost's fault, it is a bogus expectation on our side of guarantees that were never given
<jbjnr_>
guarantees of what?
<hkaiser>
we can for instance replace boost.regex with std regex which will cause a slowdown by a factor of 100
<hkaiser>
jayeshbadwaik: do you want that?
<K-ballo>
we can't expect things build for different standard versions to be compatible
<hkaiser>
jbjnr_: ^^
<K-ballo>
it just worked by mere chance in the past, it is not guaranteed to work, this is not a boost bug
<jbjnr_>
ok. I would not expect them to anyway, but sadly some of our users are new to all this stuff
<zao>
On the subject, what about it not finding versioned libraries properly?
<K-ballo>
that's just C++
<K-ballo>
there's plenty to blame boost for, this is not one of those things
<jbjnr_>
zao: I wasted half a day recently trying to get hpx to detect boost on one machine and it just refused. New cmake, broken stuff.
<jbjnr_>
new cmake + new boost + pain
<jbjnr_>
never discovered what was wrong, but I think it went away when I wiped everything clean and started from nothing.
<jbjnr_>
but I still wasted a lot of time on it
parsa[[w]] is now known as parsa[w]
<ravibitsgoa>
phew! Finally building hpx worked!
nanashi55 has quit [Ping timeout: 272 seconds]
nanashi55 has joined #ste||ar
<ravibitsgoa>
with this: boost for C++14, or hpx for C++11
<K-ballo>
which one?
<ravibitsgoa>
sorry, I meant both at once.
<ravibitsgoa>
Now, how should I proceed?
<ravibitsgoa>
I am supposed to work on parallel algorithms
<K-ballo>
pick one or the other, don't mix, there's no guarantee things work if you mix, that was your original problem
<K-ballo>
you either build both for 11, or both for 14, (or both with whatever set of flags you prefer)
<ravibitsgoa>
ah, but it worked only I mixed.
<ravibitsgoa>
I had to use boost with 14 flag and hpx with 11 flag
<ravibitsgoa>
I haven't tried other combinations yet
<zao>
I would recommend looking into what remains of Boost installations you've got in /usr/local, and strongly prefer using an installation with --prefix= to b2 and -DBOOST_ROOT to HPX's CMake.
ravibitsgoa has quit [Ping timeout: 256 seconds]
aserio has joined #ste||ar
parsa[w] has quit [Read error: Connection reset by peer]
parsa[w] has joined #ste||ar
jaafar has joined #ste||ar
hkaiser has quit [Quit: bye]
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 252 seconds]
aserio1 is now known as aserio
aserio has quit [Quit: aserio]
parsa has joined #ste||ar
parsa has quit [Client Quit]
aserio has joined #ste||ar
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 264 seconds]
aserio1 is now known as aserio
bibek has quit [Quit: Konversation terminated!]
hkaiser has joined #ste||ar
jaafar has quit [Quit: Konversation terminated!]
jaafar has joined #ste||ar
aserio has quit [Quit: aserio]
jaafar has quit [Ping timeout: 250 seconds]
<jbjnr_>
simbergm: just fyi - probably too late now, but I'm testing a fix for the hwloc 2 numa issue. hopefully have it ready by tomorrow.