[AIX] Changes for linking gotools on AIX.

Description:
 * This patch adds linker options for gotools for AIX.

Tests:
 * Fedora25/x86_64 + GCC trunk : Configure/Build: SUCCESS
   - build remade by means of gmake.
   - some test redone in libgo (gmake check)
 * AIX + GCC 7.1.0 :
   - build remade by means of gmake.
   - some test redone in libgo (gmake check)
 
ChangeLog:
 * Makefile.am (AM_LDFLAGS & GOLINK): Changes for linking on AIX.
 * Makefile.in: Rebuild.

Cordialement,

Tony Reix

Bull - ATOS
IBM Coop Architect & Technical Leader
Office : +33 (0) 4 76 29 72 67
1 rue de Provence - 38432 Échirolles - France
www.atos.net

On Wed, Jul 26, 2017 at 12:41 PM, REIX, Tony <tony.reix@atos.net> wrote:
> Description:
>  * This patch adds linker options for gotools for AIX.
>
> Tests:
>  * Fedora25/x86_64 + GCC trunk : Configure/Build: SUCCESS
>    - build remade by means of gmake.
>    - some test redone in libgo (gmake check)
>  * AIX + GCC 7.1.0 :
>    - build remade by means of gmake.
>    - some test redone in libgo (gmake check)
>
> ChangeLog:
>  * Makefile.am (AM_LDFLAGS & GOLINK): Changes for linking on AIX.
>  * Makefile.in: Rebuild.

If this is trying to fix AIX search paths, a better solution would
seem to be the equivalent of -static-libstdc++ -static-libgcc.  The Go
tools should be linked statically and not depend on Go shared
libraries.

Thanks, David

On Wed, Jul 26, 2017 at 9:58 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Wed, Jul 26, 2017 at 12:41 PM, REIX, Tony <tony.reix@atos.net> wrote:
>> Description:
>>  * This patch adds linker options for gotools for AIX.
>>
>> Tests:
>>  * Fedora25/x86_64 + GCC trunk : Configure/Build: SUCCESS
>>    - build remade by means of gmake.
>>    - some test redone in libgo (gmake check)
>>  * AIX + GCC 7.1.0 :
>>    - build remade by means of gmake.
>>    - some test redone in libgo (gmake check)
>>
>> ChangeLog:
>>  * Makefile.am (AM_LDFLAGS & GOLINK): Changes for linking on AIX.
>>  * Makefile.in: Rebuild.
>
> If this is trying to fix AIX search paths, a better solution would
> seem to be the equivalent of -static-libstdc++ -static-libgcc.  The Go
> tools should be linked statically and not depend on Go shared
> libraries.

On GNU/Linux I used to use -static-libgo, but I changed it because of
https://gcc.gnu.org/PR64738.  Of course on AIX we can do as you
prefer.

Ian

Hi Ian, David,

On AIX, that is more complicated...

We have to use -static-libgo when building the libgo tests. Because AIX does not work like Linux does and because the Go libgo tests are done by duplicating several .go files of libgo packages that already appear in the libgo.a (libgo.so) library.
On AIX, without -static-libgo, when building/running the libgo tests, we have Go variables defined somewhere and used elsewhere, BUT with different memory addresses... leading to bad issues...

However, when building/linking real Go application code outside of Gcc Go compiler, and thus with NO 2-times compiled libgo internal code, we have another issue and we need to load libgo.a at first, otherwise we have other issues.

In short, this patch is the first step of a global fix we have found for AIX for covering the 2 cases: build/run libgo internal tests, and build real NO-libgo internal customer code. And it works fine.
I'll provide the second step later.


Cordialement,

Tony Reix

Bull - ATOS
IBM Coop Architect & Technical Leader
Office : +33 (0) 4 76 29 72 67
1 rue de Provence - 38432 Échirolles - France
www.atos.net

On Thu, Jul 27, 2017 at 11:51 AM, REIX, Tony <tony.reix@atos.net> wrote:
> Hi Ian, David,
>
> On AIX, that is more complicated...
>
> We have to use -static-libgo when building the libgo tests. Because AIX does not work like Linux does and because the Go libgo tests are done by duplicating several .go files of libgo packages that already appear in the libgo.a (libgo.so) library.
> On AIX, without -static-libgo, when building/running the libgo tests, we have Go variables defined somewhere and used elsewhere, BUT with different memory addresses... leading to bad issues...
>
> However, when building/linking real Go application code outside of Gcc Go compiler, and thus with NO 2-times compiled libgo internal code, we have another issue and we need to load libgo.a at first, otherwise we have other issues.
>
> In short, this patch is the first step of a global fix we have found for AIX for covering the 2 cases: build/run libgo internal tests, and build real NO-libgo internal customer code. And it works fine.
> I'll provide the second step later.

My concern is that the patch explicitly inserts the build directory
into the search path for the tools.  GCC already is fairly screwed up
with respect to the search path without explicitly making it worse.
Ideally, the libpath should be the install directory, not the build
directory.

If I understand your reply, this is a hack to allow the testsuite to
run in the build tree.

Thanks, David