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]

Re: (fwd) BUG IN DYNAMIC LINKER ld.so:


bgat@open-widgets.com wrote:

> Kai:
>
> >>  I have never understood why using the 'cp' command to copy and the 'find'
> >> command to search things is so hard that the desperate choice of using the
> >> newlib-headers for the bootstrap-compiler has been recommended in some FAQs...
>
> >> My advice is to use the real headers stuff from glibc...
>
> Because glibc is complicated enough as it is, and using newlib helps
> remove the doubt that comes with a broken build cobbled together from
> hand-placed headers.

 And please use 95-octane gasoline in a car needing the 99-octane...
They
are both just gasoline, so what's the problem?  Or use Fairy in your
disk
washer, not the special one needed for it, it doesn't matter when they
both
are just for the same purpose...

 Very weird suggestions indeed...  Now I don't wonder where people get
their
ideas of using newlib everywhere, using newlib or glibc for the Solaris2
target  while its proprietary headers and libs are available freely from
Sun...

 The GCC manual clearly says that a cross-compiler needs "suitable
headers
and libraries" for the target in question.  So  the 'powerpc-aix*' 
targets need
AIX headers and libraries, 'i386-sco*' targets need the SCO headers and
libs,
'sparc-solaris2*' targets need the Sparc/Solaris2 headers and libs and
so on.

 Only in some special cases any unsuitable headers and libraries can be
used.
And then the builder must know what this will cause to the result and
that
then there are pure garbage as result...

 Building the 'libgcc_s.so' for Linux targets in gcc-3.0 tries to scan
the
'libc.so.6' and building glibc needs a working 'libgcc.a'... So I don't
see
any easier route to a working GCC & glibc than using the right target
stuff,
not any cheap replacement...  The best result and the least amount of
iterations
will be achieved when all the stuff is 'suitable for the target' in the
beginning...

 Perhaps there already is/should be a 'make preinstall' choice in the
glibc
sources, to install the glibc-headers into their proper places before
building
GCC.  Then the right stuff could be used while building GCC.  Anyway I
haven't
seen any possibility existing to automatize this, and if it does exist,
someone
else could have found it. Meanwhile the :

     cp -p -r newlib/libc/include $prefix/$target

with the newlib headers works easily...

> Yes, it burns a ton of (possibly needless) CPU cycles, but when something
>  breaks, you don't have to worry so much about if it is something you
> screwed up with your 'cp' and 'find' procedure.

 Copying just the same version glibc-headers from some other
glibc-installation
and then doing the

   .../bits/*.h'   -->  $prefix/$target/include/bits

and the

  .../sys/*.h    -->  $prefix/$target/include/sys

copies from the target-specific subdirs in the glibc-sources sounds
trivial
enough for me. Anyway a 'make preinstall' possibility for preinstalling
all
the glibc headers for the target would be preferred, the 'some other
glibc-
installation' perhaps is not available, at least for the same
glibc-version....

 Or there should be those '#ifdef __mips__' , '#ifdef __arm__' etc. in
the
glibc-headers to enable them being 'generic' for all the supported Linux
targets (supported in the specific glibc-version).  Why the
glibc-headers
for 'arm-linux' differ from those for 'i686-linux' and these differ from
those for 'powerpc-linux' sounds really stupid...  I really don't mean
that the glibc-headers should be just like those for Windoze, including
all
the Win9x/NT/2k/CE opsys-support and all the SH/MIPS/Alpha/PowerPC/ARM
architecture-support into the same headers... Only the '.../bits' and
'.../sys'
stuff, now separate, could easily be combined into common headers, the
kernel's '.../asm'-stuff may remain separate as it doesn't belong to
glibc...

> I'm starting on updates to CrossGCC FAQ next week, now that I've
> almost caught up from being away from the office for two weeks.  I'm
> hoping to answer some of the questions like this that keep coming up
> over and over again.

 The problem with the current CrossGCC FAQ has been just this idea
about newlib being a 'medicine for all-purposes' or a CRC-spray which
fixes everything and lets people go on.... So people have started with
it in every possible case, whether the target is Solaris2, SCO, AIX,
HPUX,
SGI Irix, Linux or anything else.  Or alternatively thought that glibc
can be used instead of the proprietary headers and libs for the
target...

 Ok, I sometimes ported glibc-1.09 for SCO3.2 and newlib too and they
both could be used to write simple (non-network, non-X11) apps for
the Unix SVR3.2/SCO world, for the iBCS2-mode of Linux (to port SCO
apps like the Oracle ones to Linux), so it is possible to use either
newlib or glibc for those 'system' targets. But this needs the necessary
'porting' first....

 So the most important thing in the CrossGCC FAQ should be to get
people understand that C-headers and libraries are specific for the
target.
No 'generic headers and libs' do exist, the native headers cannot be
used
for any other targets and so on... (Of course there are exceptions, that
who
knows what he/she is doing, is free to do anything....).

 Just as is wrong to use  the cheaper 95-octane  gasoline for a car
needing
the 99-octane one, using newlib for Linux is basically wrong.  Anyone
who is
going to build tools for Linux, MUST know that Linux uses glibc as its
C-library, not newlib... Anyone who is going to build tools for
Solaris2,
MUST know that Solaris2 uses its proprietary stuff from Sun, not newlib
or
glibc... And so on. Where on earth all the knowledge about these things
has
disappeared?

 And of course the first thing in the FAQ should be the: "If you haven't
yet
got the GCC manual, please get it now. And if you have got the manual,
please
immediately read the "Installation / Cross-Compiler" from it !".

 Or alternatively the FAQ must teach all those basic things about how a
C-compiler works, what are the C-headers, what are the C-libs, what are
startups and so on.... Quite a lot people asking something here haven't
any kind of clue when the famous "C compiler cannot create executables"
comes, they have never used the '-v' option for GCC (to see the 'cpp',
'cc1',
'as' and 'ld' phases during the compile and to see the options given to
the 'phases'), have never used the GCC's '--help'-option, or used the
'-print-search-dirs' to see the GCC search paths, and so on. All these
options are assumed every newbie to already know.

 Ok, the GCC-manual is not the best "C for the Dummies"-book, but some
of
those commercial C-compiler manuals are really good in telling the basic
things, so downloading the PDF-manuals for Hitachi, Mitsubishi, Motorola
etc. chip-makers own C/C++ tools may be a good start. The basic ideas
about
linker scripts, startups etc. are tried to explain in them. For the
GCC/embed
work the RedHat's 'embed.pdf' in the GNUPro-manuals-collection is a must
(www.redhat.com/support/manuals).

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]