(I thought there was a specific cross-gcc list?
I'm using gcc-help@ since my mail isn't high quality,
rather than too annoy gcc@.)
I've been playing around with building gcc/binutils/gmp/mpfr
native, cross, and "cross to native", trying various combinations.
Ultimately I have a lot of stuff working and at the end, doesn't
seems so difficult.
But..
-- sharing between multiple toolsets to reduce build time --
When building multiple toolsets, like:
"cygwin" = i686-pc-cygwin
"solaris" = sparc-sun-solaris2.10
build=cygwin host=cygwin target=cygwin
build=cygwin host=cygwin target=solaris
build=cygwin host=solaris target=solaris
With -disable-multilib -disable-bootstrap in a combined tree,
it'd be nice to only build libiberty, libgmp, libmpfr,
each twice only, libbfd, libopcodes only two or three times.
Instead you get many more -- well, only three of gmp/mpfr
and maybe only three bfd/opcodes, but many more libiberty.
I understand. Stuff doesn't get "installed" and the three builds
therefore have no knowledge of and sharing with each other.
So each one builds cygwin if it needs, solaris if it needs.
I will try -enable-commonbfdlib and -enable-install-libiberty
and see if they cut down the redundant compiling.
If not, I can probably copy/link the outputs from some builds
into the trees of others, and then like -disable-libiberty,
-disable-opcodes, -disable-bfd. But I'd rather not hack things
myself but use supported methods.
"install" is really more than I want though.
Granted, "save away some build outputs, such as .a files
but not .o files" == "install"
and I can use DESTDIR to ghettoize it to somewhere other
than "installed".
Then again "copy around some files" == "install"..
And I can re-split gmp/mpfr out of the tree I guess.
Then I can just manually build them twice.
-- crazy multi-target toolsets --
It'd also be super duper nifty if in place of
-enable-targets=all
I could say:
-enable-targets=one,two,three,four,whatever
(or if a broad but finite definition of "all" could be found, unlikely)
And if these were even just one gcc.exe and one ld.exe instead
instead of one gcc.exe and n cc1.exe, ld.exe, as.exe.
I realize that is asking a lot.
Really I want DoEverything.exe that compiles multiple source
files to multiple .o files all at once (skipping as).
-- static vs. shared, many angles thereof --
Also, let's say I have installed static and shared gmp/mpfr.
I should be able to pick and chose what is static and what is shared.
Like -enable-static=gmp -enable-shared=mpfr,gmp -use-static=gmp,mpfr
would build a static gmp and shared of both, but use static of both.
"Use" as in gcc/ld would use static.
What gcc's output uses is another knob. -enable makes them both available.
The default should be configurable. Probably at "install" time and later
via "specs" and not just earlier at "configuration" time. Maybe that's
already how it works though. I haven't really looked at specs files.
I guess ultimately there's a whole big matrix.
What if, for some reason, I want gcc to use static of some things but ld shared of others?
I don't really want that, it's just useless hypothetical.
Worse, instead of "enable", you probably want build, install, and use-local.
I guess this is already handled?
use-local and install both imply build
enable == install (and build)
-with-build-foo or -with-foo=dir == use-local (and build)
I have to look more into that.
The are some wierd unuseful combinations you can't get, like build but don't use-local,
some wierd thing where you want to link against the previous version but build and
install a new one.
?
Having shared .so/.dll files that are only shared by cc1.exe cc1plus.exe, might be nice
though, like /usr/libexec/gcc/4.3.1/i686-pc-cygwin/gmp.dll.
I have some other vague criticisms and bug reports regarding cross builds but this is my clearest.
ok, one other.
It seems nice to able to give short noncanonical platforms names, like sparc-solaris.
However:
1) Somewhere I found an inconsistency where canonical and noncanonical had to match,
so I stick with canonical.
2) libstd++ even wants a version number, so sparc-sun-solaris isn't even precise enough,
I had to use sparc-sun-solaris2.10. Perhaps sparc-solaris2.10 would work here but
I didn't try that.
There also seems to be some inconsistencies between sys-root, sys-include and //include.
That I saw building djgpp-target cygwin-host stuff though, not solaris.
For solaris I am using -with-sysroot and maybe -with-build-sysroot.
Oh, one problem I think I saw.
You can often just say "configure -with-sysroot" and the default /usr/local/target/sys-root
is used, nice to have defaults. However somewhere I saw a command line later
fail that mentiond -sysroot=yes. That seemed wrong, but it wasn't clearly the root problem.
I think now I explicitly say -with-sysroot=/usr/local/target/sys-root.
-with-sysroot and -with-build-sysroot is also confusing, in the general "all cross
build scenarios are confusing" sense, though build/host/target have more documentation.
I think in general:
build==host and host!=target => -with-sysroot
-disable-bootstrap and build!=host and host==target => neither (using previous to build)
build!=host and host==target maybe => -with-build-sysroot, if not -disable-bootstrap
If possible it'd be nice if configure gave early errors about missing sys-root or sys-include
or prefix/platform/include. I was a bit slow to discover the need for sys-root.
On the positive side:
"small" things are easy -- building native
"big" things are possible -- crosses of all sorts
Sorry if this all too vague..
- Jay
