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? 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
