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 <[email protected]>:
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 <[email protected]>
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
[email protected]
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
