Hi Yamato,
On Fri, 2008-08-22 at 21:25 +0900, Masatake YAMATO wrote:
> Hi,
>
> > Hi Rishi/Serge,
> >
> > libclone.c is giving some unexpected build error(s) on the following
> > x86_64 machine. Can you please look in to the following:
> >
> > 1) Linux 2.6.16-1.2080_FC5 #1 SMP Tue Mar 28 03:38:47 EST 2006 x86_64
> > x86_64 x86_64 GNU/Linux,
> >
> > make[4]: Entering directory
> > `/root/subrata/ltp/ltp-intermediate-20080820/testcases/kernel/containers/libclone'
> > cc -Wall -c -o libclone.o libclone.c
> > libclone.c: In function ‘do_unshare_tests’:
> > libclone.c:76: error: ‘__NR_unshare’ undeclared (first use in this
> > function)
> > libclone.c:76: error: (Each undeclared identifier is reported only once
> > libclone.c:76: error: for each function it appears in.)
> > make[4]: *** [libclone.o] Error 1
> >
> > Regards--
> > Subrata
> >
>
> I met similar situations when writing test cases.
>
> In fadvice64 I handled it like in .c file:
>
> /* Check this system has fadvise64 system which is used
> in posix_fadvise. */
> if ((_FILE_OFFSET_BITS != 64) && (__NR_fadvise64 == 0)) {
> tst_resm(TWARN, "This test can only run on kernels that
> implements ");
> tst_resm(TWARN, "fadvise64 which is used from posix_fadvise");
> exit(0);
> }
>
> In io_setup I did in Makefile:
>
> check_header = $(shell \
> if echo "\#include <$(1)>" | $(CC) -E - > /dev/null 2>&1 ; \
> then echo yes ; \
> else echo no ; fi)
>
> ifeq ($(call check_header,libaio.h),yes)
>
>
> Is there any standard rule to handle such situation?
> Generally autoconf helps. However, ltp people may
> want to handle it runtime, not buildtime.
>
>
> What we have to consider are:
>
> (1) kernel version
> (1.1) kernel configuration
> (1.2) system call existence
> (2) hardware platform
> (3) library dependency
> (4) header file dependency
>
Yes, we need to consider all these. I would prefer these things to be
handled inside the source code itself, rather than handling them from
Makefile, which otherwise makes the Makefile(s) look dirty. So, the
handling from test source code should also be able to tell the exact
reason amongst mentioned above.
If handled inside code, then the Makefile(s) will be spared from
thinking what/how things should be built, instead the code inside wiull
do this. And when the binary gets compiled, let it have the test code or
exception code.
Regards--
Subrata
> If the standard rule is given, let's add
> code snippets which make people easier to
> follow the rule to LTP.
>
>
> How do you think?
>
> Masatake YAMATO
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
