[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FTBS of ardour



Hi Felipe,
* Felipe Sateler <fsateler@gmail.com> [2007-10-23 17:06]:
> On 10/23/07, Nico Golde <nion@debian.org> wrote:
[...] 
> > > I've been looking into this. The pkg-config issue is trivial, a pkg-config
> > > build-dep was missing.
> >
> > Are you sure about this? I don't really think so I think
> > this is a scons issue, if you look at the build log failing
> > because of pkg-config you can see another place where
> > pkg-config is there in the same build
> 
> Ah, this is true. I failed to see that pkg-config was brought in by
> some dependency earlier, and that the failure was when cleaning. I
> know what the problem is, but unfortunately there is nothing we can
> do, please see scons bug 444204. In short, the problem is that the
> current snapshot in unstable doesn't actually execute configuration
> directives when called with -c (clean) or -h (help). This has the side
> effect that all configure calls return false, which makes cleaning and
> asking for help break. This is apparently fixed in upstream svn, but
> hasn't got here yet.
> I wasn't able to reproduce the problem here since I have scons on hold
> for exactly this reason (I do feel somewhat embarrased for not seeing
> this before, though).

Updating to the latest Scons build file in ardour svn should 
solve this, they added some uninstall rule referring to 
upstream.

> > > I'm having a problem with the abs issue, though: I
> > > can't understand why it is there, and it doesn't appear here on i386.
> >
> > From what I see the problem is that it does not know to
> > which type the value should be converted, there is no
> > variant for nframes64_t or int64_t and int64_t is assignment
> > compatible with float and int for example.
> > So typecasting should solve this.
> 
> The strange thing is that this should happen in other 32-bit
> architectures too, since the int64_t is defined as a long long int,
> which has no abs implementation in the std:: namespace. Anyways, my
> patch moved the casting from double to int64_t to after the abs is
> done, which should resolve the ambiguity (double std::abs(double) is
> present in the C++ standard).

Yes this should be ok.
Kind regards
Nico
-- 
Nico Golde - http://www.ngolde.de - nion@jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.

Attachment: pgpAMXkv1Ib7h.pgp
Description: PGP signature


Reply to: