Hi glibc maintainers! I'm tempted to reopen this bug because it still breaks software even without using 'extern int errno'. I received a grave bug #219103 against epstool 3.02-3 yesterday, epstool failed with the current glibc because of this errno relocation issue. But grepping the source tree shows that everything is in order: martin@donald:~/debian/epstool-3.02$ grep -r errno . ./src/epstool.c:#include <errno.h> ./src/epstool.c: fprintf(stderr, "Failed to fork, error=%d\n", errno); ./src/epstool.c: fprintf(stderr, "Failed to open stdin/out/err, error=%d\n", errno); ./src/epstool.c: fprintf(stderr, "Failed to execute ghostscript, error=%d\n", errno); So epstool.c is the _only_ source file requiring and using errno and it properly includes <errno.h>. I just found out that it works again if I include errno.h in the module clfile.c. That is very odd! IMHO include files should only be required if I actually use something from them. Otherwise fixing such bugs degenerates to randomly trying to include various files until the program works, which is certainly not the most desirable method of programming. If you want to try this yourself, then please download 3.02-3 (in testing), not the current unstable 3.02-4 (this solves the problem by disabling 64-bit file access, it does not use clfile.c; this was the only solution I found yesterday). Are there any satisfying arguments why the inclusion of errno.h in modules not needing it is really necessary? If so, is there any guarantee that this will not hold for other include files in the future? TIA and have a nice day! Martin -- Martin Pitt home: www.piware.de eMail: martin@piware.de
Attachment:
signature.asc
Description: Digital signature