I haven't confirmed that it's the case at all, but I guess this thread is an attempt to fix it:
https://roy.marples.name/archives/dhcpcd-discuss/0003037.html Title is: "Error building 8.1.9 for Smoothwall Express"
They seem to be fixing it "by accident" and moving around the #include <fcntl.h> definition. I should imagine this accidentally fixes it due to some random change in header parse order
My proposed patch should prevent it occuring on this or other projects though
Thanks for your superb help figuring out the original issue!! The error completely threw me! :-)
Ed W
On 16/06/2020 08:19, Yann Sionneau wrote:
Hi,
I'm curious as to why/how it does compile the latest dhcpcd fine?
Is upstream code changed/fixed?
Maybe we didn't understand something here?
Regards,
Yann
On 15/06/2020 16:14, Waldemar Brodkorb wrote:
Hi,
All is fine. I have just seen that the latest dhcpcd is compiling fine with out the patch, but I will apply anyway.
Best regards Waldemar
Am 15.06.2020 um 15:55 schrieb Ed W lists@wildgooses.com:
Hi, Any feedback on this? I'm probably not submitting patches in the correct style - please guide me on what you need?
Thanks
Ed W
On 11/06/2020 17:57, Ed W wrote:
On 11/06/2020 17:20, Ed W wrote: Hi!
Haha! So obvious now that you've pointed it out!! Yes, I confirm that this is the problem! I never even thought to look for such macros upstream! Thanks!
OK, can I propose a patch to uclibc-ng to change the naming of the unused fields to include "uclibc" in the name. This is in the style of glibc, which does the same (only with __glibc_unused)
Signed off: Ed Wildgoose lists@wildgooses.com
Apologies. Previous patch was obviously useless... I'm tired and not thinking before writing. More useful patch submitted, it amends all architectures and renames the spare fields to include a namespace (__uclibc_).
Patch created with:
sed -i -e 's/__unused/__uclibc_unused/' libc/sysdeps/linux/*/bits/*stat.h
This is inline with what glibc is doing, they tend to call spare fields either __glibc_unused or __glibc_reserved
Thanks so much for putting me on the right track to resolving this
Ed W
devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel