Re: [LTP] cap_bset_inh_bounds.c build failure

[Garrett Cooper <yanegomi@gm...>]

On Wed, Apr 7, 2010 at 6:39 AM, Serge E. Hallyn <serue@...> wrote:
> Quoting Mitani (mitani@...):
>> Hi,

[...]

> Agreed, since this is LTP it's not right to expect "sane"
> userspace-kernel combos.  So we need to check both.  Unfortunately
> I won't have time to work with that this week.
>
> Even if I did, I'd have a guidance question for Garrett:  Do we
> want to assume that people will change kernels, but not libraries,
> between compile/install and run of ltp?  If so, then we can stick
> with the autoconf checks for libraries+includes, and add a check
> at runtime (as I believe was there originally) for the requisite
> kernel support - file capabilities, bounding sets, and 64-bit
> capabilities.

Assuming that kernels remain constant between compile and install
would be a nice thing to shoot for, but I personally on an embedded
project [for instance] have compiled LTP once, not had the major libs
change, but the kernel potentially changed, and then dropped in ltp
and voila.. it worked perfectly fine. With that in mind, yes..
breaking that assumption would be painful, as many packagers actually
compile and distribute one version of ltp as a package (debian for
instance is one said example).

> OTOH if you're ok with assuming kernel is same at ltp configure
> and run, then we can do a test in autoconf which makes for a cleaner
> run.

Yes, it's fine to have runtime tests. The point that I've tried to
make in the past (and partially failed) is that the following needs to
be kept in mind:

1. Groups can backport patches from kernel versions; thus using kernel
version checks to determine whether or not functionality A exists is
dubious. It's better just to compile the functionality in such a way
that the test works and let the group executing the test do so without
hacking the test.
2. Compiling at runtime is no bueno for almost everything in the
source tree. There are a handful of tests in the source tree that do
do that, but by and large this is a bad idea as we aren't guaranteed
to have a full compile toolchain on the running system -- only the
build system.

Thanks,
-Garrett

Re: [LTP] cap_bset_inh_bounds.c build failure

[Serge E. Hallyn <serue@us...>]

Quoting Mitani (mitani@...):
> Hi,
> 
> > -----Original Message-----
> > From: Serge E. Hallyn [mailto:serue@...]
> > Sent: Monday, April 05, 2010 10:22 PM
> > To: Mitani
> > Cc: ltp-list@...
> > Subject: Re: [LTP] cap_bset_inh_bounds.c build failure
> > 
> > Quoting Mitani (mitani@...):
> > > Hi,
> > >
> > > I tried to build by using yesterday's git in my system (RHEL4.8 x86).
> > >  (ltp-dev-4837fee8a7c2de6a83c8927a574c792ca6dabe4e.tar.gz)
> > > But build failed in "cap_bset_inh_bounds.c" with following message.
> > > This is different from "cap_bounds_r.c"'s problem (another thread),
> > I think
> > >
> > > ------------
> > > gcc -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall
> > > -I/home/LTP/ltp-dev-20100401-3/testcases/kernel/include
> > > -I../../../../include -I../../../../include   -L../../../../lib
> > > cap_bset_inh_bounds.c   -lltp -lcap -o cap_bset_inh_bounds
> > > cap_bset_inh_bounds.c:124: error: syntax error before numeric
> > constant
> > > cap_bset_inh_bounds.c:124: warning: type defaults to `int' in
> > declaration of
> > > `tst_resm'
> > > cap_bset_inh_bounds.c:124: error: conflicting types for 'tst_resm'
> > > ../../../../include/test.h:192: error: previous declaration of
> > 'tst_resm'
> > > was here
> > > cap_bset_inh_bounds.c:124: error: conflicting types for 'tst_resm'
> > > ../../../../include/test.h:192: error: previous declaration of
> > 'tst_resm'
> > > was here
> > > cap_bset_inh_bounds.c:124: warning: data definition has no type or
> > storage
> > > class
> > > cap_bset_inh_bounds.c:129: warning: type defaults to `int' in
> > declaration of
> > > `tst_exit'
> > > cap_bset_inh_bounds.c:129: error: conflicting types for 'tst_exit'
> > > ../../../../include/test.h:203: error: previous declaration of
> > 'tst_exit'
> > > was here
> > > cap_bset_inh_bounds.c:129: error: conflicting types for 'tst_exit'
> > > ../../../../include/test.h:203: error: previous declaration of
> > 'tst_exit'
> > > was here
> > > cap_bset_inh_bounds.c:129: warning: data definition has no type or
> > storage
> > > class
> > > cap_bset_inh_bounds.c:130: error: syntax error before '}' token
> > > ------------
> > >
> > > In this source, the pair of "ifdef" start/end and the pair of
> > > main() function's "parenthesis" are alternate, I think.
> > >
> > >
> > > How about following patch?
> > >
> > > Signed-off-by : Tomonori Mitani <mitani@...>
> > 
> > Yup - although really the #ifdef HAVE_LIBCAP should be redundant as
> > the testcases/kernel/security/cap_bound/Makefile shouldn't compile
> > cap_bounds at all if HAVE_LIBCAP is not defined.
> > 
> 
> Yes. - In my system, this source is not problem. Your indication is 
> right. :-)
> But, I manually had updated "libcap2" once. And after "./configure", 
> HAVE_LIBCAP is defined. Therefore, I noticed this error.
> 
> The system which updated to "libcap2" will need solution of this 
> problem, I think.

Agreed, since this is LTP it's not right to expect "sane"
userspace-kernel combos.  So we need to check both.  Unfortunately
I won't have time to work with that this week.

Even if I did, I'd have a guidance question for Garrett:  Do we
want to assume that people will change kernels, but not libraries,
between compile/install and run of ltp?  If so, then we can stick
with the autoconf checks for libraries+includes, and add a check
at runtime (as I believe was there originally) for the requisite
kernel support - file capabilities, bounding sets, and 64-bit
capabilities.

OTOH if you're ok with assuming kernel is same at ltp configure
and run, then we can do a test in autoconf which makes for a cleaner
run.

thanks,
-serge

Re: [LTP] cap_bset_inh_bounds.c build failure

[Mitani <mitani@ry...>]

Hi,

> -----Original Message-----
> From: Serge E. Hallyn [mailto:serue@...]
> Sent: Monday, April 05, 2010 10:22 PM
> To: Mitani
> Cc: ltp-list@...
> Subject: Re: [LTP] cap_bset_inh_bounds.c build failure
> 
> Quoting Mitani (mitani@...):
> > Hi,
> >
> > I tried to build by using yesterday's git in my system (RHEL4.8 x86).
> >  (ltp-dev-4837fee8a7c2de6a83c8927a574c792ca6dabe4e.tar.gz)
> > But build failed in "cap_bset_inh_bounds.c" with following message.
> > This is different from "cap_bounds_r.c"'s problem (another thread),
> I think
> >
> > ------------
> > gcc -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall
> > -I/home/LTP/ltp-dev-20100401-3/testcases/kernel/include
> > -I../../../../include -I../../../../include   -L../../../../lib
> > cap_bset_inh_bounds.c   -lltp -lcap -o cap_bset_inh_bounds
> > cap_bset_inh_bounds.c:124: error: syntax error before numeric
> constant
> > cap_bset_inh_bounds.c:124: warning: type defaults to `int' in
> declaration of
> > `tst_resm'
> > cap_bset_inh_bounds.c:124: error: conflicting types for 'tst_resm'
> > ../../../../include/test.h:192: error: previous declaration of
> 'tst_resm'
> > was here
> > cap_bset_inh_bounds.c:124: error: conflicting types for 'tst_resm'
> > ../../../../include/test.h:192: error: previous declaration of
> 'tst_resm'
> > was here
> > cap_bset_inh_bounds.c:124: warning: data definition has no type or
> storage
> > class
> > cap_bset_inh_bounds.c:129: warning: type defaults to `int' in
> declaration of
> > `tst_exit'
> > cap_bset_inh_bounds.c:129: error: conflicting types for 'tst_exit'
> > ../../../../include/test.h:203: error: previous declaration of
> 'tst_exit'
> > was here
> > cap_bset_inh_bounds.c:129: error: conflicting types for 'tst_exit'
> > ../../../../include/test.h:203: error: previous declaration of
> 'tst_exit'
> > was here
> > cap_bset_inh_bounds.c:129: warning: data definition has no type or
> storage
> > class
> > cap_bset_inh_bounds.c:130: error: syntax error before '}' token
> > ------------
> >
> > In this source, the pair of "ifdef" start/end and the pair of
> > main() function's "parenthesis" are alternate, I think.
> >
> >
> > How about following patch?
> >
> > Signed-off-by : Tomonori Mitani <mitani@...>
> 
> Yup - although really the #ifdef HAVE_LIBCAP should be redundant as
> the testcases/kernel/security/cap_bound/Makefile shouldn't compile
> cap_bounds at all if HAVE_LIBCAP is not defined.
> 

Yes. - In my system, this source is not problem. Your indication is 
right. :-)
But, I manually had updated "libcap2" once. And after "./configure", 
HAVE_LIBCAP is defined. Therefore, I noticed this error.

The system which updated to "libcap2" will need solution of this 
problem, I think.


Thank you--

-Tomonori Mitani


> Acked-by: Serge Hallyn <serue@...>
> 
> 
> >
> Index: ./testcases/kernel/security/cap_bound/cap_bset_inh_bounds.c
> > ============
> > --- ./testcases/kernel/security/cap_bound/cap_bset_inh_bounds.c
> 2010-04-01
> > 16:15:00.000000000 +0900
> >
> +++ ./testcases/kernel/security/cap_bound/cap_bset_inh_bounds.c.ne
> w
> > 2010-04-01 17:27:23.000000000 +0900
> > @@ -39,11 +39,11 @@
> >
> >  int errno;
> >
> > +int main(int argc, char *argv[])
> > +{
> >  #if HAVE_SYS_CAPABILITY_H
> >  #if HAVE_DECL_PR_CAPBSET_READ && HAVE_DECL_PR_CAPBSET_DROP
> >  #ifdef HAVE_LIBCAP
> > -int main(int argc, char *argv[])
> > -{
> >         int ret = 1;
> >         cap_value_t v[1];
> >         cap_flag_value_t f;
> > ============
> >
> >
> > Thank you--
> >
> > -Tomonori Mitani
> >
> >
> >
> >
> ------------------------------------------------------------------
> ------------
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Ltp-list mailing list
> > Ltp-list@...
> > https://lists.sourceforge.net/lists/listinfo/ltp-list