Re: Bug#674260: RM: aspectc++ [kfreebsd-i386 kfreebsd-amd64] -- ROM; FTBFS on kfreebsd

[Guillem Jover <guillem@debian.org>]

On Thu, 2012-05-24 at 08:12:50 +0200, Reinhard Tartler wrote:
> Package: ftp.debian.org
> Severity: normal

> The package aspectc++ does not build on kfreebsd since April now. The
> reason for this is, as I suspect, a bug or insufficienty in the fnctl()
> implementation on kfreebsd. In order to speed up compilation (ac++ is
> dead slow), the compilation is run in parallel where possible. However,
> each compilation step needs to store information about the found join
> points and woven advice instantiation in project wide "aspect
> repository", which needs to be guarded against concurrent updates from
> ac++ processes. And this locking now seems to fail fatally since
> upstream release 1.1.
> 
> Before 1.1, AFAIUI locking didn't work either, and you ended up with a
> corrupt aspect repository -- rending the package pretty much useless
> IMO, but YMMV.
> 
> This has been documented as #633402, and porters have already been asked
> for help. Unfortunately, no solution could be found. Therefore, I have
> to ask for an architecture specific removal in order to allow the
> package to migrate to testing.

I've just quickly checked the aspectc++ source code and found out the
problem is in there, and as such this removal request is not warranted.
All struct flock initializers in (at least) Puma/src/basics/SysCall.cc
are bogus, as it assumes the layout of the struct flock whose members
are explicitly defined as not having a specific order. The code should
switch to use named initializers or simple member assignments [0]. I've
not checked or tested if there's other portability issues though.

[0]

  struct flock fl = { .l_type = A, .l_whence = B, ... };

or

  struct flock fl;

  fl.l_type = A;
  fl.l_whence = B;
  ...


thanks,
guillem