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 ~ #
Created attachment 427998 [details] output of "emerge --info"
Created attachment 428000 [details] output of "scanelf -aTv"
Please also post the output from 'readelf -d /usr/sbin/lxc' and a build log with the complaints from portage.
Created attachment 428094 [details] portage build log
Created attachment 428096 [details] output of "readelf -d /usr/bin/lxc"
Created attachment 428116 [details] Small test case Can reproduce the issue. Here is a small test case (depending only on dev-lang/go).
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
(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?
(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 ~ #
Created attachment 428228 [details] difference between vanilla and hardened gcc "readelf -d" of testcase
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.)
Created attachment 428246 [details, diff] Patch from Alpine linux for dev-lang/go fixing the issue
(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?
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.
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.
(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
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.
(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?
I was referring to https://github.com/golang/go/issues/6940 which was still open then but seems to be resolved now.
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.
All, is this still an issue for Go 1.7?
(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.
This was fixed in either 1.7.3 or 1.7.4.
