|
From: Roman K. <co...@rk...> - 2018-04-22 16:29:32
|
Fixes: a10216bdde433fd ("Add inner requests in VEX")
---
Makefile.vex.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile.vex.am b/Makefile.vex.am
index 64f837352..eb91d25f0 100644
--- a/Makefile.vex.am
+++ b/Makefile.vex.am
@@ -28,7 +28,8 @@ pkginclude_HEADERS = \
pub/libvex_guest_mips64.h \
pub/libvex_s390x_common.h \
pub/libvex_ir.h \
- pub/libvex_trc_values.h
+ pub/libvex_trc_values.h \
+ pub/libvex_inner.h
noinst_HEADERS = \
priv/main_globals.h \
--
2.17.0
|
|
From: Philippe W. <phi...@sk...> - 2018-04-22 19:15:16
|
Thanks for the below patch.
libvex_inner.h is effectively listed nowhere in Makefile.vex.am
I am however wondering why add this in pkginclude_HEADERS
while pub_core_inner.h is in noinst_HEADERS ?
What is the problem you have encountered when not
having pub/libvex_inner.h in the pkginclude_HEADERS ?
And would you still have a problem if this libvex_inner.h
would be in noinst_HEADERS ?
Philippe
On Sun, 2018-04-22 at 18:08 +0200, Roman Kapl wrote:
> Fixes: a10216bdde433fd ("Add inner requests in VEX")
> ---
> Makefile.vex.am | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile.vex.am b/Makefile.vex.am
> index 64f837352..eb91d25f0 100644
> --- a/Makefile.vex.am
> +++ b/Makefile.vex.am
> @@ -28,7 +28,8 @@ pkginclude_HEADERS = \
> pub/libvex_guest_mips64.h \
> pub/libvex_s390x_common.h \
> pub/libvex_ir.h \
> - pub/libvex_trc_values.h
> + pub/libvex_trc_values.h \
> + pub/libvex_inner.h
>
> noinst_HEADERS = \
> priv/main_globals.h \
|
|
From: Roman K. <co...@rk...> - 2018-04-22 20:09:58
|
On 04/22/2018 09:15 PM, Philippe Waroquiers wrote:
> Thanks for the below patch.
> libvex_inner.h is effectively listed nowhere in Makefile.vex.am
>
> I am however wondering why add this in pkginclude_HEADERS
> while pub_core_inner.h is in noinst_HEADERS ?
Hmm... I don't exactly understand the priv/pub/noinst/inst organization
and their subtleties. Shouldn't the pub_core_inner be made a tool public
header instead?
If not, is Valgrind supposed to use a private header from libvex?
>
> What is the problem you have encountered when not
> having pub/libvex_inner.h in the pkginclude_HEADERS ?
Building from the `make dist` package fails, because of this missing header.
> And would you still have a problem if this libvex_inner.h
> would be in noinst_HEADERS ?
No, both lists work ok.
>
> Philippe
>
>
> On Sun, 2018-04-22 at 18:08 +0200, Roman Kapl wrote:
>> Fixes: a10216bdde433fd ("Add inner requests in VEX")
>> ---
>> Makefile.vex.am | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/Makefile.vex.am b/Makefile.vex.am
>> index 64f837352..eb91d25f0 100644
>> --- a/Makefile.vex.am
>> +++ b/Makefile.vex.am
>> @@ -28,7 +28,8 @@ pkginclude_HEADERS = \
>> pub/libvex_guest_mips64.h \
>> pub/libvex_s390x_common.h \
>> pub/libvex_ir.h \
>> - pub/libvex_trc_values.h
>> + pub/libvex_trc_values.h \
>> + pub/libvex_inner.h
>>
>> noinst_HEADERS = \
>> priv/main_globals.h \
Thanks, Roman Kapl
|
|
From: Philippe W. <phi...@sk...> - 2018-04-22 20:53:43
|
On Sun, 2018-04-22 at 22:09 +0200, Roman Kapl wrote: > On 04/22/2018 09:15 PM, Philippe Waroquiers wrote: > > Thanks for the below patch. > > libvex_inner.h is effectively listed nowhere in Makefile.vex.am > > > > I am however wondering why add this in pkginclude_HEADERS > > while pub_core_inner.h is in noinst_HEADERS ? > > Hmm... I don't exactly understand the priv/pub/noinst/inst organization > and their subtleties. Shouldn't the pub_core_inner be made a tool public > header instead? > > If not, is Valgrind supposed to use a private header from libvex? > > > > What is the problem you have encountered when not > > having pub/libvex_inner.h in the pkginclude_HEADERS ? > > Building from the `make dist` package fails, because of this missing header. > > And would you still have a problem if this libvex_inner.h > > would be in noinst_HEADERS ? > > No, both lists work ok. Funny, on my side, I had to add it in pkginclude_HEADERS to have it working. So, I have pushed your patch as 3045007dcdf4ea656bc7ba888e6bcc42b15f0333 Thanks for reporting the problem and the provided patch. Philippe |