Re: 4.3.0 and 4.3.1 don't build startfiles (crtXXX.o files)
On Sunday 08 June 2008 04:52, Daniel Jacobowitz wrote: > On Sat, Jun 07, 2008 at 11:26:05AM +0200, Denys Vlasenko wrote: > > Seen that 4.3.1 has been released, I tried to build > > i486-linux-uclibc cross-compiler. > > You probably forgot to build libgcc. Are you using 'make all' / 'make > install' or something more specific? I was using "make all-gcc". The complete procedure was as described here: http://busybox.net/~vda/HOWTO/i486-linux-uclibc/HOWTO.txt Tried "make all-gcc all-target" and it didn't build them either. Tried "make all-target-libgcc" amd just "make" and both resulted in: ... make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/.1/usr/src/gcc-4.3.1.obj-i486-linux-uclibc/build-i386-pc-linux-gnu/fixincludes' make[2]: Entering directory `/.1/usr/src/gcc-4.3.1.obj-i486-linux-uclibc/libcpp' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/.1/usr/src/gcc-4.3.1.obj-i486-linux-uclibc/libcpp' make[2]: Entering directory `/.1/usr/src/gcc-4.3.1.obj-i486-linux-uclibc/libdecnumber' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/.1/usr/src/gcc-4.3.1.obj-i486-linux-uclibc/libdecnumber' make[2]: Entering directory `/.1/usr/src/gcc-4.3.1.obj-i486-linux-uclibc/gcc' make[2]: Leaving directory `/.1/usr/src/gcc-4.3.1.obj-i486-linux-uclibc/gcc' Checking multilib configuration for libgcc... make[2]: Entering directory `/.1/usr/src/gcc-4.3.1.obj-i486-linux-uclibc/i486-linux-uclibc/libgcc' # If this is the top-level multilib, build all the other # multilibs. /.1/usr/src/gcc-4.3.1.obj-i486-linux-uclibc/./gcc/xgcc -B/.1/usr/src/gcc-4.3.1.obj-i486-linux-uclibc/./gcc/ -B/usr/app/gcc-4.3.1-i486-linu ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:52:18: error: fenv.h: No such file or directory ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c: In function '__dfp_test_except': ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:64: error: 'FE_INEXACT' undeclared (first use in this function) ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:64: error: (Each undeclared identifier is reported only once ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:64: error: for each function it appears in.) ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:66: error: 'FE_UNDERFLOW' undeclared (first use in this function) ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:68: error: 'FE_OVERFLOW' undeclared (first use in this function) ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:70: error: 'FE_DIVBYZERO' undeclared (first use in this function) ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:72: error: 'FE_INVALID' undeclared (first use in this function) ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c: In function '__dfp_raise_except': ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:81: error: 'FE_INEXACT' undeclared (first use in this function) ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:83: error: 'FE_UNDERFLOW' undeclared (first use in this function) ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:85: error: 'FE_OVERFLOW' undeclared (first use in this function) ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:87: error: 'FE_DIVBYZERO' undeclared (first use in this function) ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:89: error: 'FE_INVALID' undeclared (first use in this function) make[2]: *** [bid_decimal_globals.o] Error 1 make[2]: Leaving directory `/.1/usr/src/gcc-4.3.1.obj-i486-linux-uclibc/i486-linux-uclibc/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/.1/usr/src/gcc-4.3.1.obj-i486-linux-uclibc' make: *** [all] Error 2 > Also check the libgcc configure.host file for your triplet. I don't understand you here. What should I check? (Target is "i486-linux-uclibc"). -- vda
Re: 4.3.0 and 4.3.1 don't build startfiles (crtXXX.o files)
On Sun, 8 Jun 2008, Denys Vlasenko wrote: > ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:52:18: error: > fenv.h: No such file or directory Decimal floating point requires . The DPD code only requires the header, not any of the actual functions it declares; it looks like the BID code requires the functions (which uClibc does provide on x86, though not on most targets). So either configure uClibc with UCLIBC_HAS_FENV enabled, or configure GCC with --disable-decimal-float. -- Joseph S. Myers [EMAIL PROTECTED]
Re: 4.3.0 and 4.3.1 don't build startfiles (crtXXX.o files)
On Sunday 08 June 2008 13:50, Joseph S. Myers wrote: > On Sun, 8 Jun 2008, Denys Vlasenko wrote: > > > ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:52:18: error: > > fenv.h: No such file or directory > > Decimal floating point requires . The DPD code only requires the > header, not any of the actual functions it declares; it looks like the BID > code requires the functions (which uClibc does provide on x86, though not > on most targets). So either configure uClibc with UCLIBC_HAS_FENV > enabled, I don't understand you. As far as I know, toolchain is built in this order: 1. binutils 2. C compiler 3. libc and after that one can finally cross-compile stuff for the selected target. Your suggestion does not make sense, because the problem I describe happens on step 2. By this time, libc did not enter the picture yet in any shape or form. In other words: it doesn't matter how I configure uclibc, because gcc should be built before uclibc can be built. If I misunderstand something, please let me know. > or configure GCC with --disable-decimal-float. Will try, thanks. -- vda
Re: 4.3.0 and 4.3.1 don't build startfiles (crtXXX.o files)
> As far as I know, toolchain is built in this order: > > 1. binutils > 2. C compiler > 3. libc No. That usually only works if you already have the toolchain installed. In which case ordering is irelevant, you can just build whichever component you want to update. A full bootstrap process looks more like: 1) Binutils 2) Whatever bits of compiler are required to produce... 3) libc headers 4) A basic C compiler+libgcc that is sufficient to build... 5) libc 6) A full compiler+runtime, c++, fortran, etc. The exact details of steps 2-4 are rather murky (see also crostool). gcc needs libc headers to build its runtime libraries, and the C library needs a working gcc to build, so you've got a bootstrapping problem. The trick is getting the right set of partial builds/configure options to break this cyclic dependency. Toplevel libgcc actually makes this easier to achieve, though there may still be some work to do. The failures you're seeing probably mean your previous toolchains were misconfigured, and worked mainly by chance. Paul
Re: 4.3.0 and 4.3.1 don't build startfiles (crtXXX.o files)
On Sunday 08 June 2008 16:27, Paul Brook wrote: > > As far as I know, toolchain is built in this order: > > > > 1. binutils > > 2. C compiler > > 3. libc > > No. > > That usually only works if you already have the toolchain installed. In which > case ordering is irelevant, you can just build whichever component you want > to update. > > A full bootstrap process looks more like: > > 1) Binutils > 2) Whatever bits of compiler are required to produce... > 3) libc headers > 4) A basic C compiler+libgcc that is sufficient to build... > 5) libc > 6) A full compiler+runtime, c++, fortran, etc. > > The exact details of steps 2-4 are rather murky (see also crostool). gcc > needs libc headers to build its runtime libraries, and the C library needs a > working gcc to build, so you've got a bootstrapping problem. The trick is > getting the right set of partial builds/configure options to break this > cyclic dependency. > > Toplevel libgcc actually makes this easier to achieve, though there may still > be some work to do. The failures you're seeing probably mean your previous > toolchains were misconfigured, and worked mainly by chance. Thanks. I added --disable-decimal-float --disable-libgomp to configure. Just --disable-decimal-float threw a warning that libgomp needs threading. Why it didn't complain before I have no idea. Then, running "make all-target-libgcc" built them, but I finally settled for just "make" - it didn't error out. Then, I have to do "make install" instead of "make install-gcc" in order for these files to be copied to install tree. Whew. Cross-compiling continues to be a bit of black magic. -- vda
climits: unsafe #defines?
Accudentally noticed this in my freshly built 4.3.1 tree in climits C++ header file: #ifndef LLONG_MIN #define LLONG_MIN -__LONG_LONG_MAX__ - 1 #endif #ifndef LLONG_MAX #define LLONG_MAX __LONG_LONG_MAX__ #endif #ifndef ULLONG_MAX #define ULLONG_MAX __LONG_LONG_MAX__ * 2ULL + 1 #endif Think what will happen in this code: if (n < ULLONG_MAX / 20)... -- vda
Question about is_call_dce_candidate()
David, I've converted the cdce pass to the tuples branch and had a question about is_call_dce_candidate(). Currently, the function checks flag_tree_builtin_call_dce, but that seems unnecessary. It's already checked by the gate function. Is there any other reason why this check should be there? Thanks. Diego.
Re: 4.3.0 and 4.3.1 don't build startfiles (crtXXX.o files)
Then, running "make all-target-libgcc" built them, but I finally settled for just "make" - it didn't error out. Yes, the advantage of Paul's suggested process are not only that the installations are reproducible and always use the complete feature set of the underlying libc (that's the big part), but also that "make" just works and you are more shielded from changes in the build system. Paolo
Re: 4.3.0 and 4.3.1 don't build startfiles (crtXXX.o files)
On Sunday 08 June 2008 22:41, Paolo Bonzini wrote: > > > Then, running "make all-target-libgcc" built them, but I finally settled > > for just "make" - it didn't error out. > > Yes, the advantage of Paul's suggested process are not only that the > installations are reproducible and always use the complete feature set > of the underlying libc (that's the big part), but also that "make" just > works and you are more shielded from changes in the build system. What is Paul's suggested process? I just reread his post again and it contains no suggestions what to do, it was useful in other way: he explained where my understanding of build process is incorrect: > > As far as I know, toolchain is built in this order: > > > > 1. binutils > > 2. C compiler > > 3. libc > > No. > > That usually only works if you already have the toolchain installed. In which > case ordering is irelevant, you can just build whichever component you want > to update. > > A full bootstrap process looks more like: > > 1) Binutils > 2) Whatever bits of compiler are required to produce... > 3) libc headers > 4) A basic C compiler+libgcc that is sufficient to build... > 5) libc > 6) A full compiler+runtime, c++, fortran, etc. If someone is willing to expand on the above and explain what exactly do I need to do in step 2, in step 3, in step 4, that would be helpful. -- vda
Re: 4.3.0 and 4.3.1 don't build startfiles (crtXXX.o files)
1) Binutils 2) Whatever bits of compiler are required to produce... 3) libc headers 4) A basic C compiler+libgcc that is sufficient to build... 5) libc 6) A full compiler+runtime, c++, fortran, etc. If someone is willing to expand on the above and explain what exactly do I need to do in step 2, in step 3, in step 4, that would be helpful. You already made step 2. Step 3 depends on your C library, I don't know the details for uclibc. Step 4 is the same as step 2, but you will need less --disable-* options. Paolo
Re: 4.3.0 and 4.3.1 don't build startfiles (crtXXX.o files)
On Sun, 8 Jun 2008, Denys Vlasenko wrote: > What is Paul's suggested process? I just reread his post again > and it contains no suggestions what to do, it was useful in > other way: he explained where my understanding of build process > is incorrect: The procedure for EGLIBC is documented in detail: http://www.eglibc.org/cgi-bin/viewcvs.cgi/*checkout*/trunk/libc/EGLIBC.cross-building (as that's written for GCC 4.1, you'll need to add --disable-decimal-float when building the first compiler with 4.3). Much the same also works for uClibc; you install the headers and crt*.o files from uClibc between building the first and second compilers. However, it may be easier to use existing scripts such as crosstool to automate the process, provided you use those scripts with versions of the tools they support. -- Joseph S. Myers [EMAIL PROTECTED]
[tuples] Merge from [EMAIL PROTECTED]
This brings in everything from trunk just before the new OMP3 changes. Jakub, you can do the omp3 merge now. David, this converts tree-call-cdce.c to use tuples. The only change is the removal of the flag that I mentioned earlier, if this is something you think it shouldn't be merged into mainline, please let me know. Diego.
