On a ~AMD64 system with: [ebuild R ] sci-libs/metis-5.2.1-r1::gentoo USE="openmp -double-precision -examples -int64" 0 KiB if one tries to dlopen libmetis.so, for example via: python Python 3.11.3 (main, Apr 6 2023, 05:59:54) [GCC 12.2.1 20230304] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> CDLL('/usr/lib64/libmetis.so') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python3.11/ctypes/__init__.py", line 376, in __init__ self._handle = _dlopen(self._name, mode) ^^^^^^^^^^^^^^^^^^^^^^^^^ OSError: /usr/lib64/libmetis.so: undefined symbol: gk_jbufs it is clear there are missing symbols. This did not used to be the case and breaks any applications which try and dynamically load METIS. Reproducible: Always
Upstream has unbundled GKlib, which is where you'll find the missing symbols. Applications that link to metis should also link to GKlib, the pkgconfig file already takes this into account.
And what about the numerous applications which dlopen libmetis.so at runtime? pkg-config is not an option for them. For over a decade this has worked without issue (as it should do, and does for 99.9% of shared libraries). Unbundling gklib is fine and probably a good thing; but there is no reason this should result in a broken shared library; if one needs a symbol convention is to mark the associated library as a dependency so the dynamic linker knows to bring it in at runtime.
I can confirm this. This also fails to (re-)build existing packages. I noticed it while working on bug #905804, but it also happens when trying to build current =media-gfx/netgen-6.2.2301 with USE="gui mpi" enabled. FAILED: ng/netgen : && /usr/bin/x86_64-pc-linux-gnu-g++ -O2 -pipe -march=znver2 -frecord-gcc-switches -fstack-check -fPIC -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 ng/CMakeFiles/netgen.dir/ngappinit.cpp.o -o ng/netgen -Wl,-rpath,/var/tmp/portage-ondisk/portage/media-gfx/netgen-6.2.2301/work/netgen-6.2.2301_build:/var/tmp/portage-ondisk/portage/media-gfx/netgen-6.2.2301/work/netgen-6.2.2301_build/libsrc/core: libnggui.so /usr/lib64/libtcl.so /usr/lib64/libtk.so libnglib.so libsrc/core/libngcore.so ng/Togl2.1/libtogl.a /usr/lib64/libXmu.so /usr/lib64/libX11.so /usr/lib64/libtclstub.a /usr/lib64/libtkstub.a /usr/lib64/libmpi.so /usr/lib64/libOpenGL.so /usr/lib64/libGLX.so /usr/lib64/libGLU.so && : /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_log2' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_CPUSeconds' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_realloc' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_sigtrap' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_jbufs' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_malloc' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_siguntrap' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_cur_jbufs' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_mcorePush' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_randint32' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_malloc_cleanup' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_malloc_init' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_mcorePop' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_rmpath' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_errexit' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_mcoreDestroy' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_mcoreMalloc' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_free' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_randinit' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_idxsmalloc' /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmetis.so.0: undefined reference to `gk_mcoreCreate' collect2: error: ld returned 1 exit status
We can safely pull in that PR.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c78ecbd3fdf9b33e307023baf0de12c4448dd283 commit c78ecbd3fdf9b33e307023baf0de12c4448dd283 Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2023-05-07 08:10:58 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2023-05-07 08:12:47 +0000 sci-libs/metis: ensure GKlib is marked as NEEDED Closes: https://bugs.gentoo.org/905822 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> .../metis/files/metis-5.2.1-add-gklib-as-required.patch | 15 +++++++++++++++ .../{metis-5.2.1-r1.ebuild => metis-5.2.1-r2.ebuild} | 2 ++ 2 files changed, 17 insertions(+)
This should have fixed the problem: ldd /usr/lib64/libmetis.so.0 linux-vdso.so.1 (0x00007ffcee1c2000) libGKlib.so => /usr/lib64/libGKlib.so (0x00007f4ab07ff000) libc.so.6 => /usr/lib64/libc.so.6 (0x00007f4ab062d000) /lib64/ld-linux-x86-64.so.2 (0x00007f4ab08bc000) libm.so.6 => /usr/lib64/libm.so.6 (0x00007f4ab0554000) Could you double check that it actually works for you now? This package is being very problematic, so if it is still not working maybe we just mask this version for now.
(In reply to Andrew Ammerlaan from comment #6) > This should have fixed the problem: > > ldd /usr/lib64/libmetis.so.0 > linux-vdso.so.1 (0x00007ffcee1c2000) > libGKlib.so => /usr/lib64/libGKlib.so (0x00007f4ab07ff000) > libc.so.6 => /usr/lib64/libc.so.6 (0x00007f4ab062d000) > /lib64/ld-linux-x86-64.so.2 (0x00007f4ab08bc000) > libm.so.6 => /usr/lib64/libm.so.6 (0x00007f4ab0554000) > > > Could you double check that it actually works for you now? > > This package is being very problematic, so if it is still not working maybe > we just mask this version for now. Both versions link correctly with -r2
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=80612d7f47f5560f9f8a7f308619354c325ac07c commit 80612d7f47f5560f9f8a7f308619354c325ac07c Author: Sam James <sam@gentoo.org> AuthorDate: 2023-05-10 01:44:11 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-10 01:44:29 +0000 profiles: mask (gone) =sci-libs/metis-5.2.1-r1 too This version was broken as well, but -r2 is fine. Mask so people don't get confusing errors. Bug: https://bugs.gentoo.org/905822 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
