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