CAI Qian wrote: > From: Gui Xiaohua <[email protected]> > Subject: Re: [LTP] [PATCH]the function name conflict with libc in LTP > Date: Mon, 11 May 2009 13:21:33 +0800 > >> The accept4 will available in glbic v2.10 >> # man accept4 >> ... >> The accept4() system call is available starting with Linux 2.6.28; support >> in glibc is available starting with version 2.10. >> ... >> In v2.9, the function was be declared. So i do some changes like folw: > > Interesting, it was declared there. It looks like you might use a > pre-released version?
Yes, because we do test on Fedora11Beta, and the glibc with version 2.9.90 was released with Fedora11Beta. > > glibc-headers-2.9.90-8.1.x86_64 > >> Signed-off-by: Gui Xiaohua <[email protected]> >> --- a/kernel/syscalls/accept4/accept4_01.c 2009-05-05 16:58:49.000000000 >> +0800 >> +++ b/kernel/syscalls/accept4/accept4_01.c 2009-05-11 12:05:45.000000000 >> +0800 >> @@ -141,9 +141,9 @@ void setup() >> TEST_PAUSE; >> tst_tmpdir(); >> } >> - >> +#if !(__GLIBC_PREREQ(2,10)) > > The cleaner approach is use autoconf to detect those situations outlined > by Masatake YAMATO, > > "The step to use autoconf in your test case: > > 0. update ltp (via cvs or git); the install autoconf > 2.61 > > 1. Added ltp-SYSTEMCALLNAME.m4 to m4 directory. > e.g. pseudo code(ltp-unshare.m4) > > AC_DEFUN([LTP_CHECK_SYSCALL_UNSHARE],[ > AC_CHECK_FUNCS(unshare) > ]) > > 2. Added the macro name to configure.ac like > > m4_include([m4/ltp-unshare.m4]) > LTP_CHECK_SYSCALL_UNSHARE > > 3. make autoconf > > 4. modify your test case. > 4.1 include config.h (see signalfd01.c) > 4.2 > > #if defined HAVE_UNSHARED > ...code for test case... > #else > ...stub reports "this environment doesn't support unshare syscall"... > #endif > > 5. ./configure > > 6. cd lib;make;cd .. > 7 cd testcases/kernel/syscall/unshare; make > > 8. Read include config.h and search HAVE_UNSHARED > You can see the result of configure. > if HAVE_UNSHARED is defined your platform may have the systemcall." > > Also, we can then remove the kernel part of the checking here, > > int > main(int argc, char *argv[]) > { > #if defined(__NR_accept4) || defined(__NR_socketcall) > >> static int >> -accept4(int fd, struct sockaddr *sockaddr, socklen_t *addrlen, int flags) >> +accept4_01(int fd, struct sockaddr *sockaddr, socklen_t *addrlen, int flags) >> { >> #ifdef DEBUG >> tst_resm(TINFO, "Calling accept4(): flags = %x", flags); >> @@ -173,6 +173,7 @@ accept4(int fd, struct sockaddr *sockadd >> return syscall(__NR_accept4, fd, sockaddr, addrlen, flags); >> #endif >> } >> +#endif >> >> /**********************************************************************/ >> >> @@ -197,8 +198,13 @@ do_test(int lfd, struct sockaddr_in *con >> die("Connect Error"); >> >> addrlen = sizeof(struct sockaddr_in); >> + #if !(__GLIBC_PREREQ(2,10)) >> + acceptfd = accept4_01(lfd, (struct sockaddr *)&claddr, &addrlen, >> + closeonexec_flag | nonblock_flag); >> + #else >> acceptfd = accept4(lfd, (struct sockaddr *)&claddr, &addrlen, >> closeonexec_flag | nonblock_flag); >> + #endif >> if (acceptfd == -1) { >> tst_resm(TCONF, >> "syscall __NR_accept4 not supported on your arch"); >> > > I don't have a system to test this right now, but it looks OK for me, > > Acked-by: CAI Qian <[email protected]> > >> CAI Qian wrote: >> >>>> From: Gui Xiaohua <[email protected]> >>>> Subject: [LTP] [PATCH]the function name conflict with libc in LTP >>>> To: [email protected] >>>> Date: Wednesday, May 6, 2009, 1:16 PM >>>> There is an error occured during i >>>> compiled ltp which was >>>> released in 20090430: >>>> accept4_01.c:146: error: static declaration of >>>> ‘accept4’ >>>> follows non-static declaration >>>> /usr/include/sys/socket.h:222: >>>> note: previous declaration of ‘accept4’ was >>>> here. >>>> Note: >>>> The OS is Fedora11Beta, the glibc version is >>>> glibc-headers-2.9.90-8.1.x86_64. >>>> >>> Well, if glibc has already provided accept4(), we can use it unless it is >>> really necessary to use syscall(). In the future, we probably don't want >>> to maintain a separate version of accept4() here. Is it possible to check >>> if the glibc version is available? If so, use the glibc one. Otherwise, >>> use the static one here? >>> >>> CAI Qian >>> >> ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
