https://sourceware.org/bugzilla/show_bug.cgi?id=33199
--- Comment #4 from Rainer Orth <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #1 from Indu Bhagat <indu.bhagat at oracle dot com> ---
> On a cfarm 215, when running the ld testsuite, I see that the lto.exp tests
> are
> not run. Not sure if I need a gcc with lto enabled (will look).
>
> Further many of the ld tests fail (also the same failure when I try simple
> manual ld runs) with:
> ./ld-new:built in linker script:0: syntax error
>
> I need to get past this error to be able to run ld to debug...
Ah, sorry about that. This is PR ld/32580. In short, you need to
export CONFIG_SHELL=/bin/bash
*before* running configure; make
I've tried to come up with a workaround directly in binutils' configury,
but so far I've failed, probably because I tried it at the toplevel
while automake has a bug correctly passing through CONFIG_SHELL to
sub-configures/make. I've got an idea how to fix this, though.
This will cause correct linker scripts to be generated.
There are more issues, unfortunately: config.guess has been broken
almost beyond repair on Solaris, and the patch authors/maintainers
refuse to see reason. Therefore you have to specify --build yourself
correctly:
* 64-bit Solaris x86_64/amd64 amd64-pc-solaris2.11 (or x86_64-...,
doesn't really matter)
* 32-bit Solaris/i386 i386-pc-solaris2.11
* 64-bit Solaris/sparcv9 sparcv9-sun-solaris2.11
* 32-bit Solaris/sparcv7 sparc-sun-solaris2.11
And last but not least, on Solaris you have two options for assembler
and linker, as documented in gcc's install.texi:
* Solaris as and ld, in /usr/bin/as, /usr/bin/ld
* GNU as and ld, in /usr/gnu/bin/as, /usr/gnu/bin/ld (for the bundled
versions)
gcc can be configured to use either (and most combinations except as/gld
work), but the decision is made at configure time. Their command lines
aren't compatible, so you get errors if you get this wrong. To avoid
picking up the wrong version just by changing PATH, it's customary to
configure gcc with --with-as=/path/to/as --with-ld=/path/to/ld.
However, such a configuration ignores -B, so it will always use the
configured tools, while binutils depend on the ability to point gcc to
the freshly-built tools at runtime.
To deal with this in the context of binutils testing, here's what I do:
* Set PATH to $prefix/bin:$PATH
* export CONFIG_SHELL=/bin/bash
* Configure binutils with
** 64-bit:
configure --prefix=$prefix --build=$build (as above)
** 32-bit:
configure CC='gcc -m32' CXX='g++ -m32' --prefix=$prefix --build=$build
Afterwards, build either or both 64-bit-default and/or 32-bit-default
gcc configured with just
--prefix=$prefix --build=$build --with-as --with-ld
--enable-languages=c,c++,lto
To spare binutils developers the trouble, I've now installed just such a
configuration on the Solaris cfarm machines in /opt/cfarm/gcc-binutils
resp. .../gcc-binutils-64. The 64-bit versions are already in place,
32-bit versions are currently building.
After setting PATH and CONFIG_SHELL as above, you should now be able to
use those versions for binutils testing without further trouble. You
can also omit the --prefix; no need for that for uninstalled testing.
Hope this helps. I suppose it would be best to document all this in the
binutils wiki, although with /opt/cfarm/gcc-binutils* things have become
much simpler.
--
You are receiving this mail because:
You are on the CC list for the bug.
