Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC

Bug 577098

Summary: dev-lang/go packages fail on amd64-musl when built with external linker
Product: Gentoo Linux Reporter: Samuel Holland <samuel>
Component: Current packagesAssignee: William Hubbs <williamh>
Status: RESOLVED OBSOLETE    
Severity: normal CC: blueness, lu_zero, musl
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 430702    
Attachments: gdb "bt full" from running "/usr/bin/lxc --help"
output of "emerge --info"
output of "scanelf -aTv"
portage build log
output of "readelf -d /usr/bin/lxc"
Small test case
difference between vanilla and hardened gcc "readelf -d" of testcase
Patch from Alpine linux for dev-lang/go fixing the issue

Description Samuel Holland 2016-03-11 23:29:15 UTC
Created attachment 427996 [details]
gdb "bt full" from running "/usr/bin/lxc --help"

Both /usr/bin/lxc and /usr/sbin/lxd segfault in libc.so when run normally. It appears that musl fails to link them. Interestingly enough, they seem to work fine when run as an argument to the dynamic linker.

Also, portage complains about the presence of textrels, but scanelf cannot find them. This might be related.

helium ~ # /usr/bin/lxc
Segmentation fault
helium ~ # /lib/ld-musl-x86_64.so.1 /usr/bin/lxc
Usage: lxc [subcommand] [options]
Available commands:
        config     - Manage configuration.
        copy       - Copy containers within or in between lxd instances.
        delete     - Delete containers or container snapshots.
...
helium ~ #
Comment 1 Samuel Holland 2016-03-11 23:29:49 UTC
Created attachment 427998 [details]
output of "emerge --info"
Comment 2 Samuel Holland 2016-03-11 23:30:37 UTC
Created attachment 428000 [details]
output of "scanelf -aTv"
Comment 3 Felix Janda 2016-03-12 10:40:06 UTC
Please also post the output from 'readelf -d /usr/sbin/lxc' and a build
log with the complaints from portage.
Comment 4 Samuel Holland 2016-03-13 03:41:14 UTC
Created attachment 428094 [details]
portage build log
Comment 5 Samuel Holland 2016-03-13 03:41:54 UTC
Created attachment 428096 [details]
output of "readelf -d /usr/bin/lxc"
Comment 6 Felix Janda 2016-03-13 09:53:25 UTC
Created attachment 428116 [details]
Small test case

Can reproduce the issue. Here is a small test case (depending only on dev-lang/go).
Comment 7 Felix Janda 2016-03-13 18:38:28 UTC
More minimal test case:

cat <<EOF > main.go
package main

import _ "runtime/cgo"

func main() {
}
EOF
/usr/lib/go/pkg/tool/linux_$ARCH/compile -v -o lib.a -pack main.go
touch empty.c
gcc -c -fPIC -o empty.o empty.c
/usr/lib/go/pkg/tool/linux_$ARCH/pack r lib.a empty.o
/usr/lib/go/pkg/tool/linux_$ARCH/link -v -o main lib.a
Comment 8 Anthony Basile gentoo-dev 2016-03-14 17:21:25 UTC
(In reply to Felix Janda from comment #7)
> More minimal test case:
> 
> cat <<EOF > main.go
> package main
> 
> import _ "runtime/cgo"
> 
> func main() {
> }
> EOF
> /usr/lib/go/pkg/tool/linux_$ARCH/compile -v -o lib.a -pack main.go
> touch empty.c
> gcc -c -fPIC -o empty.o empty.c
> /usr/lib/go/pkg/tool/linux_$ARCH/pack r lib.a empty.o
> /usr/lib/go/pkg/tool/linux_$ARCH/link -v -o main lib.a


Are we getting this with the vanilla gcc?
Comment 9 Samuel Holland 2016-03-14 17:36:28 UTC
(In reply to Anthony Basile from comment #8)
> Are we getting this with the vanilla gcc?

No, it works properly with vanilla gcc.

helium ~ # set | grep GCC
GCC_SPECS=/usr/lib/gcc/x86_64-gentoo-linux-musl/4.9.3/vanilla.specs
helium ~ # ./main 
helium ~ #
Comment 10 Samuel Holland 2016-03-14 17:38:08 UTC
Created attachment 428228 [details]
difference between vanilla and hardened gcc "readelf -d" of testcase
Comment 11 Felix Janda 2016-03-14 18:28:24 UTC
By passing the "-tmpdir" option to go's "link" command one obtains a
1MB "go.o" object file.

"ld -pie go.o" gives the DT_TEXTREL warning, "ld go.o" does not. (It
is not supposed to link successfully in any case.)
Comment 12 Felix Janda 2016-03-14 19:33:29 UTC
Created attachment 428246 [details, diff]
Patch from Alpine linux for dev-lang/go fixing the issue
Comment 13 Anthony Basile gentoo-dev 2016-03-14 19:45:16 UTC
(In reply to Felix Janda from comment #12)
> Created attachment 428246 [details, diff] [details, diff]
> Patch from Alpine linux for dev-lang/go fixing the issue

that's the easiest fix.  the other is to find the assembly responsible for the textrels and fix that.  now here's the question, is this just a musl issue?  why aren't the textrels there for glibc?
Comment 14 Felix Janda 2016-03-15 10:49:20 UTC
Actually a bad binary seems to be generated for any input file if and
only if go's linker uses the external linking mode (calling gcc instead
of doing the linking itself). The linking mode can be set via a
command line option "-linkmode". If not, it is usually internal but
becomes external when it sees a "runtime/cgo" import.

Indeed, it would be interesting to see what is different for glibc.
Comment 15 Felix Janda 2016-03-15 19:19:24 UTC
DT_TEXTREL are also generated with glibc (at least with
armv7a-hardfloat-linux-gnueabi).

The upstream bug is still unresolved. So maybe the patch should be
applied unconditionally until it is resolved.
Comment 16 Anthony Basile gentoo-dev 2016-03-15 23:23:16 UTC
(In reply to Felix Janda from comment #15)
> DT_TEXTREL are also generated with glibc (at least with
> armv7a-hardfloat-linux-gnueabi).
> 
> The upstream bug is still unresolved. So maybe the patch should be
> applied unconditionally until it is resolved.

well "good" in some sense because otherwise i would be at a loss as to why
Comment 17 Erik Mackdanz gentoo-dev 2016-05-01 21:08:15 UTC
I'm reassigning this to the maintainer of dev-lang/go since the issue is general to all go packages, and because the attached patch is for dev-lang/go.
Comment 18 William Hubbs gentoo-dev 2016-05-11 22:25:49 UTC
(In reply to Felix Janda from comment #15)
> DT_TEXTREL are also generated with glibc (at least with
> armv7a-hardfloat-linux-gnueabi).
> 
> The upstream bug is still unresolved. So maybe the patch should be
> applied unconditionally until it is resolved.


Which upstream bug? Can you provide a link in the see also for this bug?
Comment 19 Felix Janda 2016-05-12 15:22:17 UTC
I was referring to

https://github.com/golang/go/issues/6940

which was still open then but seems to be resolved now.
Comment 20 Samuel Holland 2016-06-07 21:19:02 UTC
This bug is now causing issues for other packages, even with glibc (hardened/linux/amd64):

 *  Please include the following list of files in your report:
 * TEXTREL usr/bin/discosrv

 * ERROR: net-p2p/syncthing-0.13.5::gentoo failed:
 *   Aborting due to QA concerns:  textrels,

I can confirm the patch from Alpine fixes this as well.
Comment 21 William Hubbs gentoo-dev 2016-08-16 18:44:59 UTC
All,

is this still an issue for Go 1.7?
Comment 22 Samuel Holland 2016-10-13 03:29:27 UTC
(In reply to William Hubbs from comment #21)
> All,
> 
> is this still an issue for Go 1.7?

This appears to still be an issue with dev-lang/go-1.7.1::gentoo:

 *  Please include the following list of files in your report:
 * TEXTREL usr/bin/runc

 * ERROR: app-emulation/runc-1.0.0_rc2::gentoo failed:
 *   Aborting due to QA concerns:  textrels,

portage ~ # file /tmp/portage/app-emulation/runc-1.0.0_rc2/work/runc-1.0.0_rc2/src/github.com/opencontainers/runc/runc 
/tmp/portage/app-emulation/runc-1.0.0_rc2/work/runc-1.0.0_rc2/src/github.com/opencontainers/runc/runc: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, not stripped
portage ~ # /tmp/portage/app-emulation/runc-1.0.0_rc2/work/runc-1.0.0_rc2/src/github.com/opencontainers/runc/runc 
Segmentation fault
portage ~ # /lib/ld-musl-x86_64.so.1 /tmp/portage/app-emulation/runc-1.0.0_rc2/work/runc-1.0.0_rc2/src/github.com/opencontainers/runc/runc 
/lib/ld-musl-x86_64.so.1: /tmp/portage/app-emulation/runc-1.0.0_rc2/work/runc-1.0.0_rc2/src/github.com/opencontainers/runc/runc: Not a valid dynamic program

Again, everything works fine with vanilla specs.
Comment 23 Samuel Holland 2017-01-12 00:28:15 UTC
This was fixed in either 1.7.3 or 1.7.4.