Re: Why is building a cross compiler "out-of-the-box" always broken?
Thanks for reminding me to ping that patch. Could you try moving this case statement + case "$target" in + i[[3456]]86-*-elf* | i[[3456]]86-*-coff*) + libgloss_dir=i386 + ;; + m68hc11-*-* | m6811-*-* | m68hc12-*-* | m6812-*-*) + libgloss_dir=m68hc11 + ;; above in another "case $target in" statement? Thanks, Paolo
[Tuples]Is struct gimple_statement_lable shoud be a member of union gimple_statement_d?
hello , Diego Novillo and everyone in gcc mailist. I am a Chinese developer and learing the project tuples(represent gimple as tuple). When i translanting the document 《Tuples Representation for GIMPLE》 into Chinese, i found that the struct gimple_statement_lable is not a member of union gimple_statement_d. I assume it maybe a careless mistake. Is that truth? Thank you very much. -- 编译器：http://hi.baidu.com/compiler/
compiler chain on AIX
All, I was wondering - what's the current status of the gcc compiler chain on AIX? I need to build a bunch of open source tools on AIX, but I see from the following site: http://www.ibm.com/developerworks/aix/library/au-gnu.html 'You cannot use the GNU linker on AIX as this will cause incorrectly linked binaries. By default, the AIX linker is used when using GCC on AIX. You should only use the default AIX linker.' which would be fine if the AIX linker works, but I'm getting segmentation faults when compiling perl out of the box, using the gcc-4.1.0 compiler provided.. I'm wondering if its the compiler, the linker, or both.. Anyways, if anybody is interested in helping tracking this down, I'd be more than happy to provide compilation logs, etc. Is there someone who maintains the AIX port? Ed (ps - if I can't get ld to work with gcc, my guess is that it's going to be very painful to compile the freeware packages on AIX that are needed, considering that half of them expect gnu ld flags, not native ones... so I'm hoping that someone has gotten gnu ld to work out there. )
Re: Why is building a cross compiler "out-of-the-box" always broken?
OK, let me recap as I understand the discussion up to now, realizing that this is the gcc list we can really only hope to fix things, if needed, by making changes to the gcc project. Other project will have other priorities. It sounds like the consensus is that bootstrapping a cross-compiler still requires the use of inhibit_libc and for a Linux target *should* work like this. And, apparently is does work like this for some people for some targets, just not for everyone for everything. 1. Configure the Linux kernel and "make headers_install". 2. Configure and make binutils using the headers produced in step 1. 3. Configure and make a minimal gcc cross-compiler for the target by getting configure to set inhibit_libc and disabling any complicating or conflicting options such as threads and multilib not strictly needed to build the minimal compiler. This compiler should not be generally used because of the restrictions placed on it during the build process. 4. Use the minimal cross-compiler produced in step 3 to configure glibc and do "make install-headers" to get glibc headers. At this point you should be able to delete the minimal cross-compiler, it's job has been done. 5. Make distclean and then configure, make, and install a normal gcc cross-compiler for the target using the glibc headers produced in step 4. 6. Make distclean and then configure, make, and install the complete glibc header and libraries etc. for the target. 7. Use the tools produced in steps 5 and 6 to do whatever cross-compiling project you need them for. Now for some thoughts about this. I assume we are working with current releases of the kernel and tool chain. There are lots of problems with various older combinations of things, let's not go there please right now. 1. Seems to be a good reliable source of sanitized headers for recent kernels. I know of no problems with the current release. 2. Seems to build and work out-of-the-box using the headers from step 1. I know of no problems with current release. 3. Figuring out the correct combination of --with-newlib, --with-sysroot, and --with-headers (or --without, or =no etc.) to get inhibit_libc set and then figuring out which of the myriad of --with-this-that-and-the-other options can or must be disabled to get a functional minimal compiler is a real pain in the neck. Further more, the make file may try (and fail) to make additional things like crt0 in EXTRA_PARTS= which require the use of "make -k" and/or manual copying of the needed bits and pieces. It does not always work and the failures seem to be in different places on different targets. Maybe the make files need to be modified some depending on the configure setting of inhibit_libc? If this is *supposed* to work, would it be worth while having a --force-bootstrap or some such option so that configure could force inhibit_libc and then short circuit lots of configuration stuff and disable everything appropriate on a per-target basis so we can reliably generate the minimal comiler needed for the next step? With that, additional places in the source that really need inhibit_libc special casing would be much clearer. Right now it's a question of "wtf caused that to die?", since bootstrapping a cross-compiler is such a black art to most people. Also, should the inhibit_libc hack also disable things like the unwind support that requires kernel headers? That not scrictly libc, but --without-headers sort of assume neither are present. It would also be nice if there were a clear statement about what needs to be where in the headers and/or sysroot directory structures. Or, should be just require some sort of combined tree build in this case? In which case it would be nice if there were a clear statement about what needs to be copied or symlinked from where to where to make it work. I'm a bit out of my depth since I have *not* gotten it to work for many of the cases I have tried, yet. It's not that I'm unwilling to try and contribute patches, but I'd like to know where we are heading, please. Some people advocate combining steps 3,4,5 by either cribbing a set of headers from someone elses sysroot, cobbling them together by hand, or by fooling glibc configure in to producing them without having a minimal cross compiler. They build their cross-compiler using these headers and then they proceed to step 6. That's great if you are only working with one, common, target where you can expect to find someone to crib from or you have better luck than I did trying to understand and fool glibc configure. In any case that leaves us as the mercy of changes to the glibc package, and the glibc maintainers can reasonably assume the existance of a compiler and may use that compiler to check things like sizeof(long double) etc. so it's fragile at best to rely on. (BTW - why do we have both -m128bit-long-double and -mlong-double-128 options for different targets?)
Re: Why is building a cross compiler "out-of-the-box" always broken?
4. Use the minimal cross-compiler produced in step 3 to configure glibc and do "make install-headers" to get glibc headers. At this point you should be able to delete the minimal cross-compiler, it's job has been done. 5. Make distclean and then configure, make, and install a normal gcc cross-compiler for the target using the glibc headers produced in step 4. 6. Make distclean and then configure, make, and install the complete glibc header and libraries etc. for the target. Sometimes you need to repeat 4,5,6 (but using the full toolchain produced in the previous run, not the minimal one obviously). It's a good sanity check anyway ;-) 1. Seems to be a good reliable source of sanitized headers for recent kernels. I know of no problems with the current release. There still are problems so you're advised to use the separate kernel headers package instead. 2. Seems to build and work out-of-the-box using the headers from step 1. I know of no problems with current release. Binutils doesn't need any kernel headers AFAIK. 3. Figuring out the correct combination of --with-newlib, --with-sysroot, and --with-headers (or --without, or =no etc.) to get inhibit_libc set and then figuring out which of the myriad of --with-this-that-and-the-other options can or must be disabled to get a functional minimal compiler is a real pain in the neck. configure --verbose --help I posted the full set you currently need. Further more, the make file may try (and fail) to make additional things like crt0 in EXTRA_PARTS= Don't use --with-newlib if you don't want to build newlib. Right now it's a question of "wtf caused that to die?" Yeah, it's a fun voyage, isn't it :-) Also, should the inhibit_libc hack also disable things like the unwind support that requires kernel headers? That not scrictly libc, but --without-headers sort of assume neither are present. Yeah, that's a good point. I use --enable-sjlj-exceptions to avoid the need for those headers, but that's not enough for building ia64-linux (it _is_ enough for all other Linux targets). Some people advocate combining steps 3,4,5 by either cribbing a set of headers from someone elses sysroot, That's the "normal" procedure for building a cross-toolchain, yes. or by fooling glibc configure in to producing them without having a minimal cross compiler. You should only need this if you're porting to a new target. And then this all is the least of your troubles ;-) However, it's probably not viable for someone trying to build 20 or so tools chains so they can check for kernel build failure tree wide etc. That's exactly what I'm doing. Feel free to take a look at my scripts: git://git.infradead.org/~segher/buildall.git or browse it at: http://git.infradead.org/?p=users/segher/buildall.git And besides, it would sure be nice if gcc would build a cross-compiler out-of-the-box if there is no problem with some other part of the tool chain. That does not seem to be the case for all targets at this point. Bugs happen :-) So, that's the situation as I see it. How should things work in an ideal world and where do we go from here? Or, are other people happy enough with the current ecosystem and think nothing needs to change? It would be nice if things were a bit easier; maybe a single configure flag "--from-scratch" or something like that. Someone needs to create that though. Segher
Register Numbers during machine dependent reorg?
Hello Everyone, I am currently working with MIPS port of gcc-4.0.2 by using segmented register files (like a multi-core approach). This is what i would like to do: I would like to assign instructions whose destination registers are between 0 to 7 to core 1, 8-15 to core 2 and so forth. I would like some advice about doing this efficiently in GCC? Can I do this in machine dependent reorganization phase? When the compiler reaches this phase, does it know the register numbers already? I am OK with modifying the main-stream GCC files, the whole change doesn't have to be in the files of config/mips directory. Any help is highly appreciated. Thanking You, Yours Sincerely, Balaji V. Iyer. PS. Please CC me in your response since I am not a subscriber of this mailing list. Balaji V. Iyer PhD Student, Center for Efficient, Secure and Reliable Computing Department of Electrical and Computer Engineering North Carolina State University.
Re: Why is building a cross compiler "out-of-the-box" always broken?
Thanks, I git cloned buildall and it sure looks simple (now that you have made it work) :-! Although, that combination of options was not exactly obvious at first glance. Time to re-read all the config --help stuff. I'll try it on my build system at work tomorrow and see what bites me next. I expect that I am having old nightmares from when I was trying to do this under Solaris and made it harder than I needed to on a Linux host. Apparently, I'm not the only one who got lead astray though. Thank again - Steve Segher Boessenkool wrote: 4. Use the minimal cross-compiler produced in step 3 to configure glibc and do "make install-headers" to get glibc headers. At this point you should be able to delete the minimal cross-compiler, it's job has been done. 5. Make distclean and then configure, make, and install a normal gcc cross-compiler for the target using the glibc headers produced in step 4. 6. Make distclean and then configure, make, and install the complete glibc header and libraries etc. for the target. Sometimes you need to repeat 4,5,6 (but using the full toolchain produced in the previous run, not the minimal one obviously). It's a good sanity check anyway ;-) 1. Seems to be a good reliable source of sanitized headers for recent kernels. I know of no problems with the current release. There still are problems so you're advised to use the separate kernel headers package instead. 2. Seems to build and work out-of-the-box using the headers from step 1. I know of no problems with current release. Binutils doesn't need any kernel headers AFAIK. 3. Figuring out the correct combination of --with-newlib, --with-sysroot, and --with-headers (or --without, or =no etc.) to get inhibit_libc set and then figuring out which of the myriad of --with-this-that-and-the-other options can or must be disabled to get a functional minimal compiler is a real pain in the neck. configure --verbose --help I posted the full set you currently need. Further more, the make file may try (and fail) to make additional things like crt0 in EXTRA_PARTS= Don't use --with-newlib if you don't want to build newlib. Right now it's a question of "wtf caused that to die?" Yeah, it's a fun voyage, isn't it :-) Also, should the inhibit_libc hack also disable things like the unwind support that requires kernel headers? That not scrictly libc, but --without-headers sort of assume neither are present. Yeah, that's a good point. I use --enable-sjlj-exceptions to avoid the need for those headers, but that's not enough for building ia64-linux (it _is_ enough for all other Linux targets). Some people advocate combining steps 3,4,5 by either cribbing a set of headers from someone elses sysroot, That's the "normal" procedure for building a cross-toolchain, yes. or by fooling glibc configure in to producing them without having a minimal cross compiler. You should only need this if you're porting to a new target. And then this all is the least of your troubles ;-) However, it's probably not viable for someone trying to build 20 or so tools chains so they can check for kernel build failure tree wide etc. That's exactly what I'm doing. Feel free to take a look at my scripts: git://git.infradead.org/~segher/buildall.git or browse it at: http://git.infradead.org/?p=users/segher/buildall.git And besides, it would sure be nice if gcc would build a cross-compiler out-of-the-box if there is no problem with some other part of the tool chain. That does not seem to be the case for all targets at this point. Bugs happen :-) So, that's the situation as I see it. How should things work in an ideal world and where do we go from here? Or, are other people happy enough with the current ecosystem and think nothing needs to change? It would be nice if things were a bit easier; maybe a single configure flag "--from-scratch" or something like that. Someone needs to create that though. Segher
GCC cpp to mips! Help Please!
Hello My name is Derrick Washington and and brand new to GCC, and I need some information on how to convert c++ code to files which I can load into the ram on my MIPs processor. I have been looking over the manuels and they are of no help and I need help on this one. I have attached the c++ code that I want to conver to hex files to dowload into the Ram on my MIPs processor. Basically I am trying to go from my cpp file to a instruction file in hex and a data file also in hex that I an download into the ram and run on the processor, and I have no idea on how to go about doing that. Thanks in advance for any help provided. _ More photos, more messages, more storageget 2GB with Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507 GCD.cpp Description: Binary data
Re: Why is building a cross compiler "out-of-the-box" always broken?
Thanks, I git cloned buildall and it sure looks simple (now that you have made it work) :-! Good to see it is useful to more people than just me :-) Although, that combination of options was not exactly obvious at first glance. Heh. Almost all of it is just "disable what we don't need". OTOH, that's not how I ended up with those options: I added one every time something broke. I'll try it on my build system at work tomorrow and see what bites me next. What target(s) are you building? I expect that I am having old nightmares from when I was trying to do this under Solaris and made it harder than I needed to on a Linux host. Apparently, I'm not the only one who got lead astray though. The manual explicitly says you need to have target headers. With all those --disable-XXX and especially --enable-sjlj-exceptions it all works fine without, though. Let me know how it goes, Segher
