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: glibc vs. newlib in build processes (was:BUG IN DYNAMIC LINKER ld.so)


Kai:


> 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...

[snip]

Look, I'm not very happy about the state of things either, but I'm not
ranting about it.  I don't LIKE using newlib when building a linux
crosscompiler from scratch, but I haven't found an alternative.

What is needed is a way to get target-specific headers out of glibc
cleanly, without having a crosscompiler installed first.

Since it all appears to be so easy for you, try this: go get a copy of
a recent Linux disto, say Red Hat 7.1, and install it on a VIRGIN PC.
No upgrades, wipe the whole thing and start from scratch.  Then give
me a canned procedure for building powerpc-linux that somehow pulls
"suitable headers and libraries" out of thin air.  The world will
thank you.  I will thank you.  CrossGCC will thank you.  Hell, I bet
even the glibc guys will thank you!

> 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.

Sure, but they leave the mechanism by which you do so as an exercise
to the user--- as they should, I suppose, since it really isn't their
problem.  The trouble is, glibc kind of does the same thing--- almost
presumes that target-specific headers exist *before* you build glibc,
as far as I can tell.  This isn't the case when bringing up a
crossdevelopment environment, even one that's already supported by
GCC et al.

And don't bolt to the "just download it from xyz" defense.  If I can't
build it from scratch, it's obfuscation.  Being able to build *from
scratch* is precisely why I prefer GNU over all other options.

> The best result and the least amount of iterations will be achieved
> when all the stuff is 'suitable for the target' in the beginning...

Sure.  Just give me the procedure to follow, and I'll add it to the FAQ.

> Meanwhile the :
> 
>      cp -p -r newlib/libc/include $prefix/$target
>
> with the newlib headers works easily...

In a sense, this is what gcc's --with-headers configure option does.

> 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....

Sure it is--- when you *already* have target-specific glibc's of the
same version, which (a) isn't the case in any Cywgin or Solaris
installation, and (b) is an unreasonable requirement everywhere else.

> 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 won't go nearly so far as to say it's "stupid".  In fact, I am certain
that there is some perfectly reasonable explanation for it--- I just
don't know what it is, because CrossGCC isn't the typical "market" for
glibc, and I don't understand how their typical customers think.

>  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...

Until we understand glibc better, it's all we've got.


b.g.
-- 
Bill Gatliff
bgat@open-widgets.com

------
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]