host-acl: build fix on RHEL6 hosts (GCC 4.4.7)
PATCH 1/1 host-acl: build fix on RHEL6 hosts (GCC 4.4.7)
This didn't introduce any build warnings, FWIW.
package/acl/0001-pragma-gcc-diagnostic-in-fn.patch new file +21 -0
@@ -0,0 +1,21 @@ +build with old GCC versions + +GCC 4.4.7, as found in RHEL6, reports: + libacl/acl_from_text.c:307: error: #pragma GCC diagnostic not allowed inside functions + +Signed-off-by: Hollis Blanchard <[email protected]> + +--- host-acl-2.2.53/libacl/acl_from_text.c.orig 2018-07-19 09:15:40.425940094 -0700 ++++ host-acl-2.2.53/libacl/acl_from_text.c 2018-07-19 09:15:50.777940093 -0700 +@@ -304,11 +304,8 @@ + create_entry: + if (acl_create_entry(acl_p, &entry_d) != 0) + return -1; +-#pragma GCC diagnostic push +-#pragma GCC diagnostic ignored "-Waddress" + if (acl_copy_entry(entry_d, int2ext(&entry_obj)) != 0) + return -1; +-#pragma GCC diagnostic pop + return 0; + + fail:
PATCH 1/1 host-attr: build fix for RHEL6 hosts (GCC 4.4.7)
package/attr/0001-deprecated-attribute-message.patch new file +76 -0
@@ -0,0 +1,76 @@ +build with older GCCs + +GCC versions up through 4.4.7 (which is used in RHEL 6) do not accept any +argument for the deprecated attribute. GCC 4.5 and later say the "msg" +argument is optional. We don't need the messages during Buildroot builds +anyways. + +Signed-off-by: Hollis Blanchard <[email protected]> + +--- host-attr-2.4.48/include/attributes.h.orig 2018-07-19 08:49:19.506854736 -0700 ++++ host-attr-2.4.48/include/attributes.h 2018-07-19 08:49:22.132854736 -0700 +@@ -127,10 +127,10 @@ + */ + EXPORT int attr_get (const char *__path, const char *__attrname, + char *__attrvalue, int *__valuelength, int __flags) +- __attribute__ ((deprecated ("Use getxattr or lgetxattr instead"))); ++ __attribute__ ((deprecated)); + EXPORT int attr_getf (int __fd, const char *__attrname, char *__attrvalue, + int *__valuelength, int __flags) +- __attribute__ ((deprecated ("Use fgetxattr instead"))); ++ __attribute__ ((deprecated)); + + /* + * Set the value of an attribute, creating the attribute if necessary. +@@ -139,11 +139,11 @@ + EXPORT int attr_set (const char *__path, const char *__attrname, + const char *__attrvalue, const int __valuelength, + int __flags) +- __attribute__ ((deprecated ("Use setxattr or lsetxattr instead"))); ++ __attribute__ ((deprecated)); + EXPORT int attr_setf (int __fd, const char *__attrname, + const char *__attrvalue, const int __valuelength, + int __flags) +- __attribute__ ((deprecated ("Use fsetxattr instead"))); ++ __attribute__ ((deprecated)); + + /* + * Remove an attribute. +@@ -151,9 +151,9 @@ + */ + EXPORT int attr_remove (const char *__path, const char *__attrname, + int __flags) +- __attribute__ ((deprecated ("Use removexattr or lremovexattr instead"))); ++ __attribute__ ((deprecated)); + EXPORT int attr_removef (int __fd, const char *__attrname, int __flags) +- __attribute__ ((deprecated ("Use fremovexattr instead"))); ++ __attribute__ ((deprecated)); + + /* + * List the names and sizes of the values of all the attributes of an object. +@@ -164,10 +164,10 @@ + */ + EXPORT int attr_list(const char *__path, char *__buffer, const int __buffersize, + int __flags, attrlist_cursor_t *__cursor) +- __attribute__ ((deprecated ("Use listxattr or llistxattr instead"))); ++ __attribute__ ((deprecated)); + EXPORT int attr_listf(int __fd, char *__buffer, const int __buffersize, + int __flags, attrlist_cursor_t *__cursor) +- __attribute__ ((deprecated ("Use flistxattr instead"))); ++ __attribute__ ((deprecated)); + + /* + * Operate on multiple attributes of the same object simultaneously. +@@ -188,10 +188,10 @@ + */ + EXPORT int attr_multi (const char *__path, attr_multiop_t *__oplist, + int __count, int __flags) +- __attribute__ ((deprecated ("Use getxattr, setxattr, listxattr, removexattr instead"))); ++ __attribute__ ((deprecated)); + EXPORT int attr_multif (int __fd, attr_multiop_t *__oplist, + int __count, int __flags) +- __attribute__ ((deprecated ("Use getxattr, setxattr, listxattr, removexattr instead"))); ++ __attribute__ ((deprecated)); + + #ifdef __cplusplus + }
PATCH 1/1 libglib2: build fix for RHEL6 hosts (GCC 4.4.7)
In reply to Hollis Blanchardpackage/libglib2/0004-define-F_SETPIPE_SZ.patch new file +17 -0
@@ -0,0 +1,17 @@ +On RHEL6 hosts, fcntl.h doesn't define F_SETPIPE_SZ or F_GETPIPE_SZ. + +Signed-off-by: Hollis Blanchard <[email protected]> + +--- libglib2-2.56.1/gio/gfile.c.orig 2018-07-12 11:31:13.862255422 -0700 ++++ libglib2-2.56.1/gio/gfile.c 2018-07-12 12:06:49.984118708 -0700 +@@ -34,6 +34,10 @@ + #include <sys/stat.h> + #include <unistd.h> + #include <fcntl.h> ++#ifndef F_SETPIPE_SZ ++#define F_SETPIPE_SZ 1031 ++#define F_GETPIPE_SZ 1032 ++#endif + #include <errno.h> + #endif +
PATCH 1/1 host-acl: build fix on RHEL6 hosts (GCC 4.4.7)
In reply to Hollis BlanchardHello,
Quoted 9 lines · Hollis Blanchard
This didn't introduce any build warnings, FWIW.
Signed-off-by Hollis Blanchard <[email protected]>package/acl/0001-pragma-gcc-diagnostic-in-fn.patch new file +0
-0
package/acl/0001-pragma-gcc-diagnostic-in-fn.patch line 6
Quoted 6 lines
package/acl/0001-pragma-gcc-diagnostic-in-fn.patch new file +6
-0@@ -0,0 +1,21 @@ +build with old GCC versions + +GCC 4.4.7, as found in RHEL6, reports: + libacl/acl_from_text.c:307: error: #pragma GCC diagnostic not allowed inside functions + +Signed-off-by: Hollis Blanchard <[email protected]>
Are you sure removing this won't break the build with newer gcc versions ?
In any case, for all three of your patches, could you please use Git to generate the package patches themselves ? All three packages being patched use Git upstream, and we very much like having Git formatted patches in this case.
However, a larger question is: do you intend to contribute an autobuilder that tests Buildroot under RHEL6 ? Indeed, you are fixing just the few packages that are useful to you, but if we are going to support something as old as RHEL6, then we need to do it properly and have an autobuilder running on this distro. Do you think this is something that could be done ?
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
PATCH 1/1 host-acl: build fix on RHEL6 hosts (GCC 4.4.7)
Quoted 7 lines · Thomas Petazzoni
Hello,
Quoted 4 lines · Hollis Blanchard
This didn't introduce any build warnings, FWIW.
Signed-off-by Hollis Blanchard <[email protected]>
Quoted 13 lines
package/acl/0001-pragma-gcc-diagnostic-in-fn.patch line 6
Quoted 11 lines
package/acl/0001-pragma-gcc-diagnostic-in-fn.patch new file +6
-0@@ -0,0 +1,21 @@ +build with old GCC versions + +GCC 4.4.7, as found in RHEL6, reports: + libacl/acl_from_text.c:307: error: #pragma GCC diagnostic not allowed inside functions + +Signed-off-by: Hollis Blanchard <[email protected]>Are you sure removing this won't break the build with newer gcc versions ?
I've built it with host gcc 6.3.0 and 4.4.7 and saw no warnings in either case. (Aside: patchelf refused to build with 6.3.0, so I had to manually build that.)
If some toolchain emits a warning on this code, and if the package is built with -Werror somehow, I suppose it's possible to break the build. If you'd like, I will try relocating the pragma outside the whole function, which could only hide more warnings and thus be less likely to break the build.
Quoted 4 lines
In any case, for all three of your patches, could you please use Git to generate the package patches themselves ? All three packages being patched use Git upstream, and we very much like having Git formatted patches in this case.
OK.
Quoted 6 lines
However, a larger question is: do you intend to contribute an autobuilder that tests Buildroot under RHEL6 ? Indeed, you are fixing just the few packages that are useful to you, but if we are going to support something as old as RHEL6, then we need to do it properly and have an autobuilder running on this distro. Do you think this is something that could be done ?
Not certain, but possible. What does it entail, exactly? Do I just have to run
https://git.buildroot.net/buildroot-test/tree/scripts/autobuild-run via cron?
Hollis Blanchard
Mentor Graphics Emulation Division
PATCH 1/1 host-acl: build fix on RHEL6 hosts (GCC 4.4.7)
Hello Hollis,
Quoted 9 lines · Hollis Blanchard
Quoted 3 lines
Quoted 1 line
+Signed-off-by: Hollis Blanchard <[email protected]>
Are you sure removing this won't break the build with newer gcc versions ?
I've built it with host gcc 6.3.0 and 4.4.7 and saw no warnings in either case. (Aside: patchelf refused to build with 6.3.0, so I had to manually build that.)
If some toolchain emits a warning on this code, and if the package is built with -Werror somehow, I suppose it's possible to break the build.
The package doesn't seem to be built with -Werror by default, so it should be fine. Let's apply your patch, and see if it works fine on the autobuilders.
Quoted 10 lines
Quoted 6 lines
However, a larger question is: do you intend to contribute an autobuilder that tests Buildroot under RHEL6 ? Indeed, you are fixing just the few packages that are useful to you, but if we are going to support something as old as RHEL6, then we need to do it properly and have an autobuilder running on this distro. Do you think this is something that could be done ?
Not certain, but possible. What does it entail, exactly? Do I just have to run
https://git.buildroot.net/buildroot-test/tree/scripts/autobuild-run via cron?
It is about running this script yes, but it does not need to be run in cron, the script itself is an infinite loop that continuously does some builds and contribute the results to autobuild.buildroot.org.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
PATCH 1/1 host-acl: build fix on RHEL6 hosts (GCC 4.4.7)
Quoted 5 lines · Thomas Petazzoni
Hello Hollis,
Quoted 1 line · Hollis Blanchard
Quoted 1 line
Quoted 1 line
+Signed-off-by: Hollis Blanchard <[email protected]>
[snip]
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
However, a larger question is: do you intend to contribute an autobuilder that tests Buildroot under RHEL6 ? Indeed, you are fixing just the few packages that are useful to you, but if we are going to support something as old as RHEL6, then we need to do it properly and have an autobuilder running on this distro. Do you think this is something that could be done ?
Quoted 8 lines
Quoted 4 lines
Not certain, but possible. What does it entail, exactly? Do I just have to run
https://git.buildroot.net/buildroot-test/tree/scripts/autobuild-run via cron?It is about running this script yes, but it does not need to be run in cron, the script itself is an infinite loop that continuously does some builds and contribute the results to autobuild.buildroot.org.
You also need disk space, at least 100GB per job I think? That's the sole
reason why I'm not running an autobuilder myself. It's very annoying to get spurious failures because of -ENOSPC.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
[Buildroot] RHEL6 autobuilder
In reply to Thomas PetazzoniQuoted 7 lines · Thomas Petazzoni
Quoted 7 lines
Quoted 7 lines
However, a larger question is: do you intend to contribute an autobuilder that tests Buildroot under RHEL6 ? Indeed, you are fixing just the few packages that are useful to you, but if we are going to support something as old as RHEL6, then we need to do it properly and have an autobuilder running on this distro. Do you think this is something that could be done ?
Quoted 7 lines
Quoted 4 lines
Not certain, but possible. What does it entail, exactly? Do I just have to run
https://git.buildroot.net/buildroot-test/tree/scripts/autobuild-run via cron?It is about running this script yes, but it does not need to be run in cron, the script itself is an infinite loop that continuously does some builds and contribute the results to autobuild.buildroot.org.
OK, I set this up on a RHEL6.5 host, and it ran enough to hit the known libglib2 problem <https://patchwork.ozlabs.org/patch/947086/>. I encountered two issues along the way:
* buildroot-test/buildroot-autobuild script uses the --detach option to 'git checkout', which RHEL6.5's git doesn't know about. I just deleted the option and everything's working fine. I can submit a patch if you like.
* buildroot/utils/genrandconfig uses argparse, which doesn't exist in RHEL6.5's Python. I avoided the problem for now by supplying an alternate Python installation.
I guess I just need HTTP credentials to submit to
http://autobuild.buildroot.org ?
Hollis Blanchard
Mentor Graphics Emulation Division
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180727/e4b5cf34/attachment.html>
[Buildroot] RHEL6 autobuilder
Hello Hollis,
+Arnout in Cc about the --detach option.
Quoted 3 lines · Hollis Blanchard
OK, I set this up on a RHEL6.5 host, and it ran enough to hit the known libglib2 problem <https://patchwork.ozlabs.org/patch/947086/>. I encountered two issues along the way:
Great!
Quoted 4 lines
* buildroot-test/buildroot-autobuild script uses the --detach option to 'git checkout', which RHEL6.5's git doesn't know about. I just deleted the option and everything's working fine. I can submit a patch if you like.
This option was added in commit 66f91eb4409e5efacb1871b8ab2b336c4873b796, and Arnout gave the following reason:
Since switching repositories may also switch branches, we use a git fetch/checkout sequence instead of doing a git pull. With git pull, the branches would be merged instead of switched. To avoid polluting the log with the long git message about a detached head, while still getting some useful output from git, pass the --detach option to git checkout.
Since it's apparently just about logging, perhaps we can just remove it. Arnout ?
Quoted 3 lines
* buildroot/utils/genrandconfig uses argparse, which doesn't exist in RHEL6.5's Python. I avoided the problem for now by supplying an alternate Python installation.
Sounds good.
Quoted 2 lines
I guess I just need HTTP credentials to submit to
http://autobuild.buildroot.org ?
I'll reply to you privately about this.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com