-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libadios2_serial_evpath.so.2.10.0: undefined reference to `cmfabric_add_static_transport' #4156
Comments
Unfortunately, this is probably the same issue as #4103 . ADIOS is looking for libfabric before EVPath does, which messes with the CMake in EVPath and produces undesirable results. In #4103, the solution was to simply not have libfabric installed. Neither EVPath nor ADIOS need or uses it unless you are on a machine with an RDMA transport. Alternatively, you can run cmake with -DCMAKE_DISABLE_FIND_PACKAGE_LIBFABRIC=TRUE, or -DADIOS2_USE_SST=FALSE (if you don't need the SST streaming transport). This problem should be fixed in master branch, and so will be fixed in 2.10.1 when that release happens. |
Thanks. One of the design goals for the debian packages is to support clusters (cloud computing), so RDMA (and fbric) support is wanted. I'll look forward to the new release, and try the workarounds or patches in the meantime. |
|
Same with both |
Not sure what's going on with the workarounds, but you might try github master. Libfabric can installed on non-RDMA machines of course, and will configure itself to offer only the sockets-based provider which is theoretically useful for testing libfabric code. In practice however it's not useful (for complicated reasons), and libfabric code like that in ADIOS is quite likely not to work if there's not a real RDMA provider underneath libfabric. Certainly if it does work, performance would be terrible, which is why we don't generally know if ADIOS would build in this circumstance, we don't do it. Instead, ADIOS takes the presence of certain libraries as indicative of the sort of machine that it's on and builds features accordingly. Unfortunately this isn't the sort of dependency that packaging systems seem to capture well. |
Thanks. I'll report again if I can confirm that the problem is lifted (or not) in a later code base. |
I'm still getting undefined references with 2.10.1, with
|
And still fails with
|
That the linker isn't finding libraries that are built as part of the ADIOS build:
seems to be an insurmountable problem. Then again, the names here look strange. Normally the libraries should be libadios2_ffs.so.2.10, without the extra "_serial" in it. Ah, I was going to ask for how you configured ADIOS, but I followed the "debian/rules" link above and it looks like debian has a quite complex build system that bypasses most of our stuff, for example deleting everything under ADIOS/thirdparty and using external versions of those libraries. Offhand I'd say that however those libraries are build built, they either aren't named correctly or the paths are set correctly for the link to find them. How that's supposed to be working I have no idea. Not something the adios team has had a direct hand in. |
The debian packaging added the In the case of I'll test a separate manual build without the debian package considerations and see at which point I can reproduce the problem (or not) manually. |
It's been a long time since the original debian package rules were produced for ADIOS. In the meantime, the ADIOS build system itself has been rewritten to produce both serial and MPI versions of the ADIOS library in a single build. Presumably this means that the debian rules will need some adjustment. |
Building a debian package for adios 2.10.0 fails with "libadios2_serial_evpath.so.2.10.0: undefined reference to `cmfabric_add_static_transport'":
cmfabric_add_static_transport
is used in EVPath/cm_transport.c if libfabric is found (libfabric 1.17.0 is available). But libfabric does not define cmfabric_add_static_transport.EVPath/cmfabric.c contains an extern definition. But it is wrapped by
_WITH_IB_
. Evidently_WITH_IB_
is not available.There seems to be an inconsistency between
LIBFABRIC_FOUND
using cmfabric_add_static_transport in cm_transport.c and_WITH_IB_
defining cmfabric_add_static_transport in cmfabric.c.To Reproduce
A minimal reproducible example is preferred.
Or Steps to reproduce the behavior:
-DEVPATH_TRANSPORT_MODULES=OFF
) given in debian/rulesExpected behavior
Build should not have undefined references, or should signal a missing component during cmake configuration if required
Desktop (please complete the following information):
Additional context
If
-DEVPATH_TRANSPORT_MODULES=ON
is used instead (ON instead of OFF), a swarm of other undefined symbols is reported:The text was updated successfully, but these errors were encountered: