This is the mail archive of the crossgcc@sourceware.org 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] |
Kristoffer Ericson wrote:
Greetings,
I started experimenting with the prefix settings once i started having crt1.o
issues. I appreciate the information although a simple "use --prefix=/usr"
would have been just fine.
You'll just have to get used to Kai. He's very opinionated and verbose,
As the matter of fact I would like to see a native GCC for something like 'sh3-linux-gnu' being quite similar with any cross-GCC for this target !
But the Linux people long time ago decided that on Linux there is a imaginary proprietary native 'cc' whose install directories for headers and libraries the native GCC must mimic ! Also the Cygwin and MinGW people have decided similarly... I have never understood why these decisions were so obligatory.
Nothing should force a GCC for an Unix-like system to use just the '/usr/include', '/lib' and '/usr/lib'. A GCC for Linux could have used anything and as long as the existing sources tried to use these directories directly, instead of letting GCC to find any stuff automagically, these 'native directories' could have been only links or symlinks to where the stuff really is. Them being in a cross-GCC like install scheme should have been the natural choice.
If Windoze requires its DLLs normally in '\windows\system32' and Linux requires its '.so's in '/lib' and '/usr/lib', so what this has to do with the link-time issues, other than also these shared libs must be seen by the linker ? Getting them symlinked into the '$prefix/$target/lib' or something cannot be any rocket science
For the people who mainly cross-produce stuff, a cross-GCC for their (not so quick) Linux target system should be more familiar. Just as a cross-GCC for MinGW sounds as the natural choice when needing to produce something for the Windoze host. If some day one must produce the native GCC, producing it being different from the familiar GCC, doesn't sound sane at all. And then one can get from the native GCC :
So generally Kristoffer is free to produce any kind of "unnormal" native GCC... My point only was to say that maybe practicing with a "normal" native GCC first could be useful... Not that I in any way would prefer the native install scheme !
The clue for producing a native GCC as a cross-GCC like GCC is using different name for the host and target, for instance using
(if the 'sh3' means the same as 'sh3eb') could enable this. In the x86 world a 'i586' is different from 'i686' and these things are easy...
------ 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] |