https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258463
--- Comment #6 from [email protected] ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/ports/commit/?id=a1edd535d35d03e2d54a49bffac39035b990a716
commit a1edd535d35d03e2d54a49bffac39035b990a716
Author: Dimitry Andric <[email protected]>
AuthorDate: 2021-09-12 19:44:36 +0000
Commit: Dimitry Andric <[email protected]>
CommitDate: 2021-10-02 10:58:25 +0000
x11/libwacom: work around lld 13 no longer supporting symver tricks
Though x11/libwacom was not yet built during the exp-run for clang/llvm
13 (see bug 258209), due to some other dependencies not being available
yet, I noticed that it failed to build with clang 13, or more
specifically this is due to a behavior change in lld 13:
...
[ 33% 10/30] cc -o generate-hwdb generate-hwdb.p/tools_generate-hwdb.c.o
-Wl,--as-needed -Wl,--no-undefined -fstack-protector-strong -O2 -pipe -g
-fstack-protector-strong -fno-strict-aliasing '-Wl,-rpath,$ORIGIN/'
-Wl,-rpath-link,/wrkdirs/share/dim/ports/x11/libwacom/work/libwacom-1.5/_build/
-Wl,--start-group libwacom.so.2.6.1 /usr/local/lib/libglib-2.0.so
/usr/local/lib/libintl.so -Wl,--end-group
[ 36% 11/30] /usr/local/bin/meson --internal exe --capture
65-libwacom.hwdb --
/wrkdirs/share/dim/ports/x11/libwacom/work/libwacom-1.5/_build/generate-hwdb
FAILED: 65-libwacom.hwdb
/usr/local/bin/meson --internal exe --capture 65-libwacom.hwdb --
/wrkdirs/share/dim/ports/x11/libwacom/work/libwacom-1.5/_build/generate-hwdb
--- stderr ---
Unfortunately the meson build process doesn't really show you why it
failed, but it turns out that running the 'generate-hwdb' command
segfaults:
Starting program:
/wrkdirs/share/dim/ports/x11/libwacom/work/libwacom-1.5/_build/generate-hwdb
Program received signal SIGSEGV, Segmentation fault.
libwacom_add_match (device=device@entry=0x801031320, newmatch=0x0) at
../libwacom/libwacom.c:943
943 device->matches[device->nmatches - 1] =
libwacom_match_ref(newmatch);
(gdb) bt
#0 libwacom_add_match (device=device@entry=0x801031320, newmatch=0x0) at
../libwacom/libwacom.c:943
#1 0x000000080024fc7d in libwacom_matchstr_to_match
(device=device@entry=0x801031320, matchstr=<optimized out>) at
../libwacom/libwacom-database.c:207
#2 0x000000080024e313 in libwacom_parse_tablet_keyfile (db=0x8010365a0,
datadir=0x200b70
"/wrkdirs/share/dim/ports/x11/libwacom/work/libwacom-1.5/data",
filename=<optimized out>) at ../libwacom/libwacom-database.c:652
#3 load_tablet_files (db=0x8010365a0, datadir=0x200b70
"/wrkdirs/share/dim/ports/x11/libwacom/work/libwacom-1.5/data") at
../libwacom/libwacom-database.c:865
#4 libwacom_database_new_for_path (datadir=0x200b70
"/wrkdirs/share/dim/ports/x11/libwacom/work/libwacom-1.5/data") at
../libwacom/libwacom-database.c:959
#5 0x00000000002021b6 in main (argc=<optimized out>, argv=0x801036630)
at ../tools/generate-hwdb.c:131
What happens is that an internal function 'libwacom_match_new' is
supposed to be called, which returns a new 'WacomMatch' object. But
instead, it calls a empty stub which returns NULL, resulting in this
segfault. The empty stub was added as a rather nasty upstream hack to
"Alias the accidentally exposed ABI into different functions", in
https://github.com/linuxwacom/libwacom/commit/b9961dbe912fa096230460b194eebdc8a590d256:
> A special "trick" is used here to hide the ABI from new versions:
> Usually when defining multiple versioned symbols, one would define one as
the
> default one with @@
> .symver _foo1,foo@VERSION1
> .symver _foo2,foo@@version2 <-- default one
> By leaving out the default one, ld doesn't know which one to link to and
> fails with an unresolved symbol. rtld however can still figure it out, so
> anything compiled will continue to work. This way we can make a symbol
> disappear from the library for new builds but have old builds continue to
> work with the new version.
Unfortunately this trick/hack does not work anymore with lld 13, since
https://github.com/llvm/llvm-project/commit/66d44304921, ("[ELF] Combine
foo@v1 and foo with the same versionId if both are defined "). The idea
behind the hack is to have the linker call the 'real' libwacom_match_new
function whenever it is called from inside the library itself, but any
external callers get the stubbed version which doesn't really do
anything.
I think libwacom should have used a different approach here, but just
renaming those accidentally exposed internal functions to something
different. Then the tricks with .symver are completely unnecessary. Here
I added a patch that is as simple as possible, which adds #defines for
two affected functions in libwacomint.h, renaming then from
'libwacom_xxx' to 'libwacom_internal_xxx'. This does not affect the
corresponding exposed functions in the libwacom.so, and makes the
'generate-hwdb' command work OK again. I also ran the complete libwacom
test suite, including the deprecated functions test, and it works fine.
PR: 258463
Approved by: zeising (maintainer)
MFH: 2021Q4
x11/libwacom/files/patch-libwacom_libwacomint.h (new) | 12 ++++++++++++
1 file changed, 12 insertions(+)
--
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.