This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
I wish I'd seen this before I updated Bill Gatliff's scripts to gcc-3.3; it looks like you ran into the same sort of things I did.
------------------- Begin nick's recipe -------------------------------- The underlined term "from scratch" above refers to the fact that absolutely no sparc cross-development tools, no pre-compiled sparc system libraries, and no native sparc development environment, of any kind, are assumed already available. Apart from the host-native (ix86) tools, everything else will be built from sources. This is a very common case if the cross-toolchain is to be used for embedded-systems development.
Please could someone explain in simple words what benefits this method brings if compared to the "easy as a pie"-method for novices:
2. Get a bootstrap-glibc for the target, for instance from the Debian archives, the glibc-2.3.1-17 seemed to be the most up-to-date there, for the 'sparc-linux' too.
5. Build glibc from sources using the new complete GCC (if absolutely necessary)
The result from this is a cross-toolchain built totally from virgin sources, no prebuilt components are used in it (but used as tools during the build -- using a hammer to produce a hammer should not be any worse than produce a hammer with a stone-ax). Generally all the native or cross-tools for other hosts on the build platform should get the same kind of 'traceability' consideration as the sources... If one starts to track down the known bugs in the gcc-2.96 in RedHat 7.x or in the gcc-3.x in RH 8.0 and 9.0, and tries to solve what these could cause into the built binutils and GCC, when using these in the build, things can become quite difficult...
So my point was to ask about any documented cases where using a prebuilt glibc in the 'from scratch' case had caused more troubles than doing several iterations with the sources only... It sounds weird that anyone building GCC natively and using the old RedHat, Debian, SuSE etc. provided glibc during the build, and then updating glibc with the new GCC somehow are more probable to get a buggy GCC than those cross-GCC builders building from sources. If this really is the case, all native GCCs should be built without needing anything from '/usr/include', '/lib' or '/usr/lib' during the build (only the old GCC used to produce the compiler binaries could use them, not the new 'xgcc', 'cpp0', 'cc1' etc. binaries...). This far the host-GCC, host-binutils and the host C library are considered to be 'traceable' and 'reliable' to work as the bootstrap tools but these 'from scratch' methods in the cross-GCC world try to put the host C libraries being somehow in suspect...
Ok, somehow I suspect that the Debian 'glibc-2.3.1-17' could be more bug-free than a 'glibc-2.3.2' built by oneself from the FSF-sources, without any target specific extra patches, if looking at some specific target. The '-17' could mean that the Debian people have tried to fix at least something... Furthermore the Debian stuff is small, the shared libs plus the static libs/startups/headers in the 'dev' package are totally only about 6 Mbytes, sodownloading them takes only half-an-hour on a 56 kbits/s modem line, much less time than building glibc from sources would take on a slow PC... Although I had glibc-2.2.4 built for 'mipsel-linux', and gcc-3.2.3 built with it, updating GCC to 3.3 and glibc to the 2.3-level, would be much easier if downloading the glibc-2.3.1-17 from Debian and building gcc-3.3 with it, than building glibc-2.3.2 with gcc-3.2.3 and then gcc-3.3 with glibc-2.3.2 and possibly glibc-2.3.2 again with gcc-3.3...
Okeydokey, here are short instructions for installing the bootstrap-glibc from the Debian packages (and honouring the work of the Debian people, not urinating upon their work, as the "very common case", by Nick, could be):
The following CPU architectures are supported with prebuilt glibc-2.1.3, 2.2.5 or 2.3.1 on the Debian archives:
alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, s390x, sparc, sparc64
The packages for the runtime shared libs and the 'dev' one could provide the minimal set if aiming to update glibc after the GCC build. So for instance the following packages would provide the bootstrap-glibc for Linux/PPC:
libc6-dev_2.3.1-17_powerpc.deb 2874 KB 20.4.2003 22:17:00 libc6_2.3.1-17_powerpc.deb 3817 KB 20.4.2003 22:17:00
will unpack the package into the current directory. Then using 'tar xvzf data.tar.gz' for the data itself will unpack the stuff into 'lib', 'usr/lib', 'usr/include' etc. in the current directory. Please note that the name is always the same 'data.tar.gz' in every package, so handling them one by one with 'ar' and 'tar' will be required. After unpacking all the needed packages, the 'lib', 'usr' etc. stuff can be moved into the final chosen $prefix/$target/lib and $prefix/$target/include.
The following script fixes the symlinks between the original 'native' glibc files:
---------------- clip ----------------------------------- ln -f -s libanl.so.1 libanl.so ln -f -s libBrokenLocale.so.1 libBrokenLocale.so ln -f -s libcrypt.so.1 libcrypt.so ln -f -s libdl.so.2 libdl.so ln -f -s libm.so.6 libm.so ln -f -s libnsl.so.1 libnsl.so ln -f -s libnss_compat.so.2 libnss_compat.so ln -f -s libnss_dns.so.2 libnss_dns.so ln -f -s libnss_files.so.2 libnss_files.so ln -f -s libnss_hesiod.so.2 libnss_hesiod.so ln -f -s libnss_nisplus.so.2 libnss_nisplus.so ln -f -s libnss_nis.so.2 libnss_nis.so ln -f -s libpthread.so.0 libpthread.so ln -f -s libresolv.so.2 libresolv.so ln -f -s librt.so.1 librt.so ln -f -s libutil.so.1 libutil.so ---------------- clip -----------------------------------
The 'libc.so' script in the libraries should be edited to be something like (ie. the absolute paths stripped away):
---------------- clip ----------------------------------- /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ GROUP ( libc.so.6 libc_nonshared.a ) ---------------- clip -----------------------------------
I tried the 'hppa-linux' target with the Debian glibc-2.3.1-17 and got the toolchain without any problems...
Those who are absolute dummies can also consider downloading a prebuilt embedded Linux-target toolchain. The Wolfgang Denk's company site, 'Denx', could be one place to find toolchains for PowerPC, ARM and MIPS targets, their "Embedded Linux Development Kit" (ELDK) provides these:
If needing a car, one could consider buying a car or finding out where one can find one as free, not necessarily seeing building the car being the only choice...
------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |