[Bug 295213] math/hydrogen: enable aluminum when OPENMPI=on, fix linking re: private symbol __extendhfxf2

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295213

            Bug ID: 295213
           Summary: math/hydrogen: enable aluminum when OPENMPI=on, fix
                    linking re: private symbol __extendhfxf2
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: yuri@freebsd.org
          Reporter: milios@ccsys.com
             Flags: maintainer-feedback?(yuri@freebsd.org)
          Assignee: yuri@freebsd.org

Created attachment 270622
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=270622&action=edit
v0 WIP

before i linked aluminum, i was getting:

/usr/ports/misc/lbann/work/lbann-0.104/include/lbann/execution_algorithms/kfac/kfac_block.hpp:46:18:
error: no member named 'Al' in the global namespace; did you mean simply 'Al'?
46 | using BackendT = ::Al::MPIBackend;
   |                  ^~~~
   |                  Al
/usr/ports/misc/lbann/work/lbann-0.104/include/lbann/comm_nb_request.hpp:39:11:
note: 'Al' declared here
39 | namespace Al {
   |           ^

which is probably lbann's fault (aluminum was not installed nor selected) but
this made that problem go away (i use openmpi-5.0.10).

before i hacked in that -print-libgcc-file-name i was getting (near the end of
the lbann build):

ld: error: undefined reference: __extendhfxf2
>>> referenced by /usr/local/lib/libHydrogen_CXX.so.1.5.3 (disallowed by --no-allow-shlib-undefined)
c++: error: linker command failed with exit code 1 (use -v to see invocation)

not sure if there's a more appropriate way to solve that issue. probably need
to register gcc as a build/run depend to go this route (i wasnt sure how to do
it correctly without triggering other framework logic that may affect the
build; base clang is still used to compile so maybe i should be finding that
symbol from /usr? i see a whole lot of -std=gnu++17 in the build so im not
quite sure how we're actually supposed to handle this. i went this route
because my libHydrogen_CXX.so ended up linked against libgcc_s.so.1; maybe this
problem doesnt even occur if gcc were absent from the system altogether (i
didnt try eliminating it).

please review with utmost scrutiny, as if drafted by artificial intelligence or
genuine stupidity.

also peculiar, -Wl here is clearly an anomalous flag mangling/parsing bug but i
couldnt track that down. (dihydrogen too, btw)
root@Mark:/usr/ports/math/hydrogen # readelf -d
/usr/local/lib/libHydrogen_CXX.so.1.5.3|grep RUNPATH
 0x000000000000001d RUNPATH              Library runpath:
[-Wl:/usr/local/lib/gcc15:/usr/local/mpi/openmpi/lib:/usr/local/mpi/openmpi/lib]

we could also live without the redundant openmpi/lib but thats the least of our
worries

-- 
You are receiving this mail because:
You are the assignee for the bug.