Bug#904289: libgo build failure with GCC trunk 20181004

2018-10-08 Thread Ian Lance Taylor
On Mon, Oct 8, 2018 at 8:59 PM, Matthias Klose  wrote:
> On 08.10.2018 11:47, Svante Signell wrote:
>> On Fri, 2018-10-05 at 21:10 +0200, Svante Signell wrote:
>>> On Fri, 2018-10-05 at 01:38 +0200, Matthias Klose wrote:
 Hi Svante,

 please have a look at the recent libgo build failure with GCC trunk
 20181004 after the libgo merge.  Please could you update the
 patches and send them upstream again?
>>>
>>> Well I don't really know where to submit the patches to upstream, but
>>> here they are. Cc:ing the gcc-snapshot bug 904...@bugs.debian.org
>>> too.
>>
>> Hi again,
>>
>> Seems like more changes were needed this time: Attached are three
>> updated patches:
>> src_libgo_go_syscall.diff
>> add-gnu-to-libgo-headers.diff
>> add-gnu-to-libgo-test-headers.diff
>
> Thanks for the update, but please could you send *all* the patches to
> gcc-patc...@gcc.gnu.org, and maybe CC Ian?  Patches really have to be ready to
> be applied upstream, and not to some Debian package.
>
> Please see https://gcc.gnu.org/contribute.html how to contribute.  libgo might
> be a bit different, because the source is maintained in golang, and then
> imported into GCC.

The absolute best way to contribute to the libgo and gcc/go/gofrontend
directories is to use Gerrit, following the process described at
https://golang.org/doc/contribute.html.

But sending patches to gcc-patc...@gcc.gnu.org and CC'ing me is also
OK.  Yes, in general the patches have to apply to GCC trunk.

Thanks.

Ian



Bug#876639: libgo11: Please consider backport "libgo: use gc's arch names as the default GOARCHs on MIPS"

2017-09-24 Thread Ian Lance Taylor
Matthias Klose  writes:

> On 24.09.2017 11:36, Shengjing Zhu wrote:
>> Package: libgo11
>> Version: 7.2.0-5
>> Severity: wishlist
>> Tags: upstream
>> X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
>> 
>> Dear Maintainer,
>> 
>> Currently the pkg-go team uses gccgo to build Go packages on MIPS*
>> archs. However currently version of gccgo has different GOARCH name for
>> MIPS*.
>> 
>> Bug is reported at https://github.com/golang/go/issues/18031
>> And the fix is applied in trunk,
>> https://github.com/gcc-mirror/gcc/commit/074bbd7b6a221b0446c73b3f4c2e1bf6cc7b2634
>> 
>> We currently need tricky way to build Go packages on MIPS*(as described
>> in https://github.com/golang/go/issues/18031#issuecomment-318574018 )
>> 
>> So I think backport this fix in gccgo can be really helpful.
>
> Is this commit good enough for the gcc-7-branch?
>
> CCing Ian, if that could be backported in GCC to the gcc-7-branch.

It should be fine to backport that to GCC 7.

Ian



Bug#683782: gccgo: please Recommend: binutils-gold on x86

2012-08-07 Thread Ian Lance Taylor
On Tue, Aug 7, 2012 at 3:44 AM, Matthias Klose d...@debian.org wrote:
 On 04.08.2012 00:07, shawn wrote:
 Source: gcc-4.7
 Version: 4.7.1-6
 Severity: normal

 gccgo requires binutils-gold in order to fully use gcc's split stack feature.
 As this feature is heavily used by the core language constructs of go,
 (namely goroutines, which are conceptually light-weight threads)
 and has large performance inpacts, gccgo should Recommend: binutils-gold. 
 (at least)

 no, forcing gold on everything would be wrong. IMO libgomp.spec should add an
 -B/usr/lib/gold-ld option the the libgomp link spec, if this is the preferred
 linker.

You're mixing up libgomp and libgo.  There is no libgo.spec.  libgomp
is irrelevant.

Ian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#632003: Finding dlltool using gcc

2011-09-21 Thread Ian Lance Taylor
Stephen Kitt st...@sk2.org writes:

 Is there a recommended approach to use to find dlltool using only
 i686-w64-mingw32-gcc?

I don't know of one.  I don't know why avoiding autoconf is desirable.
However, if I were forced to do so, I would probably use gcc -v to get
the target name and look for TARGET-dlltool that way.

 I am wrong in dropping /usr/$target/bin?

No, you are right.  That directory is used to communicate programs from
the binutils to gcc, and there are no promises about what binaries may
be found there.

Ian



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#628622: gccgo-4.6: Is gccgo GNU?

2011-05-30 Thread Ian Lance Taylor
Some more information: the code described at http://golang.org/ is not
gccgo.  gccgo is a different compiler for the Go language, written as a
frontend for gcc.  gccgo is mentioned on gcc's home page,
http://gcc.gnu.org/.  It's another GCC frontend, just like the C, C++,
Fortran, Java, Objective C, Objective C++, and Ada frontends.

I'm not sure what the actual bug is here so I'm not sure if there is
anything else useful to add.

Ian



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org