Aurelien Jarno a écrit : > Aurelien Jarno a écrit : >> Falk Hueffner a écrit : >>> Hi, >> Hi, >> >>> I'd be willing to take a look if there is a small testcase (i.e. a >>> single C file which when compiled and run will either succeed or >>> fail). Anybody willing to create such a testcase? >>> >> I have started to work on that, but unfortunately I haven't found time >> to get very far, all that I know is that it happens when calling >> db_open(), but the problem is actually in the glibc code. >> > > I have made some progress, I have reduced the testcase to a simple C > code, but that still uses glibc functions: > > #include <stdio.h> > #include <unistd.h> > #include <sys/types.h> > #include <sys/stat.h> > #include <fcntl.h> > > > int main() { > int fd; > int ret; > > fd = open("test.txt", O_CREAT); > ret = fdatasync(fd); > printf("ret: %i\n",ret); > close(fd); > > return 0; > } > > fdatasync() behaves differently on a glibc built with gcc 4.2.1-5 and > with gcc 4.2.2-3. >
I have finally found the problem. It is actually not a gcc bug. There is one more difference between the two builds that I haven't seen before, linux-libc-dev is available in different versions. And the newer version has in /usr/include/asm/unistd.h: #define __NR_fdatasync 447 The problem therefore lies in the glibc, we should define a fallback when the syscall is not available. I am therefore closing this bug, leaving the one opened on the glibc opened. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]