Source: horst Version: 3.0-2 Horst is failing to build on arm64:
https://buildd.debian.org/status/package.php?p=horst&suite=sid <https://nexus.arm.com/owa/redir.aspx?C=1ydigxXdLUyWAuwq1SsAaqqJN4M3j9FI7NjItfsWFfJQtGZkK1lRYLnk9zn2GMTFvHl3Z4lJB04.&URL=https%3a%2f%2fbuildd.debian.org%2fstatus%2fpackage.php%3fp%3dhorst%26suite%3dsid> There are two definitions of __le64. main.c first includes <signal.h>, which includes files provided by linux-libc-dev and defines it like this: __extension__ typedef unsigned long long __u64; typedef __u64 __le64; main.c then includes the package's "ieee80211.h", which includes <sys/types.h> provided by libc6-dev and defines it like this: typedef unsigned int u_int64_t __attribute__ ((__mode__ (__DI__))); typedef u_int64_t __le64; You might hope that the compiler would consider these types to be equivalent and allow the redefinition but clearly it doesn't in this case. To avoid this and similar problems in future it might be better not to define names beginning with "__" in the package's own code because these names are reserved for the system and the package's "ieee80211.h" is not part of the system now. You could substitute the names with the preprocessor but that would cause even more mayhem if you ever included a system header after having #defined the name so perhaps you should really replace them, like this: cd horst-3.0/ for x in `find -name '*.[ch]'` ; do perl -i -pe 's/__le(16|32|64)/le${1}_t/g;' $x done The package seems to build with that change to the source code, but I haven't tried using it.
