Bug#431464: autoconf: files are rebuilt several times on vfat (because cp -p can't preserve time?)
On 2007-07-09 18:49:29 -0700, Ben Pfaff wrote: Vincent Lefevre [EMAIL PROTECTED] writes: I've now found the problem. This is unrelated to the use of cp -p. On my Zaurus, GCC and some of header files are in a directory mounted with CRAMFS. The timestamps of these files are meaningless, e.g. -rwxr-xr-x1 root root 808 Jul 9 14:30 exception* -rwxr-xr-x1 root root 3360 Jan 1 1970 float.h* Is this a bug in cramfs? You might well decide to bring this up on the linux-kernel mailing list to figure out what's going on. It is probably a bug in cramfs. It may have already been fixed as the Linux kernel version is quite old (this is SHARP's original ROM, and the only way to change it is to reflash it with an unofficial one). I don't think that this is a bug in Autoconf. Do you agree? If so, then I will close the bug. I agree concerning the problems I've reported. But concerning the cp -p, is the -p useful or just cosmetic? -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Bug#431464: autoconf: files are rebuilt several times on vfat (because cp -p can't preserve time?)
Hello Vincent, * Vincent Lefevre wrote on Tue, Jul 10, 2007 at 08:57:42AM CEST: I agree concerning the problems I've reported. But concerning the cp -p, is the -p useful or just cosmetic? It's useful, as it resembles the functionality it emulates more closely: with symlinked files, 'make' considers the time stamp of the linked-to file. Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431464: autoconf: files are rebuilt several times on vfat (because cp -p can't preserve time?)
On 2007-07-10 09:25:55 +0200, Ralf Wildenhues wrote: * Vincent Lefevre wrote on Tue, Jul 10, 2007 at 08:57:42AM CEST: I agree concerning the problems I've reported. But concerning the cp -p, is the -p useful or just cosmetic? It's useful, as it resembles the functionality it emulates more closely: with symlinked files, 'make' considers the time stamp of the linked-to file. But if this timestamp is important to preserve, then there may be problems on file systems where the timestamp cannot be preserved. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Bug#431464: autoconf: files are rebuilt several times on vfat (because cp -p can't preserve time?)
On 2007-07-07 14:17:51 -0700, Ben Pfaff wrote: Do you have a suggestion for how I might reproduce the problem on a desktop system? If I can reproduce it, I can probably debug it. I've now found the problem. This is unrelated to the use of cp -p. On my Zaurus, GCC and some of header files are in a directory mounted with CRAMFS. The timestamps of these files are meaningless, e.g. -rwxr-xr-x1 root root 808 Jul 9 14:30 exception* -rwxr-xr-x1 root root 3360 Jan 1 1970 float.h* -rwxr-xr-x1 root root 275 Jan 1 1970 iso646.h* -rwxr-xr-x1 root root 3264 Jul 9 13:42 limits.h* -rwxr-xr-x1 root root 1207 Jan 1 1970 new* -rwxr-xr-x1 root root 161 Jan 1 1970 new.h* -rwxr-xr-x1 root root 137 Jan 1 1970 proto.h* -rwxr-xr-x1 root root 495 Jan 1 1970 readme* -rwxr-xr-x1 root root 6038 Jul 9 13:41 stdarg.h* -rwxr-xr-x1 root root 502 Jan 1 1970 stdbool.h* -rwxr-xr-x1 root root 9834 Jul 9 13:40 stddef.h* -rwxr-xr-x1 root root 330 Jan 1 1970 syslimits.h* [...] As such headers are listed in the .deps/*.Plo files, I probably get unnecessary rebuilds because of that. I wonder if it is possible to prevent such header files from appearing in these .deps/*.Plo files. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Bug#431464: autoconf: files are rebuilt several times on vfat (because cp -p can't preserve time?)
Hello Vincent, * Vincent Lefevre wrote on Mon, Jul 09, 2007 at 02:37:19PM CEST: On my Zaurus, GCC and some of header files are in a directory mounted with CRAMFS. The timestamps of these files are meaningless, e.g. [...] As such headers are listed in the .deps/*.Plo files, I probably get unnecessary rebuilds because of that. I wonder if it is possible to prevent such header files from appearing in these .deps/*.Plo files. Why don't you simply configure --disable-dependency-tracking ? Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431464: autoconf: files are rebuilt several times on vfat (because cp -p can't preserve time?)
On 2007-07-09 18:50:46 +0200, Ralf Wildenhues wrote: Why don't you simply configure --disable-dependency-tracking ? Yes, I could do that on the Zaurus (I didn't know this feature as it usually doesn't appear in configure --help of other software). I'll try that. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Bug#431464: autoconf: files are rebuilt several times on vfat (because cp -p can't preserve time?)
* Vincent Lefevre wrote on Mon, Jul 09, 2007 at 09:24:36PM CEST: On 2007-07-09 18:50:46 +0200, Ralf Wildenhues wrote: Why don't you simply configure --disable-dependency-tracking ? Yes, I could do that on the Zaurus (I didn't know this feature as it usually doesn't appear in configure --help of other software). I'll try that. Unless the package uses the Automake option no-dependencies globally (in which case dependencies are not used), ./configure --help will show both of the following lines, and if it doesn't, please report a bug against Automake, thanks. --disable-dependency-tracking speeds up one-time build --enable-dependency-tracking do not reject slow dependency extractors And the manual describes all this in more detail: http://sources.redhat.com/automake/automake.html#Dependency-Tracking Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431464: autoconf: files are rebuilt several times on vfat (because cp -p can't preserve time?)
Vincent Lefevre [EMAIL PROTECTED] writes: On 2007-07-07 14:17:51 -0700, Ben Pfaff wrote: Do you have a suggestion for how I might reproduce the problem on a desktop system? If I can reproduce it, I can probably debug it. I've now found the problem. This is unrelated to the use of cp -p. On my Zaurus, GCC and some of header files are in a directory mounted with CRAMFS. The timestamps of these files are meaningless, e.g. -rwxr-xr-x1 root root 808 Jul 9 14:30 exception* -rwxr-xr-x1 root root 3360 Jan 1 1970 float.h* Is this a bug in cramfs? You might well decide to bring this up on the linux-kernel mailing list to figure out what's going on. I don't think that this is a bug in Autoconf. Do you agree? If so, then I will close the bug. -- I admire him, I frankly confess it; and when his time comes I shall buy a piece of the rope for a keepsake. --Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431464: autoconf: files are rebuilt several times on vfat (because cp -p can't preserve time?)
Vincent Lefevre [EMAIL PROTECTED] writes: I've built a MPFR tarball on this Debian machine and transfered it to my Zaurus (a PDA under Linux), which has a SD card with a vfat file system. Doing make check on the Zaurus rebuilds files several times: make check builds the test files twice, run the tests, then rebuilds MPFR entirely (so that I can't see the test results, in particular). I've now attempted to reproduce this problem. I created a 128 MB file, used mkdosfs to create a DOS file system on it, mounted it as vfat, untarred the mpfr candidate from http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc1.tar.gz on it, ran ./configure; make; make check; make. But I didn't observe the behavior you mention. In particular, make check doesn't appear to rebuild the library, and the final make doesn't (re)build anything at all. There is some potential for confusion in running make check, in that it builds many test programs that make does not build. Thus, the first time that you run make check, it will spend a while compiling before it runs the tests, which may be surprising. It does not actually rebuild the library, though. The second time you run make check, it doesn't rebuild anything and runs the tests immediately. (This is what should happen and what I observe on my vfat file system.) My kernel is Linux version 2.6.18-4-686 (Debian 2.6.18.dfsg.1-11), make is version 3.81-3, and the vfat partition is mounted as: /home/blp/tmp/vfat.bin on /mnt type vfat (rw,loop=/dev/loop0,uid=1000,gid=1000) I think I've found the problem. The config.log says: configure:8965: checking whether ln -s works configure:8972: result: no, using cp -p I wonder why -p is used, as on vfat, the mtime cannot be preserved. If the Makefile assumes that cp -p preserves mtime, then it is no longer surprising that I get many file rebuilds. I do not think that this is the problem. It looks to me that ln -s or cp -p is used only by libtool, and only in final link steps. Thus, if this was the problem, I think that the only visible problem would be the possibility of extra re-linkings, not recompilations. I'm out of my own ideas at this point, but I'm willing to continue investigating if you have any leads. -- Ben Pfaff http://benpfaff.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431464: autoconf: files are rebuilt several times on vfat (because cp -p can't preserve time?)
On 2007-07-07 11:12:59 -0700, Ben Pfaff wrote: There is some potential for confusion in running make check, in that it builds many test programs that make does not build. Thus, the first time that you run make check, it will spend a while compiling before it runs the tests, which may be surprising. This is normal. The problem on the Zaurus is that after the tests are run, the library is rebuilt. My kernel is Linux version 2.6.18-4-686 (Debian 2.6.18.dfsg.1-11), make is version 3.81-3, and the vfat partition is mounted as: /home/blp/tmp/vfat.bin on /mnt type vfat (rw,loop=/dev/loop0,uid=1000,gid=1000) On the Zaurus: zaurus:~ uname -a Linux zaurus 2.4.18-rmk7-pxa3-embedix #1 Thu, 6 Nov 2003 09:29:23 +0900 armv5tel unknown GNU Make version 3.77, by Richard Stallman and Roland McGrath. I do not think that this is the problem. It looks to me that ln -s or cp -p is used only by libtool, and only in final link steps. Thus, if this was the problem, I think that the only visible problem would be the possibility of extra re-linkings, not recompilations. I'll have to check again, and perhaps try on the internal Flash (which is not vfat) if I have enough disk space there. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Bug#431464: autoconf: files are rebuilt several times on vfat (because cp -p can't preserve time?)
Vincent Lefevre [EMAIL PROTECTED] writes: On 2007-07-07 11:12:59 -0700, Ben Pfaff wrote: There is some potential for confusion in running make check, in that it builds many test programs that make does not build. Thus, the first time that you run make check, it will spend a while compiling before it runs the tests, which may be surprising. This is normal. The problem on the Zaurus is that after the tests are run, the library is rebuilt. Do you have a suggestion for how I might reproduce the problem on a desktop system? If I can reproduce it, I can probably debug it. -- Ben Pfaff http://benpfaff.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431464: autoconf: files are rebuilt several times on vfat (because cp -p can't preserve time?)
On 2007-07-05 10:01:27 -0700, Ben Pfaff wrote: Thanks for the bug report. I haven't had a chance to investigate it yet, but I will do so as soon as I can. If this is something that is blocking your progress on something important, please let me know so that I can try to give it a higher priority. A second (and last) release candidate of MPFR 2.3.0 is planned for the end of the month. If we can have a fix before this release candidate, this would really be useful. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Bug#431464: autoconf: files are rebuilt several times on vfat (because cp -p can't preserve time?)
Package: autoconf Version: 2.61-4 Severity: normal I've built a MPFR tarball on this Debian machine and transfered it to my Zaurus (a PDA under Linux), which has a SD card with a vfat file system. Doing make check on the Zaurus rebuilds files several times: make check builds the test files twice, run the tests, then rebuilds MPFR entirely (so that I can't see the test results, in particular). I think I've found the problem. The config.log says: configure:8965: checking whether ln -s works configure:8972: result: no, using cp -p I wonder why -p is used, as on vfat, the mtime cannot be preserved. If the Makefile assumes that cp -p preserves mtime, then it is no longer surprising that I get many file rebuilds. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686-bigmem (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages autoconf depends on: ii debianutils 2.22 Miscellaneous utilities specific t ii m41.4.9-2a macro processing language ii perl 5.8.8-7Larry Wall's Practical Extraction Versions of packages autoconf recommends: ii automake1.6 [automaken] 1.6.3-12 A tool for generating GNU Standard ii automake1.7 [automaken] 1.7.9-9A tool for generating GNU Standard ii automake1.8 [automaken] 1.8.5+nogfdl-2 A tool for generating GNU Standard ii automake1.9 [automaken] 1.9.6+nogfdl-3 A tool for generating GNU Standard -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
