Building Rtems 4.10 using RSB on Fedora 25
rmd
rmderbes at gmail.com
Thu Jan 26 05:05:54 UTC 2017
Hello all, Chris
I'm trying to build rtems4.10 and sparc toolchain using
rtems-source-builder on a Fedora 25 x86_64 host, but I ran into an error
building gcc.
In report file
rsb-report-sparc-rtems4.10-gcc-4.4.7-newlib-1.18.0-x86_64-linux-gnu-1.txt
this error cannot be found since its a tail of build log file, but
peeking into rsb-log-xx.txt I found:
../../gcc-4.4.7/gcc/toplev.c: At top level:
../../gcc-4.4.7/gcc/toplev.c:536:1: error: redefinition of 'floor_log2'
floor_log2 (unsigned HOST_WIDE_INT x)
^~~~~~~~~~
In file included from ../../gcc-4.4.7/gcc/toplev.c:58:0:
../../gcc-4.4.7/gcc/toplev.h:190:1: note: previous definition of
'floor_log2' was here
floor_log2 (unsigned HOST_WIDE_INT x)
^~~~~~~~~~
../../gcc-4.4.7/gcc/toplev.c:571:1: error: redefinition of 'exact_log2'
exact_log2 (unsigned HOST_WIDE_INT x)
^~~~~~~~~~
In file included from ../../gcc-4.4.7/gcc/toplev.c:58:0:
../../gcc-4.4.7/gcc/toplev.h:196:1: note: previous definition of
'exact_log2' was here
exact_log2 (unsigned HOST_WIDE_INT x)
^~~~~~~~~~
My host is an up-to-date Fedora 25 system, and the gcc version installed
is gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1).
In toplev.c , floor_log2 and exact_log2 are defined in this snippet:
----
/* When compiling with a recent enough GCC, we use the GNU C "extern inline"
for floor_log2 and exact_log2; see toplev.h. That construct, however,
conflicts with the ISO C++ One Definition Rule. */
#if ((GCC_VERSION < 3004) || defined(__clang__)) || !defined (__cplusplus)
/* Given X, an unsigned number, return the largest int Y such that 2**Y
<= X.
If X is 0, return -1. */
int floor_log2 (unsigned HOST_WIDE_INT x)
{
int t = 0;
...
...
return t;
}
/* Return the logarithm of X, base 2, considering X unsigned,
if X is a power of 2. Otherwise, returns -1. */
int exact_log2 (unsigned HOST_WIDE_INT x)
{
...
...
}
#endif /* GCC_VERSION < 3004 || !defined (__cplusplus) */
----
and in toplev.h:
/* Return log2, or -1 if not exact. */
extern int exact_log2 (unsigned HOST_WIDE_INT);
/* Return floor of log2, with -1 for zero. */
extern int floor_log2 (unsigned HOST_WIDE_INT);
/* Inline versions of the above for speed. */
#if (GCC_VERSION >= 3004) && !defined(__clang__)
# if HOST_BITS_PER_WIDE_INT == HOST_BITS_PER_LONG
# define CLZ_HWI __builtin_clzl
# define CTZ_HWI __builtin_ctzl
# elif HOST_BITS_PER_WIDE_INT == HOST_BITS_PER_LONGLONG
# define CLZ_HWI __builtin_clzll
# define CTZ_HWI __builtin_ctzll
# else
# define CLZ_HWI __builtin_clz
# define CTZ_HWI __builtin_ctz
# endif
extern inline int floor_log2 (unsigned HOST_WIDE_INT x)
{
return x ? HOST_BITS_PER_WIDE_INT - 1 - (int) CLZ_HWI (x) : -1;
}
extern inline int exact_log2 (unsigned HOST_WIDE_INT x)
{
return x == (x & -x) && x ? (int) CTZ_HWI (x) : -1;
}
#endif /* GCC_VERSION >= 3004 */
I think that, as in message
https://lists.rtems.org/pipermail/users/2016-March/030034.html, the
problem lays in the macro that determines GCC version, apparently broken
in newer versions.
In that message thread, host GCC version was 5.1.x, and no proper
solution was found except patching gcc code, repackaging it and also
modifying RSB due to hashes verification.
Also, I see that rtems patch for gcc4.4.7 in RSB
(gcc-core-4.4.7-rtems4.10-20120314.diff) code already includes a patch
to toplev.c/h files, but only for compiling with clang.
Is there any other solution?
Thank you very much
Ricardo
More information about the users
mailing list