Re: gcc-2.95.3 for powerpc-linux

[Kai Ruottu <kai dot ruottu at luukku dot com>]

"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