David Holland <dholland-pkgtech%netbsd.org@localhost> writes: > On Tue, Feb 24, 2015 at 11:57:03AM -0700, Brook Milligan wrote: > > I am not familiar with the DBG variable and what it is to do. So > > far the ffmpeg2 package is the only anomaly I am running into. > > In the NetBSD base build system, DBG is a place to stick -g vs. -O2, > so can be used to hack in other CFLAGS without making a huge mess. Agreed. We have been building base and pkgsrc with debugging, and this is done for base by having this in mk.conf: MKDEBUG= yes MKDEBUGLIB= yes DBG= -g > I'm not sure if pkgsrc honors it when setting the default CFLAGS > passed to packages, but even if it does it's not all that likely that > any given package honors the default CFLAGS. Most have to be patched > to, and most haven't been if it wasn't required to get things building > in the first place. To make packages build with debugging, we have: CFLAGS+= -ggdb CXXFLAGS+= -ggdb INSTALL_UNSTRIPPED= yes and that seems to at least mostly work. We did not run down that every single package we built (just under 1K) had debugging, but this was enough to make the ones that we needed to debug have symbols. I'd argue that a program whose build system doesn't follow CFLAGS (and CPPFLAGS, and LDFLAGS) from the environment is buggy; that's the normal way to pass in -I and -L. But there is no standard and there's a lot of mess. Arguably the right thing for pkgsrc to do is to patch build systems to behave correctly since pkgsrc has a notion of setting these variables. If the ffmpeg2 package is escaping from wrappes by finding and using absolute paths, that seems like the first thing to fix.
Attachment:
pgpzwfLG_MIbK.pgp
Description: PGP signature