Configure diffs vs Linux version #16
Comments
|
They do have quite a few additional options specified. I do periodically look though them when they release new versions, sometimes it's necessary to get them to compile. The path stuff is pretty irrelevant. I think I have mostly the same stuff in terms of enabling/disabling functionality (aside from maybe LTO, which I don't think I build enough of the dependencies to match). They do some things that modify the default GCC behavior for optimization levels for some statistics, but I'm not actually familiar with exactly what that's doing, so I've not included it. Then they're also giving it a few specifics about the host's stdc++ library, perhaps to use static versions that they're including to make it more easily redistributable. So, I think the only really substantive changes that I might consider including that I haven't are their special spec definitions which change the optimized code output from GCCs defaults, but those don't look like they affect code? The major differences between their options and the ones I've set are for Newlib where I've told it to build so that it optimizes for code size and to select code sections that use less code space potentially at the cost of speed (there are ifdefs on a number of things where either someone has manually unrolled loops, inserted assembler or done other things that are faster, but larger, and the flags set tell it to prefer the smaller versions). I'll consider matching theirs a little more closely when I update to the latest sources, but the differences for the GCC build in the special spec options actually make it less like generic gcc. My inclination is only to add things when I have a reason for them :-) |
well, it depends on your objective. I first thought that your project is a source build for the missing CodeSourcery Mac OS X toolchain. however, since your project is called 'arm-eabi-toolchain', you probably target your own toolchain, incidentally based on CodeSourcery sources. this is fine, but when you work in a multi-platform environment, it is very important that all versions of the toolchains on all platforms generate exactly (well, more or less) the same code, otherwise testing becomes a nightmare. you partly solved the multi-platform issue by making the Makefile run on Linux too, but this leaves the Windows platform uncovered. If you are not interested in maintaining a CodeSourcery compatible toolchain, then I'll try to maintain my script to patch your Makefile to bring it closer to the Linux/Windows versions of CodeSourcery. another option would be to add a configuration switch to the build, to decide either the toolchain is compatible with CodeSourcery, or it has the special features you require.
I fully understand this :-) Liviu |
|
On Jan 18, 2012, at 3:27, Liviu [email protected] wrote:
My original idea was a mixture of filling the lack of a Mac build of CodeSourcery and to enable some tweaks for newlib.
True, Though for our project we actually work with a variety of gcc builds some with and without the newlib build flag tweaks, the main differences we see though for approximately the same version of toolchain components is code size. Where we have encountered bugs it has usually been between varying component ages and patch levels. In general we've tried to target the project to be buildable with more than one toolchain version and configuration, but it hasn't been a huge headache. Actually, finding that it works with one compiler and not another can be useful for finding bugs.
I have zero experience trying to build it on windows. If someone has made it work, I'm happy to include that information in the instructions and/or modify things a bit for that platform.
Well there's basically only one line of major difference in configuration options for newlib in the 2011.09 branch so adding a switch for this should be easy. I'll include this in a commit today along with a comment about it in the README.
|
in fact my point was exactly opposite, instead of having to deal with aligning the Windows build with the two existing builds (Linux/Mac), I would prefer to use the original CodeSourcery versions and only align the Mac version to them.
great, thank you.
then I'll give it another try in 2-3 days. GitHub question: can I subscribe to some kind of automatic notification service so that I know when you release new versions of the Makefile? Liviu |
Right, I understood. I was just explaining where I was coming from (which was also actually using vanilla GCC sources before I found the CodeSourcery ones). One thing of note on this front is that although I would hope that matching all those flags will result in the same code generation across platforms (let me know if you notice it doesn't, when we're intentionally matching flags), but they also build many of the build dependencies from scratch as well in their own version so I'd expect there might be some variation due to building against varying installed versions of libraries and using different system compilers. I would hope that this would just affect things like performance and memory usage and that generated code would be the same, but I've never tried to match them exactly then check. Also, the GCC build system does have some weird quirks (like how, for example, the avr32-toolchain sporadically does or doesn't build on the first try even with PROCS=1). And I've noticed that for Atmel's own builds of gcc that their 32-bit and 64-bit builds of GCC don't always seem to do the same thing... (never tracked that one down) All in all, for what you're trying to do, at least matching build options/flags should cut down on the variables that affect code generation, and we can go from there. I would agree that being able to provide a version that matches CS for Linux & Win on the Mac would be valuable and quite nice.
I've put something in now that provides a few different ways to do this, nominally it should work to do something like this:
I haven't tried building with these different options, but I'd be a little surprised if the other ones worked and these don't.
You can use the "watch" button for the project, but you won't get emails as a result of that. It will just show up in your dashboard on github. I could also set up the hooks for the project to fire out commit messages to a mailing list or just a set of email addresses. I'll see if any of the hooks that github now works with might provide some easy way to subscribe to commits without having to set up something more complicated like this. You should certainly be able to get messages when the state of these issues change unless you've unchecked the relevant options in your settings: https://github.com/account/notifications |
|
I checked the differences between our MATCH_CS build and the Mentor/CS Linux 2011.09-69 build and here they are:
Additional switches they have:
Do you know details about these switches? Would it be complicated to add them on the MATCH_CS branch? That would (hopefully) make us fully compatible with their build. Liviu |
|
Regarding the first two: Regarding the others, the GCC configuration guide provides some details on that: http://gcc.gnu.org/install/configure.html
Tells GCC to consider dir as the root of a tree that contains a (subset of) the root filesystem of the target operating system.
Tells GCC to consider dir as the system root (see --with-sysroot) while building target libraries, instead of the directory specified with --with-sysroot. Both of these have to do with where it will look for libraries and headers during the build and then when the resulting compiler builds for the target. There's some information here: http://gcc.gnu.org/ml/gcc-help/2011-12/msg00035.html I'm not completely sure what's best here, especially given this: I'll have to take a look at their full build script again (the .sh file in the src tarball), but I believe that part of the reason that they do this is because they're basically building all their dependencies (ppl, cloog, gmp, make etc..) at build time and then using that rather than system libraries and headers.
They're just pointing to the libraries that they've built as dependencies. I don't set these since the location will vary depending on platform and build version, and it does a decent job of picking them up itself if you just have them installed. As far as what these libraries are for: they enable the ability to set a few relatively recently added optimizations to gcc that started with the Graphite branch: http://gcc.gnu.org/wiki/Graphite which does loop interchanging optimizations among a few other things: http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html (-ftree-loop-linear, -floop-interchange, -floop-block, -fgraphite-identity, -floop-parallelize-all). None of these are part of the standard -O[1,2,3,s] as far as I can tell. You have to ask for them specifically.
Used for static linking with PPL, if you're using a shared library version of PPL it's indicated as not needed. I generally don't build with the graphite features since I've not wanted to bother with these optimizations, they're not included in any of the default sets, and it requires extra build dependencies. The above flag is only really useful I think if you're trying to do static linking so that you can redistribute the binary on systems that might not have a system PPL library.
This I might enable, it's supposed to provide warnings when it pulls a library or header from /usr instead of the cross compiler. For the platforms on which I'm building this (non-arm) I can't think of any good reason why it would ever try to link against system libraries, but if it would warn about headers, it might be of some value. I've never had a problem with this, though. I suspect the only case where it might start looking elsewhere for these is if you try to include a header or library not found in built newlib/gcc and then it starts to have to try looking elsewhere.
In theory this should prevent the need for pre-making the $PREFIX/bin directory and adding things to the path. This is supposed to make GCC use tools in that path. I have tried this before and it hasn't quite worked correctly for me. I can switch it back on and I'll try and see if I can ditch the pregeneration and path adding, but I'm not sure it will work. To sum this up: Some of it puts restrictions on the build environment to look for what is needed in specific places and potentially provide warnings if it looks outside of these areas. I have used some of these related flags before and might turn them back on, but I've never really noticed them making a difference so long as what is needed for building is done in the correct order and required libraries are found in their expected locations. I'll turn these on in a branch first and if they don't break things I can enable them in all builds. (so that would be the sysroot, poison system directories and build time tools options) Some of these I think are more useful when you're building the way that codesourcery is to ship a whole distribution of tools in an installer, and some of them might in some cases make it more likely to warn or bail when the user does something they shouldn't. Some of it is for enabling the graphite optimization features which one has to specifically ask for at compile time and require some extra libraries during the build. I think this would be pretty easy on linux since there are probably packages for them. They will get picked up automatically on that platform if available. On OS X, PPL is in homebrew, CLooG is not AFAIK, so it adds another dependency for an optimization feature that I have never switched on. Depending on how easy or painful these libraries are to build I'm not strongly inclined to go out of my way to add it since even GCC doesn't include these optimizations in any of their default levels. |
|
There's now a branch that uses with-build-time-tools & with-sysroot (with-build-sysroot doesn't really make sense since that's for defining the sysroot for the toolchain being used to build the toolchain.. and we're using system libraries and compilers). It now seems to work OK without pre-setting PATH or pre-generating the destination bin directory which is nice, however with-sysroot did require one ugly-ish hack to make it work that I didn't like which was that I needed to make a usr/include under $PREFIX/$TARGET otherwise the last stage of building the compiler failed (complaining about not being able to find headers in that directory.. apparently it just wants the directory and doesn't mind the headers being not present). I'll probably merge that. Also, it looks like there's an open request to include cloog in Homebrew so that might not be too painful to support either. |
|
I tested the 25ac742 release and it compiles fine in my environment. Adding options that require new Homebrew packages should't be a problem, my script automatically installs them, I just have to add the names to a list. Liviu |
I installed the Linux version of 2011.03-42 and I noticed a lot of definitions used during the configure step.
Did you check them? Maybe they are not relevant, but I would be more confident when porting from one architecture to the other if the compilers would have been configured similarly.
Liviu
ilg@ubuntu:
/Developer$ arm-none-eabi-g++ -v/Developer$Using built-in specs.
COLLECT_GCC=arm-none-eabi-g++
COLLECT_LTO_WRAPPER=/home/ilg/Developer/Cross/arm-2011.03/bin/../libexec/gcc/arm-none-eabi/4.5.2/lto-wrapper
Target: arm-none-eabi
Configured with: /scratch/janisjo/arm-eabi-lite/src/gcc-4.5-2011.03/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs --with-gnu-as --with-gnu-ld --with-specs='%{save-temps: -fverbose-asm} -D__CS_SOURCERYGXX_MAJ__=2011 -D__CS_SOURCERYGXX_MIN__=3 -D__CS_SOURCERYGXX_REV__=42 %{O2:%{!fno-remove-local-statics: -fremove-local-statics}} %{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}' --enable-languages=c,c++ --disable-shared --enable-lto --with-newlib --with-pkgversion='Sourcery G++ Lite 2011.03-42' --with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls --prefix=/opt/codesourcery --with-headers=yes --with-sysroot=/opt/codesourcery/arm-none-eabi --with-build-sysroot=/scratch/janisjo/arm-eabi-lite/install/arm-none-eabi --with-gmp=/scratch/janisjo/arm-eabi-lite/obj/host-libs-2011.03-42-arm-none-eabi-i686-pc-linux-gnu/usr --with-mpfr=/scratch/janisjo/arm-eabi-lite/obj/host-libs-2011.03-42-arm-none-eabi-i686-pc-linux-gnu/usr --with-mpc=/scratch/janisjo/arm-eabi-lite/obj/host-libs-2011.03-42-arm-none-eabi-i686-pc-linux-gnu/usr --with-ppl=/scratch/janisjo/arm-eabi-lite/obj/host-libs-2011.03-42-arm-none-eabi-i686-pc-linux-gnu/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-cloog=/scratch/janisjo/arm-eabi-lite/obj/host-libs-2011.03-42-arm-none-eabi-i686-pc-linux-gnu/usr --with-libelf=/scratch/janisjo/arm-eabi-lite/obj/host-libs-2011.03-42-arm-none-eabi-i686-pc-linux-gnu/usr --disable-libgomp --enable-poison-system-directories --with-build-time-tools=/scratch/janisjo/arm-eabi-lite/install/arm-none-eabi/bin --with-build-time-tools=/scratch/janisjo/arm-eabi-lite/install/arm-none-eabi/bin
Thread model: single
gcc version 4.5.2 (Sourcery G++ Lite 2011.03-42)
ilg@ubuntu:
The text was updated successfully, but these errors were encountered: