Believe me, it's not something I want to do. But, it's the only way that building a Go program with dynamic linking will work.
Here's what I mean: % go build -linkshared file1.go internal/abi: go build internal/abi: copying /home/jonf/.cache/go-build/06/0628acf114fffa5bc27f637027df97345926fcd84fc223b7965e9a29abc9a2fc-d: open /usr/local/go/pkg/linux_amd64_dynlink/internal/abi.a: permission denied runtime/internal/math: go build runtime/internal/math: copying /home/jonf/.cache/go-build/c5/c50274855cf2c87ce7f9579d93ecbd945ce2a2fc71064b9baaf8c7fa9bc1fac9-d: open /usr/local/go/pkg/linux_amd64_dynlink/runtime/internal/math.a: permission denied runtime/internal/sys: go build runtime/internal/sys: copying /home/jonf/.cache/go-build/59/59f10e728f337902b572dc91cc0fa5babba58786fd6b3855a08c37de6826f987-d: open /usr/local/go/pkg/linux_amd64_dynlink/runtime/internal/sys.a: permission denied internal/bytealg: go build internal/bytealg: copying /home/jonf/.cache/go-build/e5/e55aca54d406715f95c5cdda5149a53efe34e68759cdeef7658c207f69380f6e-d: open /usr/local/go/pkg/linux_amd64_dynlink/internal/bytealg.a: permission denied math: go build math: copying /home/jonf/.cache/go-build/66/66ea7240358ed8a641ab6dcd3ce290a817f633146c68b5cf98e56c2b35e5fa9c-d: open /usr/local/go/pkg/linux_amd64_dynlink/math.a: permission denied image/color/palette: go build image/color/palette: copying /home/jonf/.cache/go-build/42/4250f9f38ffaf1e12f6a1e123bbb5e9323aebdcdf4dd65e7bbb4fb700763c5a7-d: open /usr/local/go/pkg/linux_amd64_dynlink/image/color/palette.a: permission denied crypto/internal/boring/bcache: go build crypto/internal/boring/bcache: copying /home/jonf/.cache/go-build/8b/8b887de65adc0f4d5c4ecd00452f5c26f909f2a22bde7195b185ad4121060ac3-d: open /usr/local/go/pkg/linux_amd64_dynlink/crypto/internal/boring/bcache.a: permission denied slices: go build slices: copying /home/jonf/.cache/go-build/09/09413e8fd6fd3d702b748ad7da013e04bca8ab23206c0cf1c815be383ec5f14f-d: open /usr/local/go/pkg/linux_amd64_dynlink/slices.a: permission denied Do you perhaps have write permission to /usr/local/go? Then there's also the question of why building a Go program should write to /usr/local/go/pkg/linux_amd64_dynlink. Jon On Saturday, August 12, 2023 at 1:01:22 PM UTC-7 Ian Lance Taylor wrote: > On Sat, Aug 12, 2023 at 10:27 AM jlfo...@berkeley.edu > <jlfo...@berkeley.edu> wrote: > > > > Thanks. > > > > There's a more fundamental problem, though. Try running > > > > go build -linkshared hello.go > > > > as a non-privileged user. You'll get a bunch of permission denied > messages. (I had mentioned this > > back in January). This is why I'm fooling around running the compiler > and linker manually. > > > > I suggest you add this to your test suite. > > To be clear, I ran all the commands I listed as a non-privileged user. > > It's not clear why you are running any of the commands as root. > > Ian > > > > On Friday, August 11, 2023 at 10:00:12 PM UTC-7 Ian Lance Taylor wrote: > >> > >> On Fri, Aug 11, 2023 at 6:15 PM jlfo...@berkeley.edu > >> <jlfo...@berkeley.edu> wrote: > >> > > >> > Now that Go 1.21 has been released, I've returned to trying to figure > out how to > >> > dynamically link a Go program. Back in January I posted the results > of my first attempt > >> > with an earlier version of Go, which was: > >> > > >> > 1) Building a Go shared library by running > >> > > >> > go install -buildmode=shared std > >> > > >> > as root works fine. > >> > > >> > 2) Building a dynamically linked Go executable as a non-privileged > user by adding > >> > > >> > -linkshared > >> > > >> > to "go build" fails with lots of file access permission errors because > >> > the go build tool tries to write to the Go shared library, which a > non-privileged > >> > user can't do. > >> > > >> > 3) Building a dynamically link Go executable as root works but a new > version > >> > of the Go shared library gets made in the process. This makes this > command > >> > take much longer than it should. Plus, having to be root is a > non-starter. > >> > > >> > I started looking at what "go build" is doing by adding the "-x" > option. > >> > I was able to figure out how to build and link the following program > >> > > >> > package main > >> > func main() { > >> > } > >> > > >> > using a shared library. This was quite an accomplishment. But, then I > tried making it into > >> > a "Hello, world!" program. > >> > > >> > package main > >> > import "fmt" > >> > func main() { > >> > fmt.Println("Hello, world!\n") > >> > } > >> > > >> > This also compiles and links, but running it results in > >> > > >> > panic: runtime error: invalid memory address or nil pointer > dereference > >> > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 > pc=0x7fe02814e593] > >> > > >> > goroutine 1 [running]: > >> > os.(*File).write(...) > >> > /usr/local/go/src/os/file_posix.go:46 > >> > os.(*File).Write(0x0, {0xc0003a6000?, 0xf, 0x7fe028059f25?}) > >> > /usr/local/go/src/os/file.go:183 +0x53 > >> > fmt.Fprintln({0x202f88, 0x0}, {0xc00035af20, 0x1, 0x1}) > >> > /usr/local/go/src/fmt/print.go:305 +0x6f > >> > fmt.Println(...) > >> > /usr/local/go/src/fmt/print.go:314 > >> > > >> > To compile the program I ran > >> > > >> > WORK=/tmp/go-build3183434751 > >> > /usr/local/go/pkg/tool/linux_amd64/compile -p main -complete > -installsuffix dynlink -goversion go1.21.0 -c=3 -dynlink -linkshared > -nolocalimports -importcfg $WORK/b001/importcfg ./file1.go > >> > > >> > and to link it I ran > >> > > >> > WORK=/tmp/go-build3183434751 > >> > /usr/local/go/pkg/tool/linux_amd64/link -o a.out -importcfg > $WORK/b001/importcfg.link -buildmode=exe -linkshared -w file1.o > >> > > >> > $WORK/b001/importcfg is > >> > packagefile fmt=/usr/local/go/pkg/linux_amd64_dynlink/fmt.a > >> > packagefile runtime=/usr/local/go/pkg/linux_amd64_dynlink/runtime.a > >> > packagefile > runtime/cgo=/usr/local/go/pkg/linux_amd64_dynlink/runtime/cgo.a > >> > > >> > $WORK/b001/importcfg.link is many lines like > >> > packagefile fmt=/usr/local/go/pkg/linux_amd64_dynlink/fmt.a > >> > packageshlib fmt=/usr/local/go/pkg/linux_amd64_dynlink/libstd.so > >> > > >> > Both these files were created when I ran the regular "go build > -linkedshare" command. > >> > I have to admit that I don't really understand what these files > should contain, > >> > and I wouldn't be surprised if this is what's causing my problem. > >> > > >> > Any suggestions for what I'm doing wrong? > >> > >> Thanks. This looks like a bug. Somehow we must not be testing quite > >> this case in our -buildmode=shared testsuite. > >> > >> I opened https://go.dev/issue/61973. > >> > >> Ian > > > > -- > > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/b644a419-b3a7-4021-9e1c-b8954e07000cn%40googlegroups.com > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f6984042-e692-46ba-b9f3-6d9c2ad8290an%40googlegroups.com.