lib.
ClosedPublic
Actions

Authored by jhb on Mar 22 2022, 4:48 PM.

Details

Reviewers

pizzamig

Commits

R11:92d6b833f0a0: devel/gdb: Handle recent 14.0 systems with libc++ in /lib.

Summary

The auto-load python wrapper for libc++ pretty printers has to be
installed at the same path as libc++ to work correctly. Update the
port to install the top-level wrapper in lib/ under the auto-load data
directory instead of usr/lib on recent 14.0 systems.

Diff Detail

Repository

R11 FreeBSD ports repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

jhb created this revision.Mar 22 2022, 4:48 PM

Herald added a subscriber: mat. · View Herald TranscriptMar 22 2022, 4:48 PM

jhb requested review of this revision.Mar 22 2022, 4:48 PM

Harbormaster completed remote builds in B44858: Diff 104091.Mar 22 2022, 4:48 PM

emaste added inline comments.Mar 22 2022, 5:03 PM

devel/gdb/Makefile
173	does gdb bulid/work with no libc++ at all?

pizzamig added inline comments.Mar 22 2022, 10:04 PM

devel/gdb/Makefile
173	no, gdb is a C++ application, so it cannot be built without libc++ I guess the libc++ pretty printer conditions could be reworked/simplified assuming that libc++ is always available. Is there any possibility that libc++.so.1 is not available?

emaste added inline comments.Mar 22 2022, 11:33 PM

devel/gdb/Makefile
173	Mmm, I guess it is still possible to build without libc++ right now but see D33108 which avoids libc++ and C++ applications in the base system. I think it would be fine to remove the `.if` condition and just require that one of the two paths will exist but it's also fine to just leave tihs.

jhb added inline comments.Mar 22 2022, 11:50 PM

devel/gdb/Makefile
173	Yeah, when I first added this to the port we still had platforms using GCC instead of clang that didn't support libc++. I could assume it is always present at this point if that is preferred.