This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [build] Support libgo on Solaris 2
"Joseph S. Myers" <joseph@codesourcery.com> writes:
> On Wed, 5 Jan 2011, Rainer Orth wrote:
>
>> * Building in a configured tree doesn't work, e.g. mksysinfo.sh uses
>> ${CC:-gcc}, which is wrong if the installed gcc isn't Go-capably
>> (which it most likely isn't). Either fix the invokation or substitute
>> the value into mksysinfo.sh.
>
> Since this is a target library, shouldn't it be configured with --host
> being the target and CC being the target compiler?
It is. The problem is that this setting of CC isn't communicated to
mksysinfo.sh: either CC should be passed in the environment on the
command line or mksysinfo.sh turned into mksysinfo.in and CC substituted
by configure.
>> * go1 is linked with libstdc++.so.6, but if that isn't installed (or too
>> old), compilation won't work. I had to manually set LD_LIBRARY_PATH
>> (both for libstdc++.so.6 and libgcc_s.so.1) to avoid that.
>
> It's meant to be linked with static libstdc++ to avoid this problem.
True. I think this happens already if bootstrapping GCC with a C++
compiler. The trouble is, this depends on HAVE_LD_STATIC_DYNAMIC, whose
detection only works with GNU ld ;-( Fixed. I'll check IRIX and Tru64
UNIX once I get there.
>> * Since mksysinfo.sh uses set -e, it silently exists upon the first
>> error. This script is massively unportable (e.g. if ! ...), heavily
>
> What's wrong with "if ! ..."? It's in POSIX (1992) and install.texi
> documents a POSIX shell should be used when configuring GCC (in general,
> and specifically ksh rather than /bin/sh for Solaris). Maybe we need to
> use CONFIG_SHELL for running this script - is there anything non-POSIX
> about the script?
I hadn't checked in detail: I only remember having had trouble with if ! -e
in libjava somewhere, even when using Solaris 2 /bin/ksh. There's a
section in the Autoconf manual about issues with if !, so it may be
better to avoid id.
>> * testsuite/gotest again calls nm -s, who'se output format isn't
>> portable. nm -ps works on Solaris, though.
>
> And of course for target files the configured target nm should be used.
Which would simply be $NM, which would have to be either substituted
into gotest or passed in the environment.
This doesn't help for the nm options to use, though. I'd have to check
if autoconf provides anything here, but this area has traditionally been
a can of worms (cf. the trouble with nm use in collect2 for LTO lately).
>> * The build relies on objcopy, which is available as gobjcopy on Solaris
>> 10+. configure.ac should account for that, but it's a general issue
>> not only pertaining to libgo.
>
> Again, the configured target objcopy should be used. I see toplevel
> configure only checks for objcopy for the host not the target; it should
> have a target check added and Makefile.tpl adjusted accordingly. This may
> not solve your problem, however.
True. The missing search for the g-prefixed binutils (on Solaris and
elsewhere) is general problem, independent of the current issue.
I have no idea if objcopy could be avoided here, though. Ian?
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University