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] |
"Cameron, Steve" wrote: > > Kai Ruottu wrote: > > > What kind of religion or attitude disables you to copy a prebuilt > > glibc from the target machine or from some other Linux/PPC system > > or from a Linux/PPC distribution on the net (SuSE PPC, > > YellowDog,...) ? > > Then build GCC using it and then possibly updating glibc from its > > sources? If one wants to build everything from sources, 'start from > > scratch', this is the easy way. > > No attitude or religion. It's for an embedded system. > I tried with newlib because of this page: > http://penguinppc.org/embedded/cross-compiling/ > which references "--with-newlib", and also this page: > http://shorterlink.com/?TNTVV7 and others like it, > which claimed to solve the specific problem I was seeing. Perhaps the idea about not using anything else than the sources is one kind of religion, or misunderstanding the target libraries being host-dependent because GCC and binutils for the target are, but anyhow using newlib in the bootstrap process sounds a little weird... With gcc-2.95.3 things are still easy, only target headers are needed, but gcc-3.x requires the C-library with its startups for linking the shared 'libgcc_s.so'. Then all kind of tricks will be needed. Not any rocket science, but who cares to teach these tricks all the time or to try to find new ones, when doing this thing mimicking the native Linux situation is much more easy... One may need tricks when building one's first GCC+glibc combination, but documenting the tricks and expecting others to do the same 'reinventing the wheel' is a bad joke. I did my stuff because downloading those big (usually 10 M + 10 M RPMs) packages wasn't quick enough and building a newer generic glibc was my aim... And I somehow expected to be able to build them without asking any help. One needs the tricks only when building the first toolchain for a Linux/CPU, and not if a glibc for the Linux/CPU is available. I can stand the pain, but don't expect others to share it with me... All the people having rapid net connections are free to choose the easier way. Some new/old tricks here: The 'newlib as the workaround-library where to find some headers' isn't the only possibility if not wanting to use a prebuilt glibc during the GCC-build... With gcc-2.95.3 one could simply copy the native Linux-headers from the '/usr/include' and copy the CPU-dependent headers from the 'sysdeps/*/powerpc/bits' and the 'sysdeps/*/powerpc/sys' in the glibc- sources into the '$prefix/$target/include/bits' and '$prefix/$target/include/sys' for the target and then get a working 'libgcc.a' at the first try and 'make all-gcc' to succeed... Copying the 'native Linux-headers' in a Solaris2 etc. build platforms of course isn't possible... Or the most simple solution would be to not build 'libgcc.a' at all in the bootstrap phase to get only a C-compiler. The 'make all-gcc' tries to build this, but computers are stupid, so it is also possible to use a 'touch libgcc.a' in the '$build/gcc' subdir after the libgcc-build needs some target headers and crashes. So letting 'make' be happy with the produced empty file... Maybe a 'touch libgcc2.ready' will be needed to 'stamp' the situation, or using the same for 'stmp-multilib' because it tells when all the needed 'libgcc.a's are built for targets needing multiple 'libgcc.a's (some Linux'es may try this)... So again the build to get a GCC may 'succeed', now WITHOUT any headers... I have used the 'copy the glibc headers from a Linux distribution using the same glibc-version', ie. building glibc for some other CPU which has GCC ready, not for the native system, and then copying the headers from the installation into another for another CPU and then replacing the CPU- specific headers with ones for the another CPU... Hmmm, one possibility would be to search for a prebuilt GCC for the host and target combination, for instance Linux/MIPS has many, Linux/SH too, probably Linux/PPC too (RedHat EDK had RedHat 6.x-to-Linux/PPC and this should work under 7.x. A prebuilt glibc-2.1.2 too) and then use it to build glibc from sources... Getting a 'bootstrap-GCC' from the net is quite normal when no native 'cc' exists (Solaris2'es). All the FAQs in the net are only opinions from different people, there are always many ways to do the same thing and one may prefer something to something else... I got my opininion about using always the right stuff after putting liquid aimed for hand-washing into a dish-washer machine because the right liquid bottle was empty... And then got a reall mess in the kitchen and quite a lot nagging afterwards... As it was told to me, no sane person could use wrong liquid there. But who would expect an engineer being sane ? The only other person who I know having done the same, was also an engineer... Meanwhile I have never heard anyone putting 92-octane gasoline into a car needing 99... How on earth people know that this could cause a mess or some big noise ? Ok, using the right stuff everywhere unless surely knowing that the 'wrong stuff' will work too, is my recommendation... For instance my experience says that a brandy made elsewhere in France, not in Cognac or in Armagnac, cannot very easily be recognized to not be real cognac or real armagnac, or that the taste is worse. Many people cannot taste the difference, so suggesting them to get VSOP brandy instead of VSOP cognac may be fully possible... The "Hitchikers Guide to the Galaxy" recommends real armagnac, but if one cannot taste the difference... Recognizing a bourbon from a scotch, although they both are 'whiskey's, however isn't hard... Things may get very complicated if one builds GCC with newlib, gets a garbage-libgcc.a, then builds a glibc which scans the produced 'libgcc.a', links against it when producing 'libc-2.2.x.so', 'libm-2.2.x.so' etc. Then also the produced glibc binaries are garbage, only the headers should be ok. Then one must build GCC again to get a working 'libgcc.a' (but not necessarily a working 'libgcc_s.so' because the '.so's in glibc were broken) and finally build glibc again to get working glibc binaries... And then GCC once again... Maybe one must do once iteration again to check the results... To much work and a real mess for all the lazy people who would rather use their time for trying to decide whether an armagnac tastes better than a cognac... Ok, producing GCC uses only the build/host headers, but producing 'libgcc.a', 'libiberty.a', 'libstdc++.a' etc. uses the target headers. One cannot use mostly wrong headers for these... "A Linux is a Linux, although one would fry it (embedded) in butter", or something... AFAIK all the syscalls etc. are the same for the same CPU. The kernel may vary but all the tools around the kernel can be the same. The IBM-PC age teached that it is not enough to have MS-DOS in the 'PC', also the HW must be identical with the 'original PC'. The 'Wang-PC', 'HP-150', 'NCR-PC', 'Nokia-MM2' etc. were sad examples about 'non-compatible-PC's using MS-DOS... Compaq however was one of the first to understand the importance of 'hardware compatability' in the PC-business... I remember the 'comp' meaning both 'compatability' and 'compactness', the first 'sewing-machine'-like PC perhaps wouldn't be very 'compact' now... There shouldn't be any HW-dependency in the Linux-business, an old non-compatible 'Altos/386' bought with Xenix/386 should be capable to run Linux/x86 with all its tools, if drivers for its HW would exist in the kernel. In the PowerPC-area no HW-compatability needs should either exist. So the compiler tools should produce code for Linux, not for some specific HW, and the compilers and glibc should be HW-independent... So any prebuilt glibc as the C-library for Linux would be suitable to start with, before one knows what special things would be needed in the kernel. Or some new feature existing in the C-library... Ther may be some dependency between the kernel version (2.4.x now) and the glibc version (2.2.x needed for 2.4.x ?), so although GCC could be built against glibc-2.1.x, updating glibc later may be necessary. But rebuilding GCC against/with glibc-2.2.x probably not. Having some glibc helps the GCC-build and when the 'Catch-22' situation never is a joy, one really doesn't want to struggle with it with every GCC-update. When one gets glibc built for something, it is not sane to throw it away before the update. Having glibc already built earlier is the 'normal' situation, not that it doesn't yet exist. Or people build GCC and glibc only once in their life. My 'glibc-2.2.4' may be third or fourth reincarnation after the first '2.0.6' or something for Linux/PPC... It never came into my mind to throw away the existing glibc before a GCC-update, how weird when all the FAQs expect every GCC-builder to do just this. If I have misunderstood all this, please someone correct me. > Also, I didn't have a usable target machine or a distribution, > it's an IBM walnut 405GB, a pretty bare bones system: processor, > memory, network, serial port, nothing more. Hence the need > for a cross compiler. Basically the sources and binaries for the MontaVista (www.mvista.com) 'embedded Linux' distributions should exist, the RedHat's EDK ('Embedded Development Kit') for embedded x86 and PPC was withdrawn. I mention these if someone wishes the prebuilt stuff being 'embedded oriented'... It really doesn't need to be (first). The plain-vanilla Linux kernel sources should support all kind of HW, but maybe MontaVista has more drivers for more HW... > Anyway, I did get the cross compiler to build finally, but it sounds > like I should probably build it again with glibc. Yes, you will need the preinstalled glibc-headers for the target libs. > What I was doing wrong (well, _one_ thing I was doing wrong) > was trying to build gcc from inside the source directory, I > didn't realize you weren't supposed to do that. > (on account of the fact that I'm an idiot) Maybe you didn't do anything definitely wrong... In your case the tools probably will be used to produce Linux for a new HW, not Linux apps for some Linux-distribution. Producing 'apps' is easier, but producing 'Linux' means that the produced 'glibc' is partly an 'app', the shared libs will be installed into target system, also the utilities produced during the glibc-build... So glibc must be produced for the native environment, not for the cross-environment. The 'penguinppc' instructions about using the '--prefix=/usr' for glibc, but being very careful during install are all sane... Although the instructions for the GCC-build maybe aren't... Practicing with copying a native glibc from the native environment into the cross-environment, before doing this vice versa, may be useful... So this would be one more reason for using a prebuilt glibc from some native environment using Linux/PPC there... Small things like '/lib/ld-linux.so.2' in Linux/x86 being replaced with '/lib/ld.so.1' in Linux/PPC, but some time one must learn all these... Cheers, Kai ------ 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] |