Conversation
|
Could you please add the build error console output to the commit message to make this a perfect patch? BTW, looks like the fix is very similar to 043761b |
|
@n1tehawk already attempted to contact @panzi in the https://gist.github.com/panzi/6856583 gist about this. Also I see that the only difference in that problematic ifdef block are some extra defines. Could it be that they are only needed on some versions of NetBSD and DragonFly and caouse build problems on the others? The information about the DragonFly BSD version (or rather the version of its C library?) would be welcome in the commit message too. |
|
AFAICT DragonFly is a FreeBSD derivate, so it seems natural that this change follows the 043761b one. When you amend your commit message, please add a "Signed-by:" ( Regards, NiteHawk |
|
Hi, This is the build error: $ gmake cc -std=c99 -Wall -Wextra -Wno-unused-result -D_POSIX_C_SOURCE=200112L -D_BSD_SOURCE -D_DEFAULT_SOURCE -Iinclude/ -o sunxi-fexc fexc.c script.c script_uboot.c script_bin.c script_fex.c define be16toh(x) betoh16(x)^ define le16toh(x) letoh16(x)^ define be32toh(x) betoh32(x)^ define le32toh(x) letoh32(x)^ define be64toh(x) betoh64(x)^ define le64toh(x) letoh64(x)^ define be32toh(x) betoh32(x)fel.c:165:6: note: in expansion of macro 'be32toh' define le32toh(x) letoh32(x)fel.c:243:17: note: in expansion of macro 'le32toh' define le16toh(x) letoh16(x)fel.c:246:20: note: in expansion of macro 'le16toh' Let me check this further. Best regards, |
|
Thanks! Just condense this error log (keep only the essential part) and add your Signed-off-by tag to the commit message (via "git commit --amend"). Then force-push the updated commit to the branch used for your merge request and we are done with it. |
|
I'm suspecting more and more that older *BSDs did not have those names in their endian.h, which is probably why those additional It's well possible that we'll see the issue come up even on NetBSD - judging from https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/sys/endian.h we'd be redefining those macros there too. Maybe we should test / safeguard the [EDIT] Further information is available in the endian(3) man page (section "Conforming to"):
It looks like this is 'historic' information that might no longer apply to more recent *BSD versions. |
See pull requests linux-sunxi#59 and linux-sunxi#83. It looks like various BSD derivates have adopted the more common naming conventions for the endian conversion macros, which means that we would attempt to redefine them without need (potentially even to 'historic' names that no longer exist). Try to avoid this by properly checking for existing functions first. Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
|
Haven't test the patch on FreeBSD but I don't see why it wouldn't work. |
|
Hi, Will try it over the weekend and report here. Cheers, |
evadot
left a comment
There was a problem hiding this comment.
Just tested on FreeBSD, no problem for me.
See pull requests linux-sunxi#59 and linux-sunxi#83. It looks like various BSD derivates have adopted the more common naming conventions for the endian conversion macros, which means that we would attempt to redefine them without need (potentially even to 'historic' names that no longer exist). Try to avoid this by properly checking for existing functions first. Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
See pull requests #59 and #83. It looks like various BSD derivates have adopted the more common naming conventions for the endian conversion macros, which means that we would attempt to redefine them without need (potentially even to 'historic' names that no longer exist). Try to avoid this by properly checking for existing functions first. Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
|
Should be addressed by merging 384ff64 - closing this now. |
No description provided.