https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258463
Bug ID: 258463
Summary: x11/libwacom: Fix build with clang/lld 13
Product: Ports & Packages
Version: Latest
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: Individual Port(s)
Assignee: [email protected]
Reporter: [email protected]
Assignee: [email protected]
Flags: maintainer-feedback?([email protected])
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.
--
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.