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
K-ballo has quit [Quit: K-ballo]
<zao> Interesting... I did a dynamic build with vcpkg (against static TBB) and libhpx fails to link: https://gist.github.com/zao/ac778178bc95e3cbcddcc11937441029
hkaiser_ has quit [Ping timeout: 258 seconds]
<zao> The build of tests have a whole lot more additional symbols missing over the one I added to the issue, everything from ones in `libatomic` to `partitioned_vector` and `component_heap` and probably more - build log: https://gist.github.com/zao/d1775a0ac8a28584033c229818704c43
Yorlik has joined #ste||ar
hkaiser has joined #ste||ar
<hkaiser> zao: that TBB error is not caused by HPX, is it? it's a tbb symbol missing...
K-ballo has joined #ste||ar
ct-clmsn has joined #ste||ar
hkaiser has quit [Quit: Bye!]
ct-clmsn has quit [Quit: This computer has gone to sleep]
ct-clmsn has joined #ste||ar
ct-clmsn has quit [Quit: This computer has gone to sleep]
hkaiser has joined #ste||ar
<zao> hkaiser: The TBB use is from HPX code in `lib/libhpx_collectivesd.a(communication_set_node.cpp.o)`and that particular symbol is defined in `libtbb.a`, which isn't linked in at all on that command line. If one has a dynamic TBB I guess that might transitively be linked by a shared library, I don't have any logs for a shared with shared dependencies build to compare with.
<hkaiser> zao: HPX does not rely on tbb in any way
<zao> So it seems apart from some tests, so how on earth is it pulled in? The best I can find is that Boost's config talks about how <execution> depends on TBB with libstdc++.
<hkaiser> zao: yes, that's true, try adding -DHPX_WITH_CXX17_STD_EXECUTION_POLICES=Off when running cmake
<zao> OK, will try. Just gotta coax vcpkg into rebuilding rather than use the binary cache.
<hkaiser> delete the cache!
<zao> hkaiser: libhpxd.so.1.9.1 built fine with that option.
<zao> Next failure on `libhpx_compression_bzip2d.so.1.9.1`, where `libboost_iostreams.a` depends on bzip2 but the link order is again the wrong way around.
<zao> `ld ... /proj/inya/krangler/build/vcpkg_installed/x64-linux/debug/lib/libbz2d.a /proj/inya/krangler/build/vcpkg_installed/x64-linux/debug/lib/libboost_iostreams.a ...`
<zao> Static libraries are the gift that just keeps on giving.
<hkaiser> *grumble*
<hkaiser> not even sure what I can do about that
<zao> I guess it might be some sort of order that libraries are supplied in `components/parcel_plugins/binary_filter/bzip2/CMakeLists.txt`?
<zao> I'm honestly not sure how far down to keep digging with static libraries for dependencies.
<zao> vcpkg's `x64-linux` triplet unfortunately seems to favour static libraries if it can.
<zao> (there's a `x64-linux-dynamic` triplet I might be able to use instead, but it's unfortunate if HPX can't be used out of the box with vcpkg)
<zao> It's up to you how far you wish to dig into these things, I'm fine as long as I can workaround things personally. Might be able to make a PR for vcpkg later on to get the version bumped - it'll at least be about as broken as before for weird configurations and probably work still on MSVC.
<hkaiser> zao: I did fix the bzip library sequence and the parcelport symbol problem
<hkaiser> zao: I'd need to see the cmake log to have an understanding what's happening wrt libatomic
<hkaiser> I will also setup a github action staticly building on linux
<zao> Seeing if I can isolate the libatomic fault with a log.
<zao> hkaiser: configure+build of `bin/freelist_test` with libatomic failures: https://gist.github.com/zao/a38e3eba3b5171cc7da50a662d83314f
<zao> I've seen `-latomic` in other build command lines that have scrolled past, I guess it might not have carried quite over to the use site of `libhpx*.a` when building the test.
<zao> (scrolled past in the past, not sure if there were any in this particular one)
<hkaiser> are you sure it's available?
<zao> Not entirely available it seems.
<zao> There's `/usr/lib/gcc/x86_64-redhat-linux/13/libatomic.so` which is actually a linker script of `INPUT ( /usr/lib64/libatomic.so.1.2.0 )`. Said file doesn't exist on the system.
<zao> The `libatomic` package is not installed indeed.
<zao> I guess that I might not have gotten everything development-related installed on this machine as I only installed `gcc-c++`.
<zao> There's also a `libatomic-static` package, not sure which one is normally present.
<zao> Installing `libatomic` now makes the three lines in the log go SUCCESS, FAILED, SUCCESS.
<hkaiser> good
<hkaiser> so it found the library
<zao> Running the build of the test again.
<hkaiser> pull first, please
<zao> I'm on "77bf8505da (HEAD -> pr/6320, origin/fixing_cyclic_dependencies) Fixing cyclic dependencies related to parcelport symbols"
<zao> Now links libatomic, single other symbol missing: `parcelport_tcp_factory_init` - https://gist.github.com/zao/44efd6e364a1460b00dd40cd66583399
<hkaiser> darn, I thought I fixed this
<hkaiser> zao: can you show me this file: /mnt/stellar/builds/hpx-git/libs/full/parcelset/include/hpx/parcelset/static_parcelports.hpp, please?
<hkaiser> ok, that's a bit more work, then :/
<zao> vcpkg build failed to configure HPX with x64-linux-dynamic, couldn't find MPI (Package 'mpi-cxx', required by 'virtual:world', not found)
<zao> (testing all sorts of things at the same time in different environments, so that's not a viable workaround either for me)
<hkaiser> zao: that error means that vcpkg's mpi installation is broken
<hkaiser> I was fighting the same the other day
<zao> Looking forward to writing this code in serial in the end, as that's what's going to end up working ;)
<hkaiser> lol
<hkaiser> ok, pushed another attempt...
<zao> Configure bails out with `Cannot find source file: libs/full/parcelset/src/static_parcelports.cpp`.
<hkaiser> yah, added that just now
<zao> [438/438] Linking CXX executable bin/freelist_test
<zao> [stellar@stellar-fedora stellar]$
<zao> huzzah!
<hkaiser> \o/
<hkaiser> zao: thanks again!
<zao> Gonna build the rest of the tests too, slowly.
<zao> Forgot to make it not bail on errors, so possibly more too.
<hkaiser> it gets better and better :/
<zao> /tmp/ccq3UFBl.s: Fatal error: can't write 3887 bytes to section .debug_info of examples/transpose/CMakeFiles/transpose_serial_vector.dir/transpose_serial_vector.cpp.o: 'No space left on device'
<hkaiser> yah, I expected that to happen
<zao> I had "only" given it 256 gigs.
<hkaiser> pah, that's nothing