Error when building cross compiler
I am getting the following error when compiling "x86_64 to powerpc64"
cross gcc, as soon as the libgcc_s.so.1 has appeared in obj/gcc
directory.
...
# Now that we have built all the objects, we need to copy
# them back to the GCC directory. Too many things (other
# in-tree libraries, and DejaGNU) know about the layout
# of the build tree, for now.
make install-leaf DESTDIR=../.././gcc \
slibdir= libsubdir= MULTIOSDIR=.
make[5]: Entering directory
`/a/linux/.powerpc/gcc/obj/powerpc64-unknown-linux-gnu/libgcc'
/bin/bash ../../../src/libgcc/../mkinstalldirs ../.././gcc
/usr/bin/install -c -m 644 libgcc_eh.a ../.././gcc/
chmod 644 ../.././gcc/libgcc_eh.a
/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/bin/ranlib
../.././gcc/libgcc_eh.a
/bin/bash ../../../src/libgcc/../mkinstalldirs ../.././gcc;
/usr/bin/install -c -m 644 ./libgcc_s.so.1 ../.././gcc/libgcc_s.so.1;
rm -f ../.././gcc/libgcc_s.so; ln -s libgcc_s.so.1
../.././gcc/libgcc_s.so
/bin/bash ../../../src/libgcc/../mkinstalldirs ../.././gcc
/usr/bin/install -c -m 644 libgcc.a ../.././gcc/
chmod 644 ../.././gcc/libgcc.a
/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/bin/ranlib
../.././gcc/libgcc.a
/usr/bin/install -c -m 644 libgcov.a ../.././gcc/
chmod 644 ../.././gcc/libgcov.a
/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/bin/ranlib
../.././gcc/libgcov.a
parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o ecrti.o
ecrtn.o ncrti.o ncrtn.o"; \
for file in $parts; do \
rm -f ../.././gcc/$file; \
/usr/bin/install -c -m 644 $file ../.././gcc/; \
done
make[5]: Leaving directory
`/a/linux/.powerpc/gcc/obj/powerpc64-unknown-linux-gnu/libgcc'
make[4]: Leaving directory
`/a/linux/.powerpc/gcc/obj/powerpc64-unknown-linux-gnu/libgcc'
Checking multilib configuration for libgomp...
mkdir -p -- powerpc64-unknown-linux-gnu/libgomp
Configuring in powerpc64-unknown-linux-gnu/libgomp
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... powerpc64-unknown-linux-gnu
checking target system type... powerpc64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for powerpc64-unknown-linux-gnu-strip...
/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/bin/strip
checking for powerpc64-unknown-linux-gnu-gcc...
/a/linux/.powerpc/gcc/obj/./gcc/xgcc
-B/a/linux/.powerpc/gcc/obj/./gcc/
-B/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/bin/
-B/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/lib/
-isystem /a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/include
-isystem /a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/sys-include
checking for C compiler default output file name... configure: error:
in `/a/linux/.powerpc/gcc/obj/powerpc64-unknown-linux-gnu/libgomp':
configure: error: C compiler cannot create executables
See `config.log' for more details.
make[3]: *** [configure-target-libgomp] Error 1
make[3]: Leaving directory `/a/linux/.powerpc/gcc/obj'
The obj/powerpc64-unknown-linux-gnu/libgomp/config.log content is:
...
configure:2569: checking for C compiler default output file name
configure:2572: /a/linux/.powerpc/gcc/obj/./gcc/xgcc
-B/a/linux/.powerpc/gcc/obj/./gcc/
-B/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/bin/
-B/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/lib/
-isystem /a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/include
-isystem /a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/sys-include
-g -O2 conftest.c >&5
/a/linux/.powerpc/gcc/obj/./gcc/cc1: error while loading shared
libraries: /a/linux/.powerpc/gcc/obj/./gcc/libgcc_s.so.1: ELF file
data encoding not little-endian
configure:2575: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME "GNU OpenMP Runtime Library"
| #define PACKAGE_TARNAME "libgomp"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU OpenMP Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "libgomp"
| #define VERSION "1.0"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2613: error: in
`/a/linux/.powerpc/gcc/obj/powerpc64-unknown-linux-gnu/libgomp':
configure:2616: error: C compiler cannot create executables
See `config.log' for more details.
...
It seems that host cc1 executable tries to load target libgcc_s.so.1
from obj/gcc directory, rather than host libgcc_s.so.1 from /lib. The
message "error while loading shared libraries:
/a/linux/.powerpc/gcc/obj/./gcc/libgcc_s.so.1: ELF file data encoding
not little-endian" is from glibc.
Is this a bug ? And are there any workarounds ?
Re: Error when building cross compiler
>> There is something peculiar going on, because a >> x86_64-unknown-linux-gnu hosted compiler would not normally refer to >> libgcc_s.so.1 at all. Even if it did, nothing would normally direct >> the dynamic linker to look in the gcc build directory. Something is >> wrong but I don't know what it is. I have successfully build cross-compiler with overriden RPATH_ENVVAR, as following: make RPATH_ENVVAR=MY_LD_LIBRARY_PATH So error was indeed caused by changing LD_LIBRARY_PATH during the build, as described by Kai. I think this is a bug.
Re: Error when building cross compiler
The error is also reproduced with gcc 4.5 revision 153504
incorrect place for LTO options description
description of the LTO specific options (--enable-lto, --with-libelf and --enable gold) should be placed in "Options specification" section instead of "Java-Specific Options" section on http://gcc.gnu.org/install/configure.html
GCC 4.5: "nonconstant array index in initializer" error
The following errors appears when I tried to compile linux kernel
2.6.30-rc2 with GCC 4.5:
linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: nonconstant array index
in initializer
linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: (near initialization
for 'drm_ioctls')
...
compiled code looks like this:
static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version, 0),
DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
...
where DRM_IOCTL_DEF defined as
#define DRM_IOCTL_DEF(ioctl, _func, _flags) \
[DRM_IOCTL_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags = _flags}
Just released GCC 4.4 compiles this code without errors.
Is this a bug in GCC 4.5 or the errors caused by folowing changes in GCC 4.5:
"GCC now implements C90- and C99-conforming rules for constant
expressions. This may cause warnings or errors for some code using
expressions that can be folded to a constant but are not constant
expressions as defined by ISO C"
?
If it is not a bug, is there a way to disable this conformance rules
checking with GCC 4.5 ?
Re: GCC 4.5: "nonconstant array index in initializer" error
Thanks for reply!
DRM_IOCTL_NR is defined as
#define _IOC_NRBITS 8
#define _IOC_NRSHIFT 0
#define _IOC_NRMASK ((1 << _IOC_NRBITS)-1)
#define _IOC_NR(nr)(((nr) >> _IOC_NRSHIFT) & _IOC_NRMASK)
#define DRV_IOCTL_NR(n)_IOC_NR(n)
i.e. expands to an integer constant expression
2009/4/23 Joseph S. Myers :
> On Thu, 23 Apr 2009, Denis Onischenko wrote:
>
>> The following errors appears when I tried to compile linux kernel
>> 2.6.30-rc2 with GCC 4.5:
>>
>>
>> linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: nonconstant array index
>> in initializer
>> linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: (near initialization
>> for 'drm_ioctls')
>> ...
>>
>> compiled code looks like this:
>>
>> static struct drm_ioctl_desc drm_ioctls[] = {
>> DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version, 0),
>> DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
>> ...
>>
>> where DRM_IOCTL_DEF defined as
>>
>> #define DRM_IOCTL_DEF(ioctl, _func, _flags) \
>> [DRM_IOCTL_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags = _flags}
>
> And how is DRM_IOCTL_NR defined? To be used here it should be defined to
> expand to an integer constant expression.
>
>> If it is not a bug, is there a way to disable this conformance rules
>> checking with GCC 4.5 ?
>
> There is no general way. In particular cases the errors can be made into
> pedwarns or pedwarns-if-pedantic if there seems to be a good reason for a
> coding style not letting proper integer constant expressions be used in a
> particular case.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>
Re: GCC 4.5: "nonconstant array index in initializer" error
The minimal code example is following:
extern unsigned int __invalid_size_argument;
#define TYPECHECK(t)( sizeof(t) == sizeof(t[1]) ? sizeof(t) :
__invalid_size_argument )
static int arr[] = {
[TYPECHECK(int)] = 0,
};
int main()
{
return 0;
}
command line is: gcc test.c
GCC 4.5.0 revision 146607 compiles this code with following errors:
test.c:5: error: nonconstant array index in initializer
test.c:5: error: (near initialization for 'arr')
released GCC 4.4.0 compiles without any errors
2009/4/23 Joseph S. Myers :
> On Thu, 23 Apr 2009, Denis Onischenko wrote:
>
>> Thanks for reply!
>>
>> DRM_IOCTL_NR is defined as
>>
>> #define _IOC_NRBITS 8
>>
>> #define _IOC_NRSHIFT 0
>> #define _IOC_NRMASK ((1 << _IOC_NRBITS)-1)
>>
>> #define _IOC_NR(nr) (((nr) >> _IOC_NRSHIFT) & _IOC_NRMASK)
>>
>> #define DRV_IOCTL_NR(n) _IOC_NR(n)
>>
>>
>>
>> i.e. expands to an integer constant expression
>
> How then are its operands (DRM_IOCTL_VERSION, DRM_IOCTL_GET_UNIQUE, etc.)
> defined?
>
> You should send a complete, self-contained, minimal code example that
> reproduces the issue you see, complete with the compilation options used,
> rather than snippets without all the previous declarations they require.
> Your message needs to contain all the information needed to reproduce the
> problem without referring to any external sources.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>
Re: GCC 4.5: "nonconstant array index in initializer" error
Thanks for the patch.
There are another error while building linux kernel with GCC 4.5.0
revision 146771.
The minimal code for reproducing the error looks like:
extern unsigned int __invalid_size_argument;
#define TYPECHECK(t)( sizeof(t) == sizeof(t[1]) ? sizeof(t) :
__invalid_size_argument )
enum {
ENUM_VALUE_NAME = TYPECHECK(int),
};
int main()
{
return 0;
}
The error is following:
test.c:5: error: enumerator value for 'ENUM_VALUE_NAME' is not an
integer constant
GCC 4.4.0 compiles this code without any error.
2009/4/24 Joseph S. Myers :
> On Thu, 23 Apr 2009, Denis Onischenko wrote:
>
>> The minimal code example is following:
>>
>>
>> extern unsigned int __invalid_size_argument;
>> #define TYPECHECK(t) ( sizeof(t) == sizeof(t[1]) ? sizeof(t) :
>> __invalid_size_argument )
>>
>> static int arr[] = {
>> [TYPECHECK(int)] = 0,
>> };
>>
>> int main()
>> {
>> return 0;
>> }
>
> Given this usage in the Linux kernel I've applied this patch to make
> this case into a pedwarn-if-pedantic, as previously done for case
> labels. Bootstrapped with no regressions on i686-pc-linux-gnu.
>
> 2009-04-24 Joseph Myers
>
> * c-typeck.c (set_init_index): Allow array designators that are
> not integer constant expressions with a pedwarn if pedantic.
>
> testsuite:
> 2009-04-24 Joseph Myers
>
> * gcc.dg/array-const-1.c, gcc.dg/array-const-2.c,
> gcc.dg/array-const-3.c: New tests.
>
> Index: gcc/testsuite/gcc.dg/array-const-2.c
> ===
> --- gcc/testsuite/gcc.dg/array-const-2.c (revision 0)
> +++ gcc/testsuite/gcc.dg/array-const-2.c (revision 0)
> @@ -0,0 +1,9 @@
> +/* Test for array designators not integer constant expressions but
> + folding to integer constants (used in Linux kernel,
> + <http://gcc.gnu.org/ml/gcc/2009-04/msg00611.html>). */
> +/* { dg-do compile } */
> +/* { dg-options "-std=gnu99 -pedantic" } */
> +
> +extern int i;
> +int a[] = { [1 ? 1 : i] = 0 }; /* { dg-warning "array index in initializer
> is not an integer constant expression" } */
> +/* { dg-warning "near initialization" "near init" { target *-*-* } 8 } */
> Index: gcc/testsuite/gcc.dg/array-const-1.c
> ===
> --- gcc/testsuite/gcc.dg/array-const-1.c (revision 0)
> +++ gcc/testsuite/gcc.dg/array-const-1.c (revision 0)
> @@ -0,0 +1,8 @@
> +/* Test for array designators not integer constant expressions but
> + folding to integer constants (used in Linux kernel,
> + <http://gcc.gnu.org/ml/gcc/2009-04/msg00611.html>). */
> +/* { dg-do compile } */
> +/* { dg-options "-std=gnu99" } */
> +
> +extern int i;
> +int a[] = { [1 ? 1 : i] = 0 };
> Index: gcc/testsuite/gcc.dg/array-const-3.c
> ===
> --- gcc/testsuite/gcc.dg/array-const-3.c (revision 0)
> +++ gcc/testsuite/gcc.dg/array-const-3.c (revision 0)
> @@ -0,0 +1,9 @@
> +/* Test for array designators not integer constant expressions but
> + folding to integer constants (used in Linux kernel,
> + <http://gcc.gnu.org/ml/gcc/2009-04/msg00611.html>). */
> +/* { dg-do compile } */
> +/* { dg-options "-std=gnu99 -pedantic-errors" } */
> +
> +extern int i;
> +int a[] = { [1 ? 1 : i] = 0 }; /* { dg-error "array index in initializer is
> not an integer constant expression" } */
> +/* { dg-error "near initialization" "near init" { target *-*-* } 8 } */
> Index: gcc/c-typeck.c
> ===
> --- gcc/c-typeck.c (revision 146679)
> +++ gcc/c-typeck.c (working copy)
> @@ -6403,6 +6403,24 @@ set_init_index (tree first, tree last)
> }
>
> if (TREE_CODE (first) != INTEGER_CST)
> + {
> + first = c_fully_fold (first, false, NULL);
> + if (TREE_CODE (first) == INTEGER_CST)
> + pedwarn_init (input_location, OPT_pedantic,
> + "array index in initializer is not "
> + "an integer constant expression");
> + }
> +
> + if (last && TREE_CODE (last) != INTEGER_CST)
> + {
> + last = c_fully_fold (last, false, NULL);
> + if (TREE_CODE (last) == INTEGER_CST)
> + pedwarn_init (input_location, OPT_pedantic,
> + "array index in initializer is not "
> + "an integer constant expression");
> + }
> +
> + if (TREE_CODE (first) != INTEGER_CST)
> error_init ("nonconstant array index in initializer");
> else if (last != 0 && TREE_CODE (last) != INTEGER_CST)
> error_init ("nonconstant array index in initializer");
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>
Re: GCC 4.5: "nonconstant array index in initializer" error
> Is the kernel using this sort of non-integer-constant-expression in > bit-field widths as well? Sizes of file-scope arrays (OK, a special case > for that was added for WINE)? Null pointer constants (that's much more > problematic to add special cases for)? __builtin_choose_expr conditions? > It seems to be making rather a lot of use of an old obscure undocumented > extension. It is possible that the kernel uses this sort of expression in other places. I can not say for sure. At the moment I found only these two.
relative include search path
I have a problem with gcc not finding location for stddef.h include file when it is invoked from directory other than /bin. Output from gcc invocation with -v option contains the following: ignoring nonexistent directory "../lib/gcc..." i.e. gcc is trying to find include files in directory with relative path. So it is works only when working directory is /usr/bin, where gcc is installed. Why gcc looks for headers in directories with relative paths ? I configured gcc with --prefix=/usr. The gcc was built with cross-compiler. Thanks in advance.
