[Bug 258463] x11/libwacom: Fix build with clang/lld 13

[email protected]
Newsgroups gmane.os.freebsd.devel.x11
Message-ID <[email protected]/bugzilla/>
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.