Build failure - missing linux/limits.h include?

Chris Larson

author

2003-11-24 23:12 UTC #0 lore raw

Greetings,

udev fails to compile here unless I'm doing a KLIBC build. The reason appears to be that the normal limits.h in the gcc inc dir doesn't pull in linux/limits.h, whereas the limits.h out in the klibc include dirs does. I'd think it'd be best to add a #include <linux/limits.h> to udev.h directly, since it uses PATH_MAX.

--
Chris Larson - kergoth at handhelds dot org Embedded Linux Developer - clarson at ti dot com OpenZaurus Project Maintainer - http://openzaurus.org/

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Arnd Bergmann

2003-11-25 00:18 UTC #1 lore raw

Quoted 5 lines · Chris Larson

udev fails to compile here unless I'm doing a KLIBC build. The reason appears to be that the normal limits.h in the gcc inc dir doesn't pull in linux/limits.h, whereas the limits.h out in the klibc include dirs does. I'd think it'd be best to add a #include <linux/limits.h> to udev.h directly, since it uses PATH_MAX.

No, don't include kernel headers directly if you can avoid it. The problem you are referring to seems to be with old tool chains, I have the same symptom with my s390 gcc-2.95/glibc-2.1.3. Including <sys/param.h> instead of <limits.h> seems to fix it.

	Arnd <><

=== udev.h 1.20 vs edited ==--- 1.20/udev.h Sun Nov 23 23:25:13 2003
+++ edited/udev.h Tue Nov 25 01:17:06 2003
@@ -24,7 +24,7 @@
#define UDEV_H

#include "libsysfs/libsysfs.h"
-#include <limits.h>
+#include <sys/param.h>

#ifdef DEBUG
#include <syslog.h>

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Chris Larson

author

2003-11-25 00:29 UTC #2 lore raw

In reply to Chris Larson

Quoted 11 lines · * Arnd Bergmann ([email protected]) wrote:

Quoted 5 lines · Chris Larson
udev fails to compile here unless I'm doing a KLIBC build. The reason appears to be that the normal limits.h in the gcc inc dir doesn't pull in linux/limits.h, whereas the limits.h out in the klibc include dirs does. I'd think it'd be best to add a #include <linux/limits.h> to udev.h directly, since it uses PATH_MAX.
No, don't include kernel headers directly if you can avoid it. The problem you are referring to seems to be with old tool chains, I have the same symptom with my s390 gcc-2.95/glibc-2.1.3. Including <sys/param.h> instead of <limits.h> seems to fix it.

Ah, that's better. Thanks :)
--
Chris Larson - kergoth at handhelds dot org Embedded Linux Developer - clarson at ti dot com OpenZaurus Project Maintainer - http://openzaurus.org/

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Greg KH

Applied

2003-12-02 00:30 UTC #3 lore raw

In reply to Chris Larson

Quoted 11 lines · Arnd Bergmann

Quoted 5 lines · Chris Larson
udev fails to compile here unless I'm doing a KLIBC build. The reason appears to be that the normal limits.h in the gcc inc dir doesn't pull in linux/limits.h, whereas the limits.h out in the klibc include dirs does. I'd think it'd be best to add a #include <linux/limits.h> to udev.h directly, since it uses PATH_MAX.
No, don't include kernel headers directly if you can avoid it. The problem you are referring to seems to be with old tool chains, I have the same symptom with my s390 gcc-2.95/glibc-2.1.3. Including <sys/param.h> instead of <limits.h> seems to fix it.

Applied, thanks.

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel