[mythtv-users] Mythtv compilation problems on FC4

[Malcolm Hill]

On Wed, 2006-02-01 at 07:24 +1100, Jarod Wilson wrote:
> On Monday 30 January 2006 16:37, Malcolm Hill wrote:
> > On Mon, 2006-01-30 at 09:06 -0800, Jarod Wilson wrote:
> > > On Monday 30 January 2006 05:02, Malcolm Hill wrote:
> > > > I've been using Mythtv 0.18.2 happily on FC4 for months now
> > >
> > > There is no such thing as MythTV 0.18.2, only a 0.18.1 release and what
> > > *could* have been 0.18.2 in subversion's 0-18-fixes branch.
> >
> > I called it 0.18.2 because on http://svn.mythtv.org/trac/ its called the
> > 'stable 0.18.2 branch'.  I guess you are correct that its the 0-18-fixes
> > branch.
> >
> > > > So - now the configure script finds lirc fine - but I'm having real
> > > > issues compiling mythtv.  The same source that built fine a few months
> > > > ago...  In that time yum has updated my kernel a few times, and I'm
> > > > sure its upgraded gcc.
> > >
> > > Are you trying to compile from a 0.18.1 tarball or from a 0-18-fixes
> > > branch checkout? The 0-18-fixes branch compiles just fine on FC4 w/the
> > > latest GCC 4.0.x (as well as GCC 4.1 in the Fedora Development tree).
> >
> > It should be the 0-18-fixes branch as I went here when 0.18.1 wouldn't
> > compile on FC4 with gcc 4.x last time.
> >
> > To make absolutely sure, I've just checked out a clean copy of the
> > 0-18-fixes branch with "svn co
> > http://svn.mythtv.org/svn/branches/release-0-18-fixes/mythtv", used
> > "./configure  --enable-dvb
> > --dvb-path=/usr/src/kernels/2.6.14-1.1656_FC4-i686/include
> > --enable-lirc" as my configure string, and started a make (after a qmake
> > mythtv.pro of course).  Same problem again.  This worked absolutely fine
> > on FC4 last year.  I just checked my config.log, and the successful make
> > was in July last year.
> 
> Take a look at the output of './configure --help':
> 
>   --enable-dvb             enable DVB support (must supply header directory)
>   --dvb-path=HDRLOC        location of directory containing
>                            'linux/dvb/frontend.h', not the
>                            directory with frontend.h 
> [/usr/src/linux-2.6.14-1.1656_FC4/include]
> 
> Seems to indicate giving a path into the kernel source like that doesn't work, 
> as it somehow pulls in other kernel headers to the build that override glibc 
> headers. Dunno if you can make that include path more specific for dvb 
> components only, or if building w/an external dvb source tarball is best 
> (which is what the ATrpms packages do).
> 
> The second error, I'm not sure what's going on. I thought I'd fixed all of 
> those problems in the 0.18 branch. One sec while I try a build... Yup, just 
> built fine. Could be a difference caused by your using the latest dvb source 
> versus my using the older dvb snap Axel is currently using in the ATrpms 
> packages, seeing as how scanwizard is dvb-specific. I dunno though.
> 

Its clear that it's pulling in kernel headers instead of glibc headers -
and looking at the sequence of includes, I'm guessing that it must
always have done this - and its just now (perhaps with a recent gcc
update) that g++ is complaining about it.

As a test, I built a brand new FC4 system in a vmware machine, updated
it, checked out the 0.18-fixes branch, and tried compiling.  Failed.
Perhaps what I should do is try it before updating...  Maybe tomorrow.

If this is true - then it means that any FC4 with the latest updates
will not be able to compile 0.18 if they point to the delivered kernel
dvb headers.  The configure script indicates that this is ok for kernels
> 2.6.11 (or something like that).  This may no longer be true. Is it
possible for the --dvb-path to be a bit more specific (like looking for
the directory with 'dvb/frontend.h' in it instead of
'linux/dvb/frontend.h')?

As for the 2nd error, I'm putting your theory to the test.  I'm
currently running a make, and --dvb-path is set to a copy of the
existing dvb headers somewhere else...  Yep - it worked.  So the latest
dvb code causes that error...

Anyway - its all a bit academic now as Axel pointed out quite rightly
that his build is based on 0.18.1, so I don't really need to be
compiling anyway.  I'll still try the un-updated FC4 though as a test.