Bug 275443 - graphics/mesa-dri: tries to use devel/elfutils API against base elftoolchain ABI
Summary: graphics/mesa-dri: tries to use devel/elfutils API against base elftoolchain ABI
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Emmanuel Vadot
URL:
Keywords: regression
Depends on:
Blocks: 273803
  Show dependency tree / graph
 
Reported: 2023-11-30 03:20 UTC by Jan Beich
Modified: 2024-01-26 06:02 UTC (History)
6 users (show)

See Also:
manu: maintainer-feedback-

Attachments
workaround (prefer elfutils) (1.77 KB, patch)
2023-11-30 03:20 UTC, Jan Beich 		no flags Details | Diff
patch (2.37 KB, patch)
2024-01-25 17:03 UTC, Ivan Rozhuk 		rozhuk.im: maintainer-approval?
Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer freebsd_triage 2023-11-30 03:20:28 UTC 
Created attachment 246680 [details]
workaround (prefer elfutils)

Mixing ABIs between different projects with compatible API can lead to instability or crashes. While -Dlibelf=disabled prevents Meson (pkg-config) from using devel/elfutils other dependencies add -I/usr/local/include which end up overriding C preprocessor search order.

  $ pkg install elfutils
  $ echo '#error API trap' >>/usr/local/include/libelf.h
  $ make clean all -C graphics/mesa-dri
  [...]
  FAILED: src/amd/common/libamd_common.a.p/ac_rtld.c.o
  In file included from ../src/amd/common/ac_rtld.c:32:
  In file included from /usr/local/include/gelf.h:32:
  /usr/local/include/libelf.h:523:2: error: API trap
  #error API trap
   ^
  In file included from ../src/amd/common/ac_rtld.c:33:
  /usr/local/include/libelf.h:523:2: error: API trap
  #error API trap
   ^
  2 errors generated.

See also PKG_CONFIG_SYSTEM_INCLUDE_PATH in pkgconf(1) manpage
https://wiki.freebsd.org/WarnerLosh/UsrLocal#Include_paths
https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html
Comment 1 Emmanuel Vadot freebsd_committer freebsd_triage 2023-12-01 12:01:47 UTC 
Confirmed locally that this patch does the right thing, if I have elfutils installed mesa is then linked against it and everything works.
Comment 2 Emmanuel Vadot freebsd_committer freebsd_triage 2023-12-04 07:19:53 UTC 
Jan, do you plan to land this or should I ?
Comment 3 Jan Beich freebsd_committer freebsd_triage 2023-12-04 08:03:16 UTC 
No. I'm not sure what to put into the commit message and don't want to deal with upstreaming. Besides, base libelf can be forced via CPPFLAGS+=-idirafter ${LOCALBASE}/include
Comment 4 Benjamin Takacs 2023-12-04 10:11:09 UTC 
(In reply to Jan Beich from comment #0)
As noted in https://docs.freebsd.org/en/books/porters-handbook/makefiles/#makefile-automatic-dependencies this workaround shouldn't be used as it causes problems when the building system changes and with it the dependencies of the port.
Comment 5 Mina Galić freebsd_triage 2023-12-04 10:22:52 UTC 
ref: ports 9f41e650f5645f1e50d8e51eb53ea231ff9f5149
Comment 6 Ivan Rozhuk 2024-01-25 17:03:44 UTC 
Created attachment 247955 [details]
patch

This patch forces use system libelf.
Comment 8 Emmanuel Vadot freebsd_committer freebsd_triage 2024-01-25 18:42:02 UTC 
NAK, current ports is correctly made, use poudriere to build in a clean env.
Comment 9 Ivan Rozhuk 2024-01-25 19:01:37 UTC 
(In reply to Emmanuel Vadot from comment #8)

Use poudriere yourself.
Comment 10 Jan Beich freebsd_committer freebsd_triage 2024-01-25 20:44:32 UTC 
Comment on attachment 247955 [details]
patch

Why such a large patch instead of -idirafter like comment 3 suggested?
Comment 11 Ivan Rozhuk 2024-01-25 20:54:30 UTC 
(In reply to Jan Beich from comment #10)

If it work - cool. I never see this option before )

Patch also disables: libudev, openmp, xcb_keysyms
and remove libelf dep if it installed from ports.
Comment 12 Emmanuel Vadot freebsd_committer freebsd_triage 2024-01-26 06:02:58 UTC 
(In reply to Jan Beich from comment #10)

Pretty sure I tested -idirafter and I wasn't able to make it work correctly.