[Bug go/114699] New: gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete so libraries crash when dlclosed

["rjones at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 114699
           Summary: gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete
                    so libraries crash when dlclosed
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: rjones at redhat dot com
  Target Milestone: ---

I was chasing a crash in nbdkit-golang-plugin
(https://gitlab.com/nbdkit/nbdkit/-/tree/master/plugins/golang?ref_type=heads).

This crash only happens with gcc-go (and quite reproducibly), but doesn't
happen with golang.  The crash happened when the plugin was being unloaded
with dlclose(3).

Long story short, this is a bug that has already been reported and "fixed"
(or more accurately, worked around) in golang:

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

Because goroutines, the garbage collector, etc is basically running all
the time in golang programs, you cannot safely remove them from memory.
Any attempt to actually dlclose a golang plugin will crash most of the
time when a goroutine/the GC executes some code after dlclose.

golang works around this by linking shared libraries it creates with
-Wl,-z,nodelete:

https://github.com/golang/go/blob/1843464f014c946c1663de76249267486887626f/src/cmd/link/internal/ld/lib.go#L1587

Because gcc-go doesn't do this, the same shared libraries crash when
compiled with it.

Fix (or workaround) is probably to copy what golang does.