Date: Mon, 05 Mar 2018 23:20:27 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-doc@FreeBSD.org Subject: [Bug 226382] Add a section about respecting WITH_DEBUG to the Chapter 13. (Dos and Don'ts) Message-ID: <bug-226382-9@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226382 Bug ID: 226382 Summary: Add a section about respecting WITH_DEBUG to the Chapter 13. (Dos and Don'ts) Product: Documentation Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Documentation Assignee: freebsd-doc@FreeBSD.org Reporter: 0mp@FreeBSD.org During the development of the new www/quark port, which is now pending to be reviewed and committed, I had to decided how I want to strip the final bina= ry.=20 On the one hand, the upstream Makefile adds -s to LDFLAGS, which according = to ld(1) mean "omit all symbol information from the output file". On the other hand, chapter 5.16.2. "Stripping Binaries and Shared Libraries" suggests to use STRIP_CMD in post-install. As long as our only goal is to strip the final binary, both approaches are = fine and the workflow should look like this (assuming that we are not dealing wi= th build systems like CMake and Autotools, which probably do all the magic on their own): 1. If the upstream already strips binaries then we're done. 2. Add STRIP_CMD to post-install. This is already described in the handbook and used in many ports. Also, it is an easily recognizable pattern to new p= orts developers. This is why the STRIP_CMD approach is better than adding "LDFLAGS+=3D-s" to portname/Makefile.=20 It is not so easy however, because we would like to respect WITH_DEBUG. It would be nice to have a reminder in the handbook that the binaries should n= ot be striped out of their debug symbols when WITH_DEBUG is set. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-226382-9>