code review 125470043: compiler: symbol names should have '.' replaced with '_'

compiler: symbol names should have '.' replaced with '_'

Package and symbol names issued by the cgo tool and compiler
should be the same for the object files to link.

A minimal change to fix only:
   https://code.google.com/p/gofrontend/issues/detail?id=36
and
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880

[ash%kambanaria.org, 2014-08-19 08:48:57]

Hello gofrontend-dev@googlegroups.com (cc: gofrontend-dev@googlegroups.com,
iant@golang.org),

I'd like you to review this change to
https://code.google.com/p/gofrontend/

[ash%kambanaria.org, 2014-08-19 09:06:39]

Hello gofrontend-dev@googlegroups.com (cc: gofrontend-dev@googlegroups.com,
iant@golang.org),

Please take another look.

[mwhudson, 2014-08-26 04:09:19]

Having just rediscovered this problem, I would like to report that this patch
does indeed appear to fix it...

[iant, 2014-09-30 13:46:50]

Sorry to leave this so long.  Have you signed the CLA as described at
http://golang.org/doc/contribute.html#copyright ?

[ash_kambanaria.org, 2014-10-02 14:29:47]

Yes, I have just signed it.

Ian,
I understand that perhaps you have many other responsibilities and
tasks and I would suppose gc toolchain is the top priority for you as
part of the Google Go team.
You are the main (or even only) maintainer of gccgo - is there
anything that I can do to ease or speed bug fixing? I would really
want to get Docker running on PowerPC.

Since:
 * this architecture is not a priority for Google and I suppose it
will never be,
 * anything beyond x86_64 is out of scope for The Docker community and
Docker, Inc. (former dotCloud)
I can hardly find any collaborators.

Short of asking direct help - as gccgo toolchain is not as mature as
the gc one - is it possible to get some mass compiling/cross compiling
effort to get large Go projects external to Google compiled, linked
and run with gccgo? This will be a much harsher test harness than the
one Go ships with and will likely help gccgo (and especially me) and
a lot.

Kind regards:
al_shopov

2014-09-30 16:46 GMT+03:00  <iant@golang.org>:
> Sorry to leave this so long.  Have you signed the CLA as described at
> http://golang.org/doc/contribute.html#copyright ?
>
> https://codereview.appspot.com/125470043/

[iant, 2014-10-02 17:52:20]

LGTM

Thanks.

[iant, 2014-10-02 17:56:12]

*** Submitted as
https://code.google.com/p/gofrontend/source/detail?r=ae56e39c190f ***

compiler: symbol names should have '.' replaced with '_'

Package and symbol names issued by the cgo tool and compiler
should be the same for the object files to link.

A minimal change to fix only:
   https://code.google.com/p/gofrontend/issues/detail?id=36
and
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880

LGTM=iant
R=gofrontend-dev, michael.hudson, iant, ash
CC=gofrontend-dev
https://codereview.appspot.com/125470043

Committer: Ian Lance Taylor <iant@golang.org>

[axw, 2014-10-03 08:22:26]

On 2014/10/02 14:29:47, ash_kambanaria.org wrote:
> Yes, I have just signed it.
> 
> Ian,
> I understand that perhaps you have many other responsibilities and
> tasks and I would suppose gc toolchain is the top priority for you as
> part of the Google Go team.
> You are the main (or even only) maintainer of gccgo - is there
> anything that I can do to ease or speed bug fixing? I would really
> want to get Docker running on PowerPC.
> 
> Since:
>  * this architecture is not a priority for Google and I suppose it
> will never be,
>  * anything beyond x86_64 is out of scope for The Docker community and
> Docker, Inc. (former dotCloud)
> I can hardly find any collaborators.
> 
> Short of asking direct help - as gccgo toolchain is not as mature as
> the gc one - is it possible to get some mass compiling/cross compiling
> effort to get large Go projects external to Google compiled, linked
> and run with gccgo? This will be a much harsher test harness than the
> one Go ships with and will likely help gccgo (and especially me) and
> a lot.

FWIW, we (Canonical) regularly build/run/test Juju on PPC64 (little endian) and
AArch64 with gccgo. I think it's fair to say Juju is "large", but it does not
have any cgo dependencies. mwhudson recently succeeded in getting Docker working
on AArch64[0].

[0] https://plus.google.com/115162568782126569728/posts/A8Q5m7ZZ2xj

> Kind regards:
> al_shopov
> 
> 2014-09-30 16:46 GMT+03:00  <mailto:iant@golang.org>:
> > Sorry to leave this so long.  Have you signed the CLA as described at
> > http://golang.org/doc/contribute.html#copyright ?
> >
> > https://codereview.appspot.com/125470043/

[iant, 2015-01-12 17:11:21]

It turns out that this change breaks SWIG (see
https://github.com/swig/swig/pull/301#issuecomment-69487603).  We need to figure
out something else.

[minux, 2015-01-12 22:23:40]

On Mon, Jan 12, 2015 at 12:11 PM, <iant@golang.org> wrote:

> It turns out that this change breaks SWIG (see
> https://github.com/swig/swig/pull/301#issuecomment-69487603).  We need
> to figure out something else.
>
But the change is already in 4.9, I guess SWIG needs to workaround
it anyway. Does it make sense to change it again? (If we change it
in 5.0, then SWIG still need to workaround this for 4.9 to 4.9.2 (assume
we also backport new fix to 4.9 branch.)

[iant, 2015-01-12 23:22:49]

The change is wrong, or, rather, incomplete.  It needs to be fixed.  Note that
the fix should apply to the case where -fgo-pkgpath is not used, so it should
not affect most users.

The patch was committed to the 4.9 branch on 2014-10-02.  It is in GCC 4.9.2
only, not in GCC 4.9.0 or 4.9.1.  In particular the go tool always passes
-fgo-pkgpath except when compiling a main package.