Thursday, May 30, 2019

Re: [patch] devel/meson: enable detection of libexecinfo

On Wed, May 29 2019, Andreas Kusalananda Kähäri <andreas.kahari@abc.se> wrote:
> Since Meson updated from 0.50.0 to 0.50.1, the libexecinfo library, if
> installed, is not properly detected with Meson's find_library(). The
> attached patch (modification of an existing patch file that we already
> have) fixes this for OpenBSD.
>
> I have also opened an issue about this on the Meson Github pages.
> https://github.com/mesonbuild/meson/issues/5432

This one got me curious.

The NetBSD folks have added libexecinfo to their base system years ago.

http://cvsweb.netbsd.org/bsdweb.cgi/%7echeckout%7e/src/lib/libexecinfo/Makefile

This doesn't look like code from our devel/libexecinfo port, rather
a reimplementation using either __builtin_frame_address or the _Unwind*
API.

The FreeBSD folks then imported the code from NetBSD.

https://github.com/freebsd/freebsd/commit/c269490987041ebfff61039a2653346eae305f0d

I do not understand why the meson folks consider the execinfo library as
a "unixy_compiler_internal_lib", especially when looking at this code:

--8<--
class CCompiler(Compiler):
# TODO: Replace this manual cache with functools.lru_cache
library_dirs_cache = {}
program_dirs_cache = {}
find_library_cache = {}
find_framework_cache = {}
internal_libs = unixy_compiler_internal_libs
[...]
def find_library_real(self, libname, env, extra_dirs, code, libtype):
# First try if we can just add the library as -l.
# Gcc + co seem to prefer builtin lib dirs to -L dirs.
# Only try to find std libs if no extra dirs specified.
if not extra_dirs or libname in self.internal_libs:
args = ['-l' + libname]
largs = self.linker_to_compiler_args(self.get_allow_undefined_link_args())
if self.links(code, env, extra_args=(args + largs)):
return args
# Don't do a manual search for internal libs
if libname in self.internal_libs:
return None

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

# Not found or we want to use a specific libtype? Try to find the
# library file itself.
patterns = self.get_library_naming(env, libtype)
-->8--

To me libexecinfo looks just like another library, except for the fact
that it uses special compiler/runtime support. NetBSD installs it as

/usr/lib/libexecinfo.so.0.0

not in a weird path a la

/usr/lib/$compiler/$version/libexecinfo.a

In the comments on commit

https://github.com/mesonbuild/meson/commit/8b065530f6aeebb8ad0af2c58a91c06db82d6491

Bruce Richardson says:

"Can you perhaps also include "-lexecinfo" into the list, as it's
a frequently needed library on freebsd."

Being "frequently needed ... on freebsd" doesn't look like a compelling
argument for treating execinfo as a special lib, and is definitely wrong
for us.

My 2 cents


: Index: patches/patch-mesonbuild_compilers_compilers_py
: ===================================================================
: RCS file: /extra/cvs/ports/devel/meson/patches/patch-mesonbuild_compilers_compilers_py,v
: retrieving revision 1.12
: diff -u -p -r1.12 patch-mesonbuild_compilers_compilers_py
: --- patches/patch-mesonbuild_compilers_compilers_py 18 Apr 2019 09:55:15 -0000 1.12
: +++ patches/patch-mesonbuild_compilers_compilers_py 29 May 2019 16:36:18 -0000
: @@ -13,6 +13,15 @@ Subject: [PATCH] Fix indent to please co
: Index: mesonbuild/compilers/compilers.py
: --- mesonbuild/compilers/compilers.py.orig
: +++ mesonbuild/compilers/compilers.py
: +@@ -82,7 +82,7 @@ cflags_mapping = {'c': 'CFLAGS',
: + 'rust': 'RUSTFLAGS'}
: +
: + # execinfo is a compiler lib on BSD

This comment ought to be removed or amended, just like the test in run_unittests.py

: +-unixy_compiler_internal_libs = ('m', 'c', 'pthread', 'dl', 'rt', 'execinfo')
: ++unixy_compiler_internal_libs = ('m', 'c', 'pthread', 'dl', 'rt')
: +
: + # All these are only for C-linkable languages; see `clink_langs` above.
: +
: @@ -1491,7 +1491,9 @@ class GnuLikeCompiler(abc.ABC):
: self.compiler_type = compiler_type
: self.base_options = ['b_pch', 'b_lto', 'b_pgo', 'b_sanitize', 'b_coverage',
:

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

No comments:

Post a Comment