stubdom/libxc-x86_64 compile error with valgrind installed

stubdom/libxc-x86_64 compile error with valgrind installed

[Simon Martin]

Hello all,

I  am building on Debian Wheezy and I have valgrind installed. About a
month ago I started having compilation problems. I assume it must have
something to do with Andrew's valgrind patch of June 10th.

The problem seems to lie in the fact that valgrind is in /usr/include,
however -nostdinc is specified on the compilation so we don't get it.

I  removed  -nostdinc from stubdom/Makefile and it compiled correctly.
Reading  the  gcc documentation this *should* be safe, as it will only
search   the   default   directories   *after*  the  explicit  include
directories. That being said, there is probably a better fix for this.

Regards.

-- 
Best regards,
 Simon                          mailto:furryfuttock@gmail.com

Re: stubdom/libxc-x86_64 compile error with valgrind installed

[Ian Campbell]

On Mon, 2014-07-21 at 11:00 +0100, Simon Martin wrote:
> Hello all,
> 
> I  am building on Debian Wheezy and I have valgrind installed. About a
> month ago I started having compilation problems. I assume it must have
> something to do with Andrew's valgrind patch of June 10th.
> 
> The problem seems to lie in the fact that valgrind is in /usr/include,
> however -nostdinc is specified on the compilation so we don't get it.
> 
> I  removed  -nostdinc from stubdom/Makefile and it compiled correctly.
> Reading  the  gcc documentation this *should* be safe, as it will only
> search   the   default   directories   *after*  the  explicit  include
> directories. That being said, there is probably a better fix for this.

The best fix would be to teach tools/configure.ac about stubdom builds
somehow and pass the appropriate options when configuring.

The quick fix is probably to tools/libxc/xc_private.h:
-#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG)
+#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG) && !defined(__MINIOS__)

Does that work for you?

Ian.

Re: stubdom/libxc-x86_64 compile error with valgrind installed

[Simon Martin]

Hello Ian,

> The quick fix is probably to tools/libxc/xc_private.h:
> -#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG)
> +#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG) && !defined(__MINIOS__)

> Does that work for you?

Works here. Thanks.

-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com

Re: stubdom/libxc-x86_64 compile error with valgrind installed

[Andrew Cooper]

On 21/07/14 11:00, Simon Martin wrote:
> Hello all,
>
> I  am building on Debian Wheezy and I have valgrind installed. About a
> month ago I started having compilation problems. I assume it must have
> something to do with Andrew's valgrind patch of June 10th.
>
> The problem seems to lie in the fact that valgrind is in /usr/include,
> however -nostdinc is specified on the compilation so we don't get it.
>
> I  removed  -nostdinc from stubdom/Makefile and it compiled correctly.
> Reading  the  gcc documentation this *should* be safe, as it will only
> search   the   default   directories   *after*  the  explicit  include
> directories. That being said, there is probably a better fix for this.
>
> Regards.
>

The problem is that stubdoms are blindly using the regular environment
config.h without reconfiguring libxc for their reduced environment.

As a result, config.h is correctly stating that memcheck.h exists in the
regular environment, even when it is included into the reduced stubdom
environment.


While removing -nostdinc does fix your problem, it is not the correct
fix.  memcheck.h is safe to use in this instance, but most header files
you find in /usr/include are not.

I am not sure what is the correct solution here is.  Introducing an
explicit --{en,dis}able-valgrind to the main ./configure will still
break for anyone who chooses to enable it.  I suspect a fix involves
someone draining the swamp which is the stubdom build system.

~Andrew

Re: stubdom/libxc-x86_64 compile error with valgrind installed

[Ian Campbell]

On Mon, 2014-07-21 at 11:19 +0100, Andrew Cooper wrote:
> I am not sure what is the correct solution here is.  Introducing an
> explicit --{en,dis}able-valgrind to the main ./configure will still
> break for anyone who chooses to enable it.

I proposed a bodge which I think would be acceptable (assuming it works)

>   I suspect a fix involves
> someone draining the swamp which is the stubdom build system.

I'm hopeful that the rump kernel work will at least reduce it to a
manageable mire...

Ian.

Re: stubdom/libxc-x86_64 compile error with valgrind installed

[Andrew Cooper]

On 21/07/14 11:33, Ian Campbell wrote:
> On Mon, 2014-07-21 at 11:19 +0100, Andrew Cooper wrote:
>> I am not sure what is the correct solution here is.  Introducing an
>> explicit --{en,dis}able-valgrind to the main ./configure will still
>> break for anyone who chooses to enable it.
> I proposed a bodge which I think would be acceptable (assuming it works)

I saw.  It most certainly is a bodge, but is probably the best short
term course of action.

Doesn't it need an extra check for the rump stuff?

>
>>   I suspect a fix involves
>> someone draining the swamp which is the stubdom build system.
> I'm hopeful that the rump kernel work will at least reduce it to a
> manageable mire...
>
> Ian.
>

Lets hope!

~Andrew

Re: stubdom/libxc-x86_64 compile error with valgrind installed

[Ian Campbell]

On Mon, 2014-07-21 at 11:40 +0100, Andrew Cooper wrote:
> On 21/07/14 11:33, Ian Campbell wrote:
> > On Mon, 2014-07-21 at 11:19 +0100, Andrew Cooper wrote:
> >> I am not sure what is the correct solution here is.  Introducing an
> >> explicit --{en,dis}able-valgrind to the main ./configure will still
> >> break for anyone who chooses to enable it.
> > I proposed a bodge which I think would be acceptable (assuming it works)
> 
> I saw.  It most certainly is a bodge, but is probably the best short
> term course of action.
> 
> Doesn't it need an extra check for the rump stuff?

I don't know...

Ian, the proposal is tools/libxc/xc_private.h:
-#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG)
+#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG) && !defined(__MINIOS__)

Ian.

Re: stubdom/libxc-x86_64 compile error with valgrind installed

[Andrew Cooper]

On 21/07/14 11:47, Ian Campbell wrote:
> On Mon, 2014-07-21 at 11:40 +0100, Andrew Cooper wrote:
>> On 21/07/14 11:33, Ian Campbell wrote:
>>> On Mon, 2014-07-21 at 11:19 +0100, Andrew Cooper wrote:
>>>> I am not sure what is the correct solution here is.  Introducing an
>>>> explicit --{en,dis}able-valgrind to the main ./configure will still
>>>> break for anyone who chooses to enable it.
>>> I proposed a bodge which I think would be acceptable (assuming it works)
>> I saw.  It most certainly is a bodge, but is probably the best short
>> term course of action.
>>
>> Doesn't it need an extra check for the rump stuff?
> I don't know...
>
> Ian, the proposal is tools/libxc/xc_private.h:
> -#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG)
> +#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG) && !defined(__MINIOS__)
>
> Ian.
>

Nor do I, but IanJ's series changed most (all?) the #if
!defined(__MINIOS__) into #if !defined(__MINIOS__) ||
!defined(__RUMPUSER_XEN__)

Therefore, I suspect the same is needed here.

~Andrew

Re: stubdom/libxc-x86_64 compile error with valgrind installed

[Ian Campbell]

On Mon, 2014-07-21 at 11:56 +0100, Andrew Cooper wrote:
> On 21/07/14 11:47, Ian Campbell wrote:
> > On Mon, 2014-07-21 at 11:40 +0100, Andrew Cooper wrote:
> >> On 21/07/14 11:33, Ian Campbell wrote:
> >>> On Mon, 2014-07-21 at 11:19 +0100, Andrew Cooper wrote:
> >>>> I am not sure what is the correct solution here is.  Introducing an
> >>>> explicit --{en,dis}able-valgrind to the main ./configure will still
> >>>> break for anyone who chooses to enable it.
> >>> I proposed a bodge which I think would be acceptable (assuming it works)
> >> I saw.  It most certainly is a bodge, but is probably the best short
> >> term course of action.
> >>
> >> Doesn't it need an extra check for the rump stuff?
> > I don't know...
> >
> > Ian, the proposal is tools/libxc/xc_private.h:
> > -#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG)
> > +#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG) && !defined(__MINIOS__)
> >
> > Ian.
> >
> 
> Nor do I, but IanJ's series changed most (all?) the #if
> !defined(__MINIOS__) into #if !defined(__MINIOS__) ||
> !defined(__RUMPUSER_XEN__)
> 
> Therefore, I suspect the same is needed here.

&& rather than || in this case though I think?

Ian.

Re: stubdom/libxc-x86_64 compile error with valgrind installed

[Ian Campbell]

On Mon, 2014-07-21 at 12:06 +0100, Ian Campbell wrote:
> On Mon, 2014-07-21 at 11:56 +0100, Andrew Cooper wrote:
> > On 21/07/14 11:47, Ian Campbell wrote:
> > > On Mon, 2014-07-21 at 11:40 +0100, Andrew Cooper wrote:
> > >> On 21/07/14 11:33, Ian Campbell wrote:
> > >>> On Mon, 2014-07-21 at 11:19 +0100, Andrew Cooper wrote:
> > >>>> I am not sure what is the correct solution here is.  Introducing an
> > >>>> explicit --{en,dis}able-valgrind to the main ./configure will still
> > >>>> break for anyone who chooses to enable it.
> > >>> I proposed a bodge which I think would be acceptable (assuming it works)
> > >> I saw.  It most certainly is a bodge, but is probably the best short
> > >> term course of action.
> > >>
> > >> Doesn't it need an extra check for the rump stuff?
> > > I don't know...
> > >
> > > Ian, the proposal is tools/libxc/xc_private.h:
> > > -#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG)
> > > +#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG) && !defined(__MINIOS__)
> > >
> > > Ian.
> > >
> > 
> > Nor do I, but IanJ's series changed most (all?) the #if
> > !defined(__MINIOS__) into #if !defined(__MINIOS__) ||
> > !defined(__RUMPUSER_XEN__)
> > 
> > Therefore, I suspect the same is needed here.
> 
> && rather than || in this case though I think?

That said -- I'd have hoped that the rumpkernel changes would have
resulted in !HAVE_VALGRIND_MEMCHECK_H, so maybe not?


Ian.

Re: stubdom/libxc-x86_64 compile error with valgrind installed

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] stubdom/libxc-x86_64 compile error with valgrind installed"):
> On 21/07/14 11:47, Ian Campbell wrote:
> > On Mon, 2014-07-21 at 11:40 +0100, Andrew Cooper wrote:
> >> Doesn't it need an extra check for the rump stuff?
> > I don't know...
> >
> > Ian, the proposal is tools/libxc/xc_private.h:
> > -#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG)
> > +#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG) && !defined(__MINIOS__)
...
> Nor do I, but IanJ's series changed most (all?) the #if
> !defined(__MINIOS__) into #if !defined(__MINIOS__) ||
> !defined(__RUMPUSER_XEN__)
> 
> Therefore, I suspect the same is needed here.

No, this bodge isn't needed for __RUMPUSER_XEN__.  The rump kernel
build runs configure with the rump kernel build system which doesn't
see the system's valgrind.h.  I.e., the rump kernel build environment
used for building tools/libxc/ doesn't have the bug that the stubdom
build system has.

There are some __RUMPUSER_XEN__ in libxc but they are just for
selecting the right implementations of various components - in
particular, to make hypercalls directly but use the devices in /dev/
for xenstore and evtchn.  (And for disabling dynamic loading.)

Ian.