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] |
Michael: > Since we are building cross-GCC for a number of targets, we want > to build each target in exactly the same way, not with a different > recipe for each target. For the most part, we are able to do this. Until there is more standardization between ports, a consistent recipe won't exist. But honestly, the variations so far have been pretty simple. It hasn't seemed like a matrix problem so far, to use your term. I think a lot of people's problems in building are actually with build/host machine configuration issues, not the build process itself. My build script does little to help in this department, short of fixing the obvious things like having write access to the installation directory, having the tools in the path during building, and getting --prefix and --with-local-prefix set consistently. > I have built GCC using Cygwin in the past, but not recently, so I'm > not current on the differences with build on pc-linux. I'm preparing to attack that problem myself-- I'm getting a Cygwin setup here shortly (I'm all-Linux at the moment). > One problem I see with the matrix approach (one entry for each > host/target combination) is that the descriptions diverge. > Differences between targets get described as if they are SOP, rather > than undesirable, and after a while a bug description begins to read > as if it is a requirement. A lot of the differences between builds for different targets are how the header files must be configured. The arm-linux port needs headers of a certain flavor, powerpc-linux and powerpc-eabi another, and so forth. One thing that would help, I think, now that I've built for so many different targets in the last two weeks, is to be able to build a core gcc that DIDN'T build libgcc1 and libgcc2. Such a compiler could build libraries, but wouldn't be able to build standalone executables because it would lack all the nifty stuff that those two libs contain. libgcc1 and libgcc2 are where a lot of the differences seem to be creeping in, and all of them get "fixed" once you have good target-specific headers. You can get headers even if all you can build are libraries. Ergo, a truly "core" gcc wouldn't need libgcc1 and libgcc2, I don't think, because all it would need to be able to do is build runtime libs like glibc and newlib to get the headers; with the headers in place, you could then build a complete gcc. Just my $0.02. 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] |