Good to know. Now I don't understand why it occurs. My testing seems to show that we don't even enter hwloc_topology_init(). If Windows lazily loads DLLs, it could mean that libhwloc-15.dll is only loaded when the first hwloc function is called, and that loading would fail for some reason such as ABI mismatch. Do you know if that's possible on Windows? If so, would we get an error popup in such a case? And is there a way to debug dynamic linking issues? On Linux we have ldd and nm/objdump for checking which libraries are used and what symbols they contain.
Brice Le 23/07/2020 à 19:32, Jon Dart a écrit : > That was it - the older DLL was in the path. Thanks for looking into it. > > --Jon > > On 7/22/2020 6:02 AM, Brice Goglin wrote: >> >> Hello Jon >> >> Sorry the delay. I finally got some time to look at this. I can only >> reproduce the issue when I am compiling against hwloc 2.0.4 and using >> 2.2.0 at runtime (placing libhwloc-15.dll in the current directory). If >> using the same version (either 2.0.4 or 2.2.0) for both compiling at >> running, the program works fine. Can you double-check if you were mixing >> versions? >> >> If so, it may look like some sort of ABI break. I am trying to find out >> where hwloc_topology_init() crashes. >> >> Brice >> >> >> _______________________________________________ >> hwloc-users mailing list >> hwloc-users@lists.open-mpi.org >> https://lists.open-mpi.org/mailman/listinfo/hwloc-users > > > _______________________________________________ > hwloc-users mailing list > hwloc-users@lists.open-mpi.org > https://lists.open-mpi.org/mailman/listinfo/hwloc-users _______________________________________________ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
