A possible bit for a README or FAQ?
Just came across this error while running configure: checking for gcc... gcc checking whether the C compiler (gcc ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. The problem was that /tmp was full - sort of. The system says there's no space: % cat /etc/termcap > /tmp/termcap bash: /tmp/termcap: No space left on device but df disagrees: % df /tmp Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda5 153667 88796 56935 61% / Short term workaround is to run configure with TMPDIR set somewhere else. Perhaps this is something to put in a gcc-specific or Unix-specific section of the README file. I didn't see anything, and the message emitted by configure gave no hint at the cause of the problem. I realized what it was because I've been scratching my head about this problem for a couple weeks. If this is deemed useful I'll modify README and check it in. If not, no big deal. (I have no idea why the system thinks /tmp is full... sigh ...) Skip
On Thu, Oct 26, 2000 at 06:29:49AM -0700, Neil Schemenauer wrote:
The problem was that /tmp was full - sort of.
You might try "df -i". You could be out inodes but still have blocks.
Or failing that, it could be out of 'indirect' or 'doubly-indirect' blocks, or some other filesystem resource. Not often the case for something like /tmp, but definately possible on some filesystems. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters <thomas@xs4all.net>:
Or failing that, it could be out of 'indirect' or 'doubly-indirect' blocks,
I think they're allocated from the same pool as data blocks. What *can* happen is that you can run out of "large" blocks. The BSD-style filesystem stores files bigger than 8k in blocks made up of 8 contiguous 1k blocks. If the filesystem is nearly full, or contains a large number of small files, you can find that it's impossible to create any more files > 8k, even though there appears to be plenty of free space, because the space is too fragmented. I don't think that's what's happening here, though, since I've only ever seen it happen when the filesystem was about 99% full. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Neil> You might try "df -i". You could be out inodes but still have Neil> blocks. Thanks, that indeed seems to be the problem: % df -i /tmp Filesystem Inodes IUsed IFree IUse% Mounted on /dev/hda5 39k 39k 7 100% / I don't believe in all my years of fiddling with Unix systems I've ever run out of inodes with a third of the disk space left. Now to identify the culprit. Skip
Skip Montanaro writes:
If this is deemed useful I'll modify README and check it in. If not, no big deal.
Personally, I don't think this is useful. I don't think the Python README is the place to list everything that can go wrong during ./configure. The generic advice is "If something goes wrong during ./configure, read through config.log to see what went wrong" I'm curious what is in your config.log when this error occurs!
Charles> The generic advice is "If something goes wrong during Charles> ./configure, read through config.log to see what went wrong" Agreed. Charles> I'm curious what is in your config.log when this error occurs! That's why I was thinking ("hmmm... perhaps a README bit"). It wasn't giving me obvious "no space" messages. I've concluded that it's probably best to forget it anyway. If it's a problem with configure or gcc messages, it's best addressed there. Skip
On Thu, Oct 26, 2000 at 03:10:33PM -0500, Skip Montanaro wrote:
If this is deemed useful I'll modify README and check it in. If not, no big deal.
If you start adding things like that, also consider all the other possibilities of configure being wrong. I hinted at one of them a couple of weeks back, I think. (Somehow, 'last saturday', when I headed for London for the Apachecon, feels like about two months ago :P) It's perfectly possible for configure to be able to run gcc, gcc to be able to create working binaries, but every check for a function or datatype failing because the more 'involved' include files are missing. This is easy to do on Linux, (removing /usr/src/linux, for instance) but not impossible on other systems either. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
On Thu, Oct 26, 2000 at 06:29:49AM -0700, Neil Schemenauer wrote:
The problem was that /tmp was full - sort of.
You might try "df -i". You could be out inodes but still have blocks.
Or failing that, it could be out of 'indirect' or 'doubly-indirect' blocks, or some other filesystem resource. Not often the case for something like /tmp, but definately possible on some filesystems. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters <thomas@xs4all.net>:
Or failing that, it could be out of 'indirect' or 'doubly-indirect' blocks,
I think they're allocated from the same pool as data blocks. What *can* happen is that you can run out of "large" blocks. The BSD-style filesystem stores files bigger than 8k in blocks made up of 8 contiguous 1k blocks. If the filesystem is nearly full, or contains a large number of small files, you can find that it's impossible to create any more files > 8k, even though there appears to be plenty of free space, because the space is too fragmented. I don't think that's what's happening here, though, since I've only ever seen it happen when the filesystem was about 99% full. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Neil> You might try "df -i". You could be out inodes but still have Neil> blocks. Thanks, that indeed seems to be the problem: % df -i /tmp Filesystem Inodes IUsed IFree IUse% Mounted on /dev/hda5 39k 39k 7 100% / I don't believe in all my years of fiddling with Unix systems I've ever run out of inodes with a third of the disk space left. Now to identify the culprit. Skip
Skip Montanaro writes:
If this is deemed useful I'll modify README and check it in. If not, no big deal.
Personally, I don't think this is useful. I don't think the Python README is the place to list everything that can go wrong during ./configure. The generic advice is "If something goes wrong during ./configure, read through config.log to see what went wrong" I'm curious what is in your config.log when this error occurs!
Charles> The generic advice is "If something goes wrong during Charles> ./configure, read through config.log to see what went wrong" Agreed. Charles> I'm curious what is in your config.log when this error occurs! That's why I was thinking ("hmmm... perhaps a README bit"). It wasn't giving me obvious "no space" messages. I've concluded that it's probably best to forget it anyway. If it's a problem with configure or gcc messages, it's best addressed there. Skip
On Thu, Oct 26, 2000 at 03:10:33PM -0500, Skip Montanaro wrote:
If this is deemed useful I'll modify README and check it in. If not, no big deal.
If you start adding things like that, also consider all the other possibilities of configure being wrong. I hinted at one of them a couple of weeks back, I think. (Somehow, 'last saturday', when I headed for London for the Apachecon, feels like about two months ago :P) It's perfectly possible for configure to be able to run gcc, gcc to be able to create working binaries, but every check for a function or datatype failing because the more 'involved' include files are missing. This is easy to do on Linux, (removing /usr/src/linux, for instance) but not impossible on other systems either. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
participants (5)
-
Charles G Waldman -
Greg Ewing -
Neil Schemenauer -
Skip Montanaro -
Thomas Wouters