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] |
"Xiaogeng (Shawn) Jin" wrote: > > Kai, > > Thanks a lot for your suggestions. Actually before starting building the > cross compiler, I read several HOWTOs but no one mentioned that the > prefixes for gcc and glibc are different. Unfornately the current > CrossGCC FAQ still doesn't explain the problem clearly. Why don't you > write a FAQ? :) Actually when talking about building glibc for the native Linux-configurations, the prefixes are the same, ie. it must normally be the '/usr' for both GCC and glibc. So the stuff will be installed into '/usr/bin', '/usr/lib' and '/usr/include'. And also the '/lib' will be used. I only remembered the 'cross-glibc'-case... But for cross-tools the meaning for the '$prefix' is different and the equivalent of '/usr' is the '$prefix/$target' for glibc, while it is the '$prefix' for GCC. Some instructions ask one to build glibc as if it would be for the native system, and to use some special option with 'make install' so that the native glibc will not be overwritten by the alien glibc (and the whole system not becoming non-working). But this may cause the script 'libc.so' (it really is a text-file, 'ld-script', not a real shared library) having values for the native install. I remember the 'Mini-FAQ' for 'powerpc-linux-gnu' at 'http://www.penguinppc.org' suggesting this and the idea was that the absolute pathnames to the cross-libs were put into the produced tools, ie. into the executables aimed to run on the target system ('gencat', 'getconf', 'ldd' etc.). If the produced glibc with the produced executables will finally be installed also to the target system (at least the shared libs), this will be sane. The option '-dynamic-linker' in the GCC-specs tries to set the path/filename for the 'program interpreter' to be right at run-time, but the glibc-build sets this to follow the given '$prefix' in configure. So the following output from a glibc-build-produced executable has false info about the place of the 'program interpreter' : ----------------------------- clip ------------------------------------------- H:\usr\local\ppc-linux-gnu\bin-glibc>..\bin\readelf -l gencat Elf file type is EXEC (Executable file) Entry point 0x10000a98 There are 6 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x10000034 0x10000034 0x000e0 0x000e0 R E 0x4 INTERP 0x000114 0x10000114 0x10000114 0x00025 0x00025 R 0x1 [Requesting program interpreter: /usr/local/ppc-linux-gnu/lib/ld.so.1] LOAD 0x000000 0x10000000 0x10000000 0x03364 0x03364 R E 0x10000 LOAD 0x003368 0x10013368 0x10013368 0x000f0 0x0033c RWE 0x10000 DYNAMIC 0x00338c 0x1001338c 0x1001338c 0x000a0 0x000a0 RW 0x4 NOTE 0x000140 0x10000140 0x10000140 0x00020 0x00020 R 0x10 ----------------------------- clip ------------------------------------------- while a 'normal' cross-built executable has it right: ----------------------------- clip ------------------------------------------- Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x10000034 0x10000034 0x000e0 0x000e0 R E 0x4 INTERP 0x000114 0x10000114 0x10000114 0x0000d 0x0000d R 0x1 [Requesting program interpreter: /lib/ld.so.1] LOAD 0x000000 0x10000000 0x10000000 0x013e0 0x013e0 R E 0x10000 LOAD 0x0013e0 0x100113e0 0x100113e0 0x0012c 0x001d8 RWE 0x10000 DYNAMIC 0x00143c 0x1001143c 0x1001143c 0x000a8 0x000a8 RW 0x4 NOTE 0x000130 0x10000130 0x10000130 0x00020 0x00020 R 0x10 ----------------------------- clip ------------------------------------------- So I will take the issue "so that the native glibc will not be overwritten by the alien glibc", when using the normal 'make install' so important, that I suggest using the '--prefix=$prefix_gcc/$target', although the produced executables then will be wrong for the native install... One has no use for these executables in the cross install when only producing 'normal' executables for the target system, not new run-time glibcs for it... About using a preinstalled C-library during the 'bootstrap-GCC' build: Generally in both the GCC and glibc configurations the 'native' case is the default and the 'cross' case is the rare exception, when talking about the 'system' targets. So for any "GCC for Linux", whether it is native or not, the preinstalled C-library is expected to exist and the headers, startups etc. already being there. Before the 'Open Source' systems, with their sources also being available, came, the only C-libraries for the 'system targets' were their proprietary ones, like those for Solaris2, Irix, SVR4s, Ultrix, HP-UX etc. That the C-library sources are now available for Linux, FreeBSD etc. hasn't changed the situation much, the Solaris2 (older ones) etc. still don't have their C-library sources available... And most native builders don't even think removing their preinstalled glibc and GCC before starting to build a new GCC and glibc (which action would make the job impossible -- no compiler for any compiles...) The "Installation / Cross-Compiler" in the "Using and Porting the GNU Compiler Collection (GCC)", ie. the 'GCC-manual' coming in source-format (texinfo) with the GCC-sources and built into GNU 'info'-format during the build, doesn't talk anything about building the C-library during the GCC-build, only about preinstalling the prebuilt target stuff... But after GCC is ready, one can use it for anything, like updating the existing C-library. So using 'some prebuilt C-library' during the GCC-build doesn't disable anyone building the C-library from its sources later... But it makes the GCC-build very easy if compared with trying everything from the sources.... The preinstalled C-library binaries can be considered (and should be...) being same kind of tools as the native C-compiler and the target binutils. In any case the preinstalled glibc doesn't need to be the final C-library in the cross-toolchain, although using a prebuilt glibc from a RedHat-distribution is most compatible with that RedHat-target and so on... If not knowing the target very well, and RedHats, SuSEs, Mandrakes etc. can all be possible targets, a 'generic' glibc from the FSF sources can be a good solution. Although some kind of 'binary compatability' between them is surely true, there can be cases when a executable linked against 'RedHat-glibc-2.2.4' doesn't work with the run-time 'glibc-2.2.4' in SuSE or Mandrake... Or this happening between the Linux/PPC-distributions (SuSE, YellowDog, Linux-PPC,...) For the 'embedded' targets the situation is different... No prebuilt C-libraries are normally available for them, but this doesn't matter because only the target headers are needed for compiling and archiving the static 'libgcc.a' (no shared 'libgcc_s.so' will be built needing the 'crti.o' and 'crtn.o' in the link phase). And the stuff in 'newlib-1.10.0/newlib/libc/include' can easily be copied into the final '$prefix/$target/include' with a single 'cp -r' command. Ok, installing a prebuilt glibc from the native environment into the cross environment and doing this vice versa later with the cross-built new glibc, lets one to practice with the different symlinks etc. If installing a 'native glibc' into the cross-environment succeeds, doing it vice versa later should succeed too... BTW, if someone tells needing "a cross-compiler for a Linux/XYZ system", should we believe this really being the case ? Or will the person really need "cross-tools for producing the whole Linux-system on the cross-environment" ? Two totally different cases and if not telling which one is in question, there will be misunderstandings... At least I have believed what the people have claimed, and it has always been the first case. > I noticed some things which might be problems. After the bootstrap gcc > is installed, I found two programs (cpp and gcov) don't have the prefix > (powerpc-linux-) no matter if the --program-prefix is set. Is it a > possible bug of the make files for gcc? Looks like being a bug... If these will be installed into the '$prefix/bin' with their base names, they will overwrite the ones already there. So you can try to report this as a bug... My habit is to use my own install-template scripts instead of the 'make install' because there has been several bugs like that you mentioned. One bug which has also been there is : - the 'libiberty.a', 'libstdc++.a' and 'libstdc++.so' were installed into the '$prefix/$target/lib' as if these were version-independent libraries and a newer one or an older one could safely replace the one already there... The 'right' place for the 'libiberty.a', 'libstdc++.*' etc. version-dependent stuff would be the '$prefix/lib/gcc-lib/$target/$version'. Maybe only the 'libstdc++.a.2.10.0' etc. version-marked stuff will now be installed into the '$prefix/$target/lib', but the 'version' ('2.10.0' or something) normally doesn't tell to which GCC-version it belongs and if one has three or more GCCs for the same target (e.g. 'egcs-1.1.2, 'gcc-2.95.3', 'gcc-3.0.4', 'gcc-3.1'), it is more clear if their 'libstdc++'-stuff is where all the other version-dependent stuff is... The '$prefix/lib/gcc-lib/$target/$version' is the first place to search for the target 'programs' and 'libraries' for the 'gcc-driver', just see with the '-print-search-dirs'... If you look with './cpp -v' what the installed 'cpp' gives, it definitely has its 'hard-wired' search directoried for headers, so it is target-dependent. Using the 'cpp' alone may however be quite rare and the installed GCCs will find their own ones ('cpp0' now) from the already mentioned '$prefix/lib/gcc-lib/$target/$version'... For which purpose the separate 'cpp' will now be needed is still unclear to me... The 'gcov' can be target-independent, so using the base name for it may be motivated. At least I couldn't find any difference in the sizes of the 'gcov's produced for different targets but from the same GCC-sources... > Then the configure process shows that the c-preprocessor used to build > glibc is the native cpp (/lib/cpp). I guess it should be the one > (/opt/xdev/ppc/bin/cpp). Where it tries to use 'cpp' directly without invoking it via the 'powerpc-linux-gcc' ? I haven't noticed this happening. Anyway it looks like being a bug... 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] |