build: dyld: Symbol not found: _fdopendir$INODE64 on OS X 10.9 Mavericks

[probonopd]

What version of Go are you using (go version)?

go1.13.3.darwin-amd64.tar.gz

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

OS X 10.9.5 Build 13F34

What did you do?

Running OS X 10.9.5 Build 13F34, downloaded go1.13.3.darwin-amd64.tar.gz. Trying to run it

What did you expect to see?

Working go command

What did you see instead?

sh-3.2# export PATH=$PATH:/usr/local/go/bin
sh-3.2# go
go             gobject-query  gofmt          
sh-3.2# go
dyld: Symbol not found: _fdopendir$INODE64
  Referenced from: /usr/local/go/bin/go
  Expected in: flat namespace

Trace/BPT trap: 5

Before this is closed with "too old OS version": One of the main advantages of Go imho is that it is statically compiled and hence should run independent from the libraries shipped with the OS. Hence it would be highly appreciated if this could be made work, or at least explained why it is not possible.

It used to work in

sh-3.2# go version
go version go1.10.8 darwin/amd64

What has changed to make this no longer work?

Could https://github.com/macports/macports-legacy-support be used to fix this, especially macports/macports-ports@abe46d0?

[ianlancetaylor]

According to https://github.com/golang/go/wiki/MinimumRequirements Go 1.13 only supports macOS 10.10 and higher.

[probonopd]

Yes. Why?

[ianlancetaylor]

See #23011 and #23122.

[probonopd]

• all: announce end of support for old macOS releases #23011 does not contain a technical reason for why OS X 10.9 cannot be supported any longer, if I have not overlooked something
• all: remove support for OS X 10.8 and 10.9 #23122 just implements the removal of support for OS X 10.9

Not everyone can run the latest versions of macOS for various reasons. I would like to know what is technically preventing the latest Go versions to work on older Mac OS X and OS X versions.

[ianlancetaylor]

You are correct: the decision to drop support for older macOS releases was not made for technical reasons. We have limited resources. We do not want to support releases for which we do not run builders. We do not want to run builders for releases that are not receiving security updates. So we chose to drop support.

The only thing I know of that technically prevents the latest Go versions from running on old macOS versions is this issue that you have just filed. If you want to analyze this issue and find a fix and send in the fix, we would probably consider it if it is not too invasive. But we do not consider ourselves responsible for fixing the issue. We prefer to focus our limited resources on newer versions. We aren't even running the old systems that we would need to run to analyze and test any fix.

Older versions of Go should continue to work fine on older versions of macOS.

I'm sorry that this is likely not the answer you want to hear, but I think it is better to be realistic about what we can accomplish.

[probonopd]

We prefer to focus our limited resources on newer versions.

Why? Wouldn't it be more reasonable to focus the limited resources on the oldest possible Mac OS X release and delegate the duty to keep things binary compatible to Apple (read: if they break compatibility, blame them)?

[ianlancetaylor]

Clearly Go must support current versions of the operating system. Evidence shows that each new macOS release requires adjustments by Go. For example, right now there are several bug reports for the Catalina release (#34935, #35177, #35247). We are going to have to investigate and fix those problems. It would be nice if we could say "oh, that's Apple's fault, ask them to fix it," but in reality that clearly won't work. Apple's interest in supporting programs that are not created by Apple approved toolchains is very small. We have to accommodate them. They are unlikely to accommodate us.

Since we must spend time on macOS support, I think it is clearly better to spend that time on current macOS versions rather than old ones.

[probonopd]

Argh.

In any case, https://github.com/macports/macports-legacy-support seems to add the missing fopendir. Could macports-legacy-support be used to make Go work on less-than-recent systems? cc @kencu

[ianlancetaylor]

I'm likely missing something but I don't see how the macports-legacy-support repo would help. That is for C programs, not Go programs.

Have you tried downloading the source code for Go and building it yourself as described at https://golang.org/doc/install/source, instead of using the binary download?

[probonopd]

I'm likely missing something but I don't see how the macports-legacy-support repo would help. That is for C programs, not Go programs.

From looking at its description I was under the impression that macports-legacy-support contains implementations of some symbols that older Mac OS X, Mac OS, and macOS versions are lacking, in order to enable software built for later versions to run on earlier versions of the system. Hence I thought it might be a way to allow Go to run on earlier versions without having to be built on earlier versions (something the Go project wants to avoid due to the additional work).

I have not tried to build Go myself on the Mac, since my use case is a bit different: I would like to build Go applications on Linux, and run them on OS X 10.9.

[kencu]

Hi. Yes -- in MacPorts, one of our members, @Ionic , has been working with this with some success. https://github.com/macports/macports-ports/blob/52f3f71c33a430c6046efdddf9cce347ae2de3db/lang/go/Portfile#L68 . It currently does require a manual step to enable linking in the legacysupport library that contains the extra functions that perhaps we might automate one day.

@Ionic has also been working on an enhanced version of this of late, https://trac.macports.org/ticket/58935 that we are / I am just trying to fully wrap my head around. But it is do-able, it appears.

[Ionic]

Yes, MP legacy support can be used to get go working again.

Yes, MP legacy support is currently "broken" because it doesn't generate the needed symbols (for newer go versions).

Yes, I have modified the build environment to generate them, based on architecture.

No, I haven't made a PR for MP legacy support yet because I a.) am lazy, b.) was waiting for some review for obvious errors, though I guess there aren't any really and c.) was occupied with other things in the meantime.

I guess that go is right in using the suffixed symbol versions, there doesn't seem to be a bug in go as such. It's just unfortunate that older OS X/macOS versions don't provide it.

MP legacy support can naturally also be used outside of MacPorts (I do find the name a bit unfortunate, but I understand that it originated there), but even with a working go build, users of go will need to build their programs with special flags on older operating system versions to get a working binary (or one in the first place).

[Ionic]

This said, I consider this a hack to make go work on older platforms - not something that could be reasonably incorporated into go itself.

The other point is that, if go actually needs the fdopendir function, it doesn't make sense to not limit the supported platforms to those that provide it out of the box. The alternative would be to avoid using it xor, if needed, emulate it within go itself, which would increase maintenance load. Probably not a smart decision for the upstream project.

I do, however, see it as a working solution for downstream package systems, even though not fully automatic/transparent to end users.

[kencu]

As a tiny bit of help, how would one add a link support/runtime library to a go build automatically? I assume go must have a list of libraries it links in to the build somewhere (and clearly I'm demonstrating my lack of go fu here). If we could have that -lLegacySupport library linked in without adding in an external step, that would be helpful.