[mythtv] Mixed debug/release build
danielk at cuymedia.net
Fri Aug 24 23:53:22 UTC 2007
On Sat, 2007-08-25 at 01:35 +0200, Michael Haas wrote:
> Daniel Kristjansson wrote:
> > Have you seen ticket #3589? Would that be compatible with apport?
> I'm not sure, I'll have to ask an apport wizard.
> > If so, would it fill your needs. You can already compile with
> > compile type profile and get an optimized build with debugging
> > symbols.
> #3589 looks interesting. I'm not sure if I understand what it does,
> though. It strips the debugging symbols and puts them into a separate
> file, right? For the Ubuntu packages, we're already doing that
> ourselves. The build script has some clever magic which automatically
> strips dbg symbols and puts them in separate packages. Atrpms seems to
> have separate packages with debug symbols, too.
Yes, it strips the debug symbols and places them in external files.
The Ubuntu packages may be doing the same magic as this patch, or
it may be doing something non-standard. If you could consult with
your apport wizard it might be a vote in favor of #3389. if Ubuntu
is already doing this.
> > A profile build stack trace isn't as good as a debug
> > build one for debugging, but it is often sufficient.
> I was told that "proper" debug builds are preferred over profile builds,
> that's why I actually wrote that patch. Of course, I can't find relevant
> IRC logs so I can't prove anything :) Consensus seemed to be that
> optimized builds are too hard to debug.
Yes, proper debug builds are preferred.
> > It also has
> > the benefit of having symbols for libavcodec, libavutil, which in
> > my experience generate most of the difficult segfaults.
> In my patch, the debugging symbols are kept as well. It's essential a
> debug build which uses -O3 for certain parts of MythTV.
Ah! That's really great then.
Ideally "release" would just build with the changes in #3589 and your
changes by default, if the toolchain supports external debugging
symbols. And only build a completely stripped release with some new
type such as "naked-release" or if an old toolchain was being used.
We might even be able to get rid of the "profile" compile flag if we
drop support for profiling with old toolchains.
The only real problem I can see with this is that avlib often breaks
when you combine gcc optimization with "-g", not a big deal to fix
once in a while for a profile build, but we might need to fix after
every other ffmpeg resync if debugging and optimization were enabled
for the avlib libraries under the "release" complile-type.
More information about the mythtv-dev