[mythtv] [mythtv-commits] Ticket #11012: mythtv-0.25.2_p20120716 - configure sets incorrect CFLAGS
Raymond Wagner
raymond at wagnerrp.com
Thu Aug 16 21:47:07 UTC 2012
On 8/16/2012 15:39, MythTV wrote:
> #11012: mythtv-0.25.2_p20120716 - configure sets incorrect CFLAGS
> ----------------------------------+-----------------------------
> Reporter: klamp <klampiar@…> | Owner:
> Type: Bug Report - General | Status: closed
> Priority: minor | Milestone: unknown
> Component: MythTV - General | Version: Unspecified
> Severity: medium | Resolution: Won't Fix
> Keywords: CFLAGS | Ticket locked: 0
> ----------------------------------+-----------------------------
>
> Comment (by klamp <klampiar@…>):
>
> Hm, that's exactly something I would expect from developers of software
> that segfaults every 60 minutues or so. No hard feelings involved, just
> observation of performance of your code @ gentoo.
>
I've been a big proponent of Gentoo, and the whole concept of "compile
your own Linux", since I started using it in the mid-2000s. I had
previously used, and still use, FreeBSD for anything that doesn't
require Linux for hardware compatibility, and the architecture of Gentoo
is the next closest thing. You don't have to worry about complex chains
of interdependent package versions. You don't have to compile in every
feature under the sun, under the odd chance someone somewhere will want
to use it. If you are missing a feature, recompile. If you have a
version mismatch, recompile. If you have a compatibility issue,
recompile. It's the simple, if perhaps not very quick, end all solution
to most problems.
The problem with compiling everything, and potentially doing it
repeatedly, is that the people most likely to put up with all that CPU
load are the "tuners" who think by fiddling with every last compiler
feature, they can eek another couple percent of performance out of their
applications. At least in my opinion, this type of use is a perversion
of the Gentoo ethos. Let the package system or build scripts decide what
is the best configuration on their own. If you think you are intelligent
enough to know better for your particular scenario, then you're
intelligent enough to patch the ebuild or build scripts yourself. If you
think it has value outside your own personal use, by all means submit
the patch upstream.
When you start blanketing non-standard compile flags to everything on
your system on a whim, that's when you really start running into
stability issues. Most things that are not standard are not standard for
good reason. I can honestly say I don't find MythTV the least bit
unstable. Just about the only time I've seen a segfault since maybe 0.20
or 0.21 has been either when I've been tinkering with some piece of code
and am in the process of debugging it, or have done something absurd
like pushed video to a remote XMing X11 server using XShm. If you are
experiencing them frequently and repeatedly, open up the core dump and
submit a ticket with the backtrace. If it were something one of the devs
was experiencing, it would have been fixed in short order. Process of
elimination means it's not, and so the only way it is going to be known
is if you report it.
The one exemption to the above is when trying to perform
cross-compilation for another system. In such cases, it is simply not
possible for the build scripts to determine the best configuration for
the system on their own. They need external specifications to do so for
them, however cross-compilation is a very different problem, and must be
handled differently than simple manual tuning parameters.
More information about the mythtv-dev
mailing list