[build] Support libgo on Solaris 2

Ian Lance Taylor <ian@airs.com> writes:

>> * 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.
>
> It should work fine if you build using "make all-target-libgo" from the
> top level.  I have no objection to making it work if you build in the
> libgo directory directly.

Fine.  It certainly makes development far easier.

>> * 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.
>
> If you do not use --disable-bootstrap, then go1 should be built with
> -static-libstdc++ and this should not happen.  So, I assume you did
> disable bootstrap.  In that case go1 will be built with the installed
> g++, and the assumption is that the installed g++ uses a libstdc++.so
> which the dynamic linker knows how to find.  I assume that is not the
> case on your system, but I don't know what else to do when bootstrap is
> disabled.  You can of course use the --with-host-libstdcxx or
> --with-stage1-libs options to set -rpath options as appropriate for your
> system.

I didn't use --disable-bootstrap, and -static-libstdc++ -static-libgcc
are already used.  As mentioned in my response to Joseph, the issue is
far easier, though: -static-libstdc++ depends on the correct detection
of -Bstatic/-Bdynamic, and the test is currently (again ;-)
gld-specific.  Solaris ld (and most likely even SunOS 4 ld) has
supported this since day 1.  If I fix gcc/configure.ac to know about
this, go1 is indeed linked statically with libstdc++ and libgcc.

>> * Since mksysinfo.sh uses set -e, it silently exists upon the first
>>   error.  This script is massively unportable (e.g. if ! ...), heavily
>>   Linux-specific, and I'm uncertain if this is the best approach here.
>>   Anyway, I've removed the set -e and manually fixed the issues with the
>>   generated sysinfo.go until it's decided how to proceed.  Perhaps it
>>   could be replaced by a C program and autoconf tests?
>
> Removing the set -e will just tend to hide problems, though I'm
> certainly open to suggestions for how to make the script easier to work
> with.  As far as I know "if !" is POSIX, but if it doesn't work it can
> be removed easily enough.
>
> The script can be augmented by autoconf tests where that makes sense,
> but it can't really be replaced by them.  I don't think a C program is
> really right here, because the script is mainly running sed, which is a
> job more appropriate for the shell than for a C program.

Ok.  I've coaxed the Solaris changes into the script, and expect do be
able to do the same for IRIX and Tru64 UNIX later.  As I said, so far
I've been lasy here to get someting running at all.

>>   Here are the changes I had to make:
>>
>> -type _pad128_t struct { _q float80; }
>> -type _upad128_t struct { _q float80; }
>> +type _pad128_t struct { _l [4]int32; }
>> +type _upad128_t struct { _l [4]uint32; }
>>
>>   Without this, I get
>>
>> sysinfo.go:1841:28: error: use of undefined type 'float80'
>> sysinfo.go:1841:25: error: struct field type is incomplete
>
> The use of float80 is a bug in godump.c.  The Go language used to have a
> float80 type but it no longer does.

I see.  For the moment, I've include a workaround in mksysinfo.sh.  Do
you envision this being fixed soon?

>>   I got
>>
>> sysinfo.go:2132:5: error: redefinition of '_timezone'
>> sysinfo.go:1921:6: note: previous definition of '_timezone' was here
>>
>>   corresponding to
>>
>> type _timezone struct { tz_minuteswest int32; tz_dsttime int32; }
>> var _timezone int32
>>
>>   I'm removing the var for now.
>
> I guess this should be handled in godump.c too, somehow.  In Go all
> names are in the same namespace, unlike C.

Ok.  Also worked around for the moment.

>> * It's currently hard to identify which libgo sources require which OS
>>   features and which are completely portable.  The deeply nested
>>   automake conditionals don't help either, especially since they give no
>>   real indication why which file is used where.
>>
>>   I've tried to improve things by adding comments liberally.  As usual,
>>   Solaris needs -lsocket (and eventually -lnsl, though things work
>>   without so far), so I've added support for NET_LIBS.  The configure
>>   test is obviously a hack that needs to be done properly, though the
>>   code in libjava/configure.ac might be overkill.
>
> Thanks.  This stuff is definitely awkward.  Part of the complexity comes
> from the master Go library; I want to minimize differences with that.

Understood: if we can up with something understandable (and be it even
comments about the different variants), hopefully this can go upstream?

>> * Several other changes should be clear from comments in the code.
>>   Unfortunately, many files in syscalls seem to be largely identical
>>   copies of each other.  It would be helpful to modularize this
>>   somewhat.
>
> Where possible, yes.

I'll check, especially when I (ever) get to trying this on anything but
Solaris.

>>   I often see dummy implementations (like go/debug/regs/{proc, regs}_*);
>>   perhaps there should be a single dummy to use until a real one is
>>   provided?
>
> That comes from the master library, which would be the place to fix it.

I see.  A misunderstanding on my part: I had misread that only the go
subdirectory was from upstream.

>> * testsuite/gotest again calls nm -s, who'se output format isn't
>>   portable.  nm -ps works on Solaris, though.
>
> Actually using -s is a bug inherited from the master gotest script.  The
> intent is to use the option which avoids sorting the symbols.

Ok.  It would be nice to centralize knowledge about how to invoke nm
somewhere, because this issue crops up over and over again.

>> * Currently, libgo prefers the gotest-bases testsuite instead of
>>   DejaGnu, which IMO is highly unfortunate since this gives us yet
>>   another test framework in GCC with a different output format and not
>>   integrated with mail-report.log.  We should strive for the opposite
>>   here!  Even if I force the DejaGnu-based one, it fails immediately
>>   since it sets GO_UNDER_TEST while the testsuite in gcc/testsuite/lib
>>   uses GOC_UNDER_TEST :-)
>
> Let's just make the libgo testsuite output match whatever
> mail-report.log wants.  Using DejaGNU for the libgo tests will just make
> them harder to run.  The output is determined by the CHECK variable in
> libgo/Makefile.am.

No!  I'm currently working to get as many of the GCC testsuites as
possible to use DejaGnu, among others for reasons discussed in

	http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00244.html

It would be a maintenance nightmare to have to coax many different
testsuite frameworks to both produce the DejaGnu output format (not that
hard, probably, but there have been differences that
e.g. dg-extract-results.sh had to be taught about) and to have many

[build] Support libgo on Solaris 2

Commit Message

Comments

Patch