https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880

            Bug ID: 61880
           Summary: Linking with external functions in C does not work in
                    GO when using gccgo, while it works in gc
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: lists at kambanaria dot org
                CC: cmang at google dot com

Created attachment 33173
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33173&action=edit
tiniest GOPATH demoing the problem (28 nonempty lines, 6 in C, 22 in GO
including comments)

This is continuation of issue reported here:
https://code.google.com/p/gofrontend/issues/detail?id=36

Since I have changed the test case to be extremely simple with no external
references to any libraries or applications, I am moving the bug here.

1. Demo of the issue:
        tar xvfz CGO_FALURE.tar.gz
        cd CGO_FALURE
        export GOPATH=`pwd`
        go run -compiler gccgo src/cgo_problem/demo.go
results in:
        # command-line-arguments
       
/tmp/go-build280712483/cgo_problem/example.com/libdemo.a(_cgo_export.o): In
function `Dummy':
       
/tmp/go-build280712483/cgo_problem/example.com/demo/_obj/_cgo_export.c:5:
undefined reference to `cgo_problem_example_com_demo.Cgoexp_Dummy'
        collect2: error: ld returned 1 exit status

2. Compare with the behavior of gc:
        go run -compiler gccgo src/cgo_problem/demo.go
results in:
        Address of function Dummy: 0x400f30

The issue can be worked around by renaming the example.com/demo package to
example_com/demo
        mv src/cgo_problem/example.com src/cgo_problem/example.com
        sed -i 's/example[.]com/example_com/' src/cgo_problem/demo.go

3. The problem stems from:

The _cgo_export.h file that is emitted by cgo.
The first part of the name given to __asm__ macro is generated by the
gccgoSymbolPrefix method here: http://golang.org/src/cmd/cgo/out.go#L985

Perhaps the runes that get emitted directly should include the dot '.' - it is
the domain delimiter character which is reused in package names.

4. gcc versions 4.8, 4.9, 4.10 suffer from this issue:

4.8:
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC) 


4.9:
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ashopov/WORK/GCC/libexec/gcc/x86_64-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../configure --prefix=/home/ashopov/WORK/GCC
--build=x86_64-linux-gnu --disable-browser-plugin --disable-libgcj
--disable-libmudflap --disable-vtable-verify --disable-libunwind-exceptions
--enable-checking=release --disable-bootstrap --enable-__cxa_atexit
--enable-gnu-unique-object --enable-languages=c,c++,go,lto
--enable-linker-build-id --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --with-linker-hash-style=gnu --with-system-zlib
--with-tune=generic --enable-multiarch
Thread model: posix
gcc version 4.9.1 20140709 (prerelease) (GCC) 


4.10:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ashopov/WORK/GCC-TRUNK/libexec/gcc/x86_64-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ./configure --prefix=/home/ashopov/WORK/GCC-TRUNK
--build=x86_64-linux-gnu --disable-browser-plugin --disable-libgcj
--disable-libmudflap --disable-vtable-verify --disable-libunwind-exceptions
--enable-checking=release --disable-bootstrap --enable-__cxa_atexit
--enable-gnu-unique-object --enable-languages=c,c++,go,lto
--enable-linker-build-id --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --with-linker-hash-style=gnu --with-system-zlib
--with-tune=generic --enable-multiarch
Thread model: posix
gcc version 4.10.0 20140721 (experimental) (GCC) 

5. System is:
Linux ashopov-dev 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux - up to date Fedora x86_64 box

6. gc/go are:
golang-1.2.2-7.fc20.x86_64

7. Sadly I could not convert this to a test case since 'go test' does not allow
using cgo.

Reply via email to