2

I am compiling a golang package, which includes the integration of a shared c library using cgo. Everything builds successfully inside docker images golang:1.15.15, golang:1.16.6, but since golang:1.16.7 (also golang:1.17) it fails with error:

/usr/bin/ld: src/foobar/lib/libXYZ.so: undefined reference to `feenableexcept'
/usr/bin/ld: src/foobar/lib/libXYZ.so: undefined reference to `floor'
...
/usr/bin/ld: src/foobar/lib/libXYZ.so: undefined reference to `memoFree'
/usr/bin/ld: src/foobar/lib/libXYZ.so: undefined reference to `memoMalloc'
collect2: error: ld returned 1 exit status

I checked the golang release notes, and could not find any relevant changes for cgo.

I checked versions of gcc and ld, those are all different. I even setup a ubuntu distro with go1.13.8, gcc (Ubuntu 8.4.0-3ubuntu2) 8.4.0 and GNU ld (GNU Binutils for Ubuntu) 2.34, where I run into this issue, so I guess, that go goes not cause it.

Do you have any clue or suggestion, how I can find the root cause of this issue? Is it right to check gcc and ld, or which other tools need investigation?

Matthias Wiedemann
  • 1,313
  • 12
  • 22
  • You could try using a tag with fully qualified host OS such as `golang:1.16.6-alpine3.14` to narrow down the cause. The non-qualified ones just install the latest release of every dependency at the time of build. See e.g. https://hub.docker.com/layers/golang/library/golang/1.16.6-alpine3.14/images/sha256-a8df40ad1380687038af912378f91cf26aeabb05046875df0bfedd38a79b5499?context=explore vs. https://hub.docker.com/layers/golang/library/golang/1.16.6/images/sha256-4516c60e1ec5e24ef54f299c1eb711c9d0f49213e7bcd740e5cd261181a3653b?context=explore – Zyl Oct 08 '21 at 13:15

1 Answers1

0

Thanks to Zyl, I was able to narrow down the problem.

I checked several distributions (bullseye, buster, stretch) and with bullseye, the build failed. In my case, neither the version of ld coming from binutils nor gcc caused the problem.

It seems, that the default settings for handling DT_NEEDED tags for the linker have changed. I resolved my problem taking the solution from https://stackoverflow.com/a/62117174/2290153 and adding export CGO_LDFLAGS=-Wl,--no-as-needed to the environment. According to https://manpages.debian.org/bullseye/binutils-common/gold.1.en.html this is the default for the ld.gold linker, but not for ld.

What helped me a lot, was the -x flag of the go build command to have a look at the gcc command being executed for cgo.

Matthias Wiedemann
  • 1,313
  • 12
  • 22