public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andreas Krebbel <krebbel@linux.vnet.ibm.com>
To: Ian Lance Taylor <iant@golang.org>, gcc-patches@gcc.gnu.org
Subject: Re: libgo patch committed: Change build procedure to use build tags
Date: Fri, 12 Aug 2016 11:20:00 -0000	[thread overview]
Message-ID: <6e128c9e-8f4d-8222-f3cc-2425b88275e3@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAOyqgcUzQ8Cv+Bx=7TrO5z-CNti2ED+qfXwxL6FNFLKrw4D-nA@mail.gmail.com>

On 08/06/2016 02:36 AM, Ian Lance Taylor wrote:
> Go packages use build tags (see the section on Build Constraints at
> https://golang.org/pkg/go/build/) to select which files to build on
> specific systems.
> 
> Previously the libgo Makefile explicitly listed the set of files to
> compile for each package.  For packages that use build tags, this
> required a lot of awkward automake conditionals in the Makefile.
> 
> This patch changes the build to look at the build tags in the files.
> The new shell script libgo/match.sh does the matching.  This required
> adjusting a lot of build tags, and removing some files that are never
> used.  I verified that the exact same sets of files are compiled on
> x86_64-pc-linux-gnu.  I also tested the build on i386-sun-solaris
> (building for both 32-bit and 64-bit).
> 
> Writing match.sh revealed some bugs in the build tag handling that
> already exists, in a slightly different form, in the gotest shell
> script.  This patch fixes those problems as well.
> 
> The old code used automake conditionals to handle systems that were
> missing strerror_r and wait4.  Rather than deal with those in Go,
> those functions are now implemented in runtime/go-nosys.c when
> necessary, so the Go code can simply assume that they exist.
> 
> The os testsuite looked for dir_unix.go, which was never built for
> gccgo and has now been removed.  I changed the testsuite to look for
> dir.go instead.
> 
> Note that if you have an existing build directory, you will have to
> remove all the .dep files in TARGET/libgo after updating to this
> patch.  There isn't anything that will force them to update
> automatically.
> 
> Bootstrapped on x86_64-pc-linux-gnu and i386-sun-solaris.  Ran Go
> testsuite on x86_64-pc-linux-gnu.  Committed to mainline.
> 
> Ian

This appears to break libgo build on s390x:

libtool: compile:  /home3/andreas/clean/gcc-7.0.0-64-clean-build/./gcc/gccgo
-B/home3/andreas/clean/gcc-7.0.0-64-clean-build/./gcc/
-B/home3/andreas/clean/gcc-7.0.0-64-clean-install/s390x-ibm-linux-gnu/bin/ -B/h
ome3/andreas/clean/gcc-7.0.0-64-clean-install/s390x-ibm-linux-gnu/lib/ -isystem
/home3/andreas/clean/gcc-7.0.0-64-clean-install/s390x-ibm-linux-gnu/include -isystem
/home3/andreas/clean/gcc-7.0.0-64-clean-instal
l/s390x-ibm-linux-gnu/sys-include -O2 -g -I . -c -fgo-pkgpath=hash/crc32
/home3/andreas/clean/../gcc/libgo/go/hash/crc32/crc32.go
/home3/andreas/clean/../gcc/libgo/go/hash/crc32/crc32_generic.go /home3/andreas/c
lean/../gcc/libgo/go/hash/crc32/crc32_s390x.go  -fPIC -o hash/.libs/crc32.o
/home3/andreas/clean/../gcc/libgo/go/hash/crc32/crc32_s390x.go:56:1: error: redefinition of
‘updateCastagnoli’
 func updateCastagnoli(crc uint32, p []byte) uint32 {
 ^
/home3/andreas/clean/../gcc/libgo/go/hash/crc32/crc32_generic.go:12:1: note: previous definition of
‘updateCastagnoli’ was here
 func updateCastagnoli(crc uint32, p []byte) uint32 {
 ^
/home3/andreas/clean/../gcc/libgo/go/hash/crc32/crc32_s390x.go:81:1: error: redefinition of ‘updateIEEE’
 func updateIEEE(crc uint32, p []byte) uint32 {
 ^
/home3/andreas/clean/../gcc/libgo/go/hash/crc32/crc32_generic.go:20:1: note: previous definition of
‘updateIEEE’ was here
 func updateIEEE(crc uint32, p []byte) uint32 {
 ^
make[4]: *** [hash/crc32.lo] Error 1
make[4]: *** Waiting for unfinished jobs....


Adding more "build ignore"s does fix the build for me.

However, I'm wondering why we have to disable the asm tuned files for gccgo? For s390 I really would
like to enable them since they make a huge difference.

The same is probably also required in ./hash/crc32/crc32_amd64p32.go
I could add this as well.

Ok to apply?

diff --git a/libgo/go/crypto/aes/cbc_s390x.go b/libgo/go/crypto/aes/cbc_s390x.go
index 427b30b..8346b5e 100644
--- a/libgo/go/crypto/aes/cbc_s390x.go
+++ b/libgo/go/crypto/aes/cbc_s390x.go
@@ -2,6 +2,8 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.

+// +build ignore
+
 package aes

 import (
diff --git a/libgo/go/crypto/aes/ctr_s390x.go b/libgo/go/crypto/aes/ctr_s390x.go
index 94dea5c..ae09dba 100644
--- a/libgo/go/crypto/aes/ctr_s390x.go
+++ b/libgo/go/crypto/aes/ctr_s390x.go
@@ -2,6 +2,8 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.

+// +build ignore
+
 package aes

 import (
diff --git a/libgo/go/hash/crc32/crc32_s390x.go b/libgo/go/hash/crc32/crc32_s390x.go
index 2f20690..b8a5808 100644
--- a/libgo/go/hash/crc32/crc32_s390x.go
+++ b/libgo/go/hash/crc32/crc32_s390x.go
@@ -2,6 +2,8 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.

+// +build ignore
+
 package crc32

 import (

  parent reply	other threads:[~2016-08-12 11:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-06  0:36 Ian Lance Taylor
2016-08-07 12:14 ` Andreas Schwab
2016-08-07 15:18   ` Matthias Klose
2016-08-07 22:33     ` Ian Lance Taylor
2016-09-04 16:24     ` Matthias Klose
2016-09-23 21:53       ` Ian Lance Taylor
2016-08-08 18:15 ` Lynn A. Boger
2016-08-08 18:26   ` Ian Lance Taylor
2016-08-08 19:07     ` Lynn A. Boger
2016-08-08 20:34   ` Ian Lance Taylor
2016-08-09 15:46     ` Lynn A. Boger
2016-08-11 15:16 ` Rainer Orth
2016-08-11 21:36   ` Ian Lance Taylor
2016-08-12  9:15     ` Rainer Orth
2016-08-12 13:56       ` Rainer Orth
2016-08-13  2:53         ` Ian Lance Taylor
2016-08-13  0:14       ` Ian Lance Taylor
2016-08-12 11:20 ` Andreas Krebbel [this message]
2016-08-13  0:23   ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6e128c9e-8f4d-8222-f3cc-2425b88275e3@linux.vnet.ibm.com \
    --to=krebbel@linux.vnet.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iant@golang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).