<nikunj>
hkaiser: I tried building the latest hpx and seems everything is working there. I was trying to build phylanx but I'm stuck here. Could you please help so that I can take a look into the problem?
<zao>
nikunj: The compile command line has `-Werror=parentheses`. Maybe the build shouldn't be asking for warnings-as-errors for warnings you don't want to treat as errors :D
<hkaiser>
what I meant was that you could try adding such pragmas, they exist for gcc as well, same syntax just s/clang/gcc
<hkaiser>
zao: I have no idea where that comes from ;-)
<hkaiser>
we definitely do not set those for Phylanx
<rori>
oh yeah thanks! so that is not cached anymore, cool
<rori>
nikunj: I feel like I already got this one but I don't remember how I solved it. You may want to try to find libLLVM-9.so file and add the path to it in your LD_LIBRARY_PATH
<nikunj>
rori: turns out this is the case here. It won't find libLLVM-9.so
<zao>
Unless the packager of clang has screwed up on Arch, if it's a dependency to the compiler it ought to be installed.
<nikunj>
most likely clang package got screwed on arch
<rori>
Try copy pasting the compilation line `/usr/bin/clang++ -o CMakeFiles/cmTC_9362c.dir/testCXXCompiler.cxx.o -c /home/nk/Downloads/hpx/build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx` using verbose flags
<zao>
/usr/lib/libLLVM-9.so is owned by llvm-libs 9.0.0-3
<rori>
So you may try to hack the clang++ command adding linker flags with the absolute path to the library, if this doesn't work sorry I don't know
<zao>
`pacman -Qo /usr/lib/libLLVM-9.so` is your friend :)
<nikunj>
turns out installing clang 9.0 installs libLLVM-9
<nikunj>
libLLVM-8.0^^
<nikunj>
instead of libLLVM-8.0
<nikunj>
^^libLLVM-9.0
<nikunj>
aah typos
<nikunj>
this thing is strange
<zao>
You can reinstall from existing downloads with `pacman -S clang llvm-libs`.
<zao>
As llvm-libs and clang are not versioned, I guess that you might have some skew in their versions?
<nikunj>
zao: yes, sudo pacman -S llvm llvm-libs makes it working
<zao>
Yay
<nikunj>
trying to compile hpx with clang 9 now
<nikunj>
will build phylanx later
<nikunj>
warnings as errors is very frustrating :3
<nikunj>
hkaiser: just built hpx with make VERBOSE, -wrap=main exists as a linker flag
<nikunj>
seems like we screwed somewhere within the phylanx cmake build maybe
<nikunj>
let me have a look
<nikunj>
hkaiser: this is very strange as hpx_setup_target should be able to take care of everything by default
<heller>
hkaiser: I really forgot how much expression templates are
<heller>
K-ballo: regarding compile times: my basic future test program compiles in 1.2 seconds, just including <hpx/lcos/future.hpp> ramps this up to 3.9 seconds
<K-ballo>
my compile times...
<hkaiser>
heller: a full-fletched implementation will amount to the same compile times
<heller>
let's hope for the best
<hkaiser>
simbergm, rori: di you add -Wall -Wextra etc. to the build system?
<heller>
I think we always had it for building HPX itself
<heller>
we didn't use to propagate it though
<hkaiser>
ok, but now it's propagated to dependent projects
<heller>
hkaiser: regarding compile times: I think we are able to remove quite a few dependencies from the future implementation there. The customization points are pretty awesome
<hkaiser>
rori: I think that we can fix things for Phylanx and other dependent projects, but people might not want to have the full -Wall etc
<hkaiser>
heller: ok
<hkaiser>
heller: that's the least f my worries atm, however
<heller>
we should not propagate *any* warning related flags to our dependent targets
<hkaiser>
I agree
<heller>
hkaiser: what are you mostly worried about?
<nikunj>
hkaiser: clang does not consider warnings as errors, yayy
<hkaiser>
get all of this current mess under control
<rori>
we do that `hpx_add_compile_flag_if_available(-Wall LANGUAGES CXX C Fortran)`
<heller>
fair enough ;)
<nikunj>
I'll try to make things working now
<rori>
but I haven't touch it so it should be as it was before
<hkaiser>
rori: having it for hpx is fine
<heller>
rori: that should only set the private flags for the hpx target though
aserio has joined #ste||ar
<rori>
I can create a target with hpx_compile_flags and only link it privately to hpx
<rori>
Ah so if it's already private, this shouldn't be forwarded
<rori>
I'll check that in details
<hkaiser>
: thanks
<heller>
rori: could be that some of the libraries have it in as PUBLIC
<heller>
which would explain things
<rori>
actually yes but I grepped -Wall -Wextra, so it's not set manually anyway, and if it's from an external library, this would complicate things as the PUBLIC or PRIVATE flag apply to all properties of the library
<rori>
ok actually it's in hpx_add_compile_flag_if_available we set the flag without any PRIVATE, I'll add an option
<rori>
ah no sorry the PRIVATE is by default
weilewei has joined #ste||ar
hkaiser has quit [Quit: bye]
<nikunj>
zao: I have openmpi installed
<nikunj>
yet phylanx tells me it can't find lopm
<nikunj>
any reasons why it's happening on arch?
<heller>
rori: you should be able to use the cmake build unit test to figure out what's wrong
<zao>
"lopm"?
<simbergm>
nikunj: are you building hkaiser's branch of phylanx or master?
<heller>
rori: this target seems to get import when doing a find_package(HPX). This has hall the warning flags
<nikunj>
to check why it would expose the linker errors
<simbergm>
heller yep
<heller>
rori: in addition to the C++ version. This needs to get cleaned up
<simbergm>
I think we'll add an explicit option to link to internal flags, off by default
<simbergm>
hpx_internal_flags used to not be exported
<nikunj>
simbergm: I can tell that with surity, once I'm able to build phylanx
<rori>
yep I'll add the option
<nikunj>
ohh if they're not exported it won't work
<nikunj>
the linker flag is crucial to be exported
<nikunj>
to make everything work
<rori>
But should hpx_setup_target be used outside of hpx ?
<heller>
rori: yes
<rori>
ok !
<simbergm>
rori: yep :)
<heller>
rori: it is even documented ;)
<rori>
haha sorry ^^
<heller>
rori: yup. not importing that target works
<simbergm>
because of cmake target fun I think we have to export it even if it's not used outside
<heller>
well, if we export it, we need to find a way to not automatically have it setup as a link dependency when configuring dependent projects
<rori>
yeo I'm on it ;)
weilewei has quit [Remote host closed the connection]
<simbergm>
heller: yep, it'll be an option to hpx_setup_target and friends, off by default
<heller>
simbergm: we want to have it for our examples and tests, but not for external projects, right? So why not just add yet another cache variable ;)?
<simbergm>
that works as well, but an option seems nicer and more explicit
hkaiser has joined #ste||ar
<zao>
nikunj: How's it going? :)
<nikunj>
having troubles
<nikunj>
reminds me of the bad ol' days
<nikunj>
can't find -lomp for some reason
<heller>
simbergm: also means that we have to add it for all our internal targets
<zao>
nikunj: That's OpenMP, not OpenMPI.
<heller>
nikunj: that's the openmp runtime for llvm/clang
<simbergm>
nikunj: do you know if your main wrapper stuff will break badly if hpx_wrap gets linked to libraries? i.e. does it really only have to be linked to executables directly?
<nikunj>
ohh crap
<nikunj>
my bad
<nikunj>
thanks!
<simbergm>
heller: yes, of course ;)
<nikunj>
works now
<hkaiser>
simbergm: executables only and could be merged with hpx_init
<nikunj>
simbergm: yes. it is supposed to be linked only with executables
<simbergm>
right, I know it's supposed to but can it be linked to libraries as well?
<simbergm>
I
<nikunj>
it will throw multiple declaration errors otherwise
<zbyerly>
zao, do you know which name came first, OpenMP or OpenMPI?
<simbergm>
ok, thanks
<simbergm>
hkaiser: nikunj thinking about what our targets should do in the end
<nikunj>
that's why we have documented it that way. We can't let libraries make use of libhpx_wrap
<simbergm>
target_link_libraries(my_target hpx) won't work generically for executables and libraries so we'll have to introduce some new targets for that purpose
<simbergm>
we might want hpx_applciation, hpx_component, hpx_library etc
<heller>
zbyerly: openmpi was first released on october 17, 2006, openmp is around since 1997
<simbergm>
or, if we allow for users to not use hpx_wrap just linking to hpx might be enough, explicitly linking to hpx_wrap would make magic opt-in
<nikunj>
anyone encountered this: /usr/bin/ld: CMakeFiles/algorithms_primitive.dir/lra.cpp.o:(.data.rel.ro+0x78): undefined reference to `typeinfo for phylanx::execution_tree::primitives::primitive_component_base'
<zbyerly>
heller, i'm going to do some more digging and figure out why they named it OpenMPI when it was so close to OpenMP
<heller>
zbyerly: maybe that's exactly the reason
<heller>
zbyerly: same as with HPX being close to HPC :P
<simbergm>
hkaiser: are you happy with #4142 and #4147?
<heller>
c and x are right next to each other
<zbyerly>
X and C are way different letters
<simbergm>
heller: I can't write hpc anymore without making it hpx first :P
<heller>
exactly!
<zao>
Be happy you don't work at a site called HPC2N.
<heller>
zbyerly: look at your keyboard!
<zbyerly>
heller, I'm such a pro that my keys aren't labeled on my keyboard
<zbyerly>
and i use Dvorak
<heller>
lol
<heller>
well, poor you, missing out on the fun ;)
<zbyerly>
heller, SC this year?
<heller>
and glad to see you around again!
<heller>
nope
<heller>
zbyerly: where are you at nowadays?
<zbyerly>
heller, my wife and I are making tentative plans to visit Germany next summer
<zbyerly>
heller, LSU HPC, user support services
<zbyerly>
you know, "have you tried deleting your job and submitting it again?"
<heller>
cool!
<heller>
well, we are in nuremberg, happy to welcome you if you wish
<nikunj>
ugh!! Errors keep popping up
<nikunj>
this is very frustrating
<nikunj>
I'll take a break and freshen my mind now
<simbergm>
nikunj: I hope you're not trying to fix the hpx_wrap problems?
<nikunj>
simbergm: I think that would be easier to resolve compared to what I'm going through