Re: [FFADO-user] build failure: support/dbus/controlserver.cpp versus /usr/include/dbus-c++-1/dbus-c++/interface.h

[Jonathan W. <jw...@ju...>]

On Tue, Aug 27, 2013 at 09:20:29AM +0200, Stefan Richter wrote:
> On Aug 27 Jonathan Woithe wrote:
> > support/dbus/controlserver-glue.h is a file which
> > is generated by dbusxx-xml2cpp, so it might be sufficient to simply upgrade
> > this to suit the newer compiler.
> 
> I will have a look for a newer one.
> 
> > I can't remember where this comes from (it
> > might be supplied by dbus-c++ - again, I'd have to check my notes).
> 
> It is provided by the dbus-c++-0.9.0 package here.

Yes, that appears to be where it comes from.

> > One question: has your gcc been updated since your last successful ffado
> > compile in January?  This would at least provide a definitive reason for the
> > breakage on your system.
> 
> Not sure.  Given the timestamps of the installed FFADO files and the
> changelog of Gentoo's gcc, I might have had gcc 4.6.3 then and now, or I
> might have had 4.5.4 then (and 4.6.3 now).

For what it's worth, I'm on 4.7.1 right now.

> I updated to the latest dbus-c++ package from Gentoo...
> 
>   *dbus-c++-0.9.0-r1 (10 Sep 2012)
> 
>     10 Sep 2012; Mike Frysinger <va...@ge...>
>     +dbus-c++-0.9.0-r1.ebuild, +files/dbus-c++-0.9.0-gcc-4.7.patch,
>     metadata.xml: Add fix from ChromiumOS for building with gcc-4.7 #424707
>     by Diego Elio Pettenò.
> 
> ...but the problem persists.  The -r1 package merely adds an "#include
> <unistd.h>" to one of the dbus-c++ source files.

I don't think there has been an official release later than 0.9.0.

I've checked my logs and it seems that this was the one issue I had
following an upgrade which I did not make notes about.  Bother.  My notes
indicate that I updated dbus-c++ from git, but this was to see if the newer
version fixed "set but not used" warnings in the generated code (it didn't).
For what it's worth, the git version (as of 9 July) lacked the unistd.h
include.

Have you tried removing the generated files (controlclient-glue.h and 
controlserver-glue.h) from support/dbus/ to force their recreation using the
tools currently on your system?

> Furthermore, I did a git pull in a clone of
> git://gitorious.org/dbus-cplusplus/mainline.git which I had on disk from
> before Gentoo got a dbus-c++-0.9.0 package, but its master ends at tag
> "release-0.9.0".  Is there another, more recent repo anywhere?

Not that I'm aware of.

> mainline.it at gitorios has got three open merge requests, which I haven't
> yet looked closer at.

I don't have them applied so I suspect they're not needed.

> A pro pos generated files:
>   $ scons -c
>   [...]
>   $ svn status $(find .)
>   I       .sconsign.dblite
>   I       admin/pyuic4.pyc
>   I       admin/pyuic.pyc
>   I       admin/dbus.pyc
>   I       admin/doxygen.pyc
>   I       admin/scanreplace.pyc
>   I       admin/pkgconfig.pyc
>   I       cache
>   svn: warning: W155007: 'cache/conftest_0.o' is not a working copy
>   [...]
>   svn: warning: W155007: 'cache/conftest_8.c' is not a working copy
> 
> Shouldn't the .pyc files be cleaned out by scons -c?

I don't know to be honest.  I guess it depends on precisely how they are
created.  A quick grep of the toplevel SConstruct file failed to find the
.pyc files mentioned therein, and admin/ doesn't have its own SConstruct
file.  Therefore I suspect that these are created by something in response
to something that scons does rather than being managed by scons.  That would
be a possible reason why "scons -c" doesn't clean them.

> Is there an svn command to reset al versioned files and remove all
> unversioned files, like "git reset --hard"?

I'm only vaguely familiar with git myself.  I suspect you could build up the
command using 

  svn status --no-ignore 

as a starting point.  I *think* that files with status ? or I are the ones
to remove; some grep/sed and xargs work would then give a working solution.
Maybe something like this:

  svn status --no-ignore | grep '^[?I]' | sed 's/^[?I]       //' \
    xargs -Ixx rm -rf xx

Note the above is completely untested by me.

Regards
  jonathan