I observe that if you add this line anywhere inside your top-level main() function, it works:

fmt.Println(len(unicode.Categories))

Or even just add this outside the main function:

var z = unicode.Categories

Hence it appears to be something to do with the triggering (or suppression) of package initialization. The documentation says:

When a plugin is first opened, the init functions of all packages not already part of the program are called.

You have already imported "unicode" to access the type unicode.RangeTable, but possibly because you're not accessing any values this has suppressed initialization?

Hum, I have not been able to reproduce this behavior with another variable.

If I add a init function using unicode.Categories in the plugin, there is no reason to remove its initialization.

func init() {
	fmt.Println(len(unicode.Categories))
}

But it prints 0.

$ go build -buildmode=plugin ./p1 && go run main.go
0
unicode.Categories not properly initialized

Yes, what matters is whether the main program initializes unicode (which you can do using "var z = unicode.Categories" in the top-level main.go)

As a complete guess:

• Main program thinks: "I'm not using any variables or functions from unicode, I don't need to initialize it"
• Plugin thinks: "main program already links with unicode, I don't need to initialize it"

I modified your reproducer to demonstrate a similar issue with the regexp library as reported on golang-nuts:

==> go.mod <==
module example.com

go 1.20

==> main.go <==
package main

import (
	"plugin"
	"regexp/syntax"
)

func main() {
	if syntax.Perl != 212 {
		panic("Unexpected flags")
	}

	p, err := plugin.Open("p1.so")
	if err != nil {
		panic(err)
	}
	s, err := p.Lookup("F")
	if err != nil {
		panic(err)
	}

	f := s.(func())
	f()
}

==> p1/plugin.go <==
package main

import (
	"regexp"
)

func F() {
	_ = regexp.MustCompile(`\w+`)
}

func main() {}

$ go version
go version go1.21.0 darwin/amd64
$ go build -buildmode=plugin ./p1 && go run main.go
panic: regexp: Compile(`\w+`): error parsing regexp: invalid escape sequence: `\w`

goroutine 1 [running]:
regexp.MustCompile({0x107aa6eea, 0x3})
	/usr/local/go/src/regexp/regexp.go:319 +0xb4
example.com/p1.F()
	/Users/brian/tmp/go/62430/p1/plugin.go:8 +0x1f
main.main()
	/Users/brian/tmp/go/62430/main.go:23 +0x103
exit status 2

cc @thanm

I haven't looked into this carefully, but I guess this is related to the map initialization change. My guess (without looking into details) is that as the main program imports the unicode package but not explicitly use the map, it initialize the unicode package but not the map. When the plugin is loaded, it sees the unicode package is already initialized by the main program, it doesn't initialize it again, leaving the map uninitialized. Maybe we need to initialize maps for programs that can use plugins.

Supporting what @cherrymui said, I bisected to e2ca417

https://go.dev/cl/463395

Thanks for the report. I will take a look.

Change https://go.dev/cl/526115 mentions this issue: cmd/link: avoid deadcode of global map vars for programs using plugins

The regexp case is almost certainly also due to an uninitialized map, in regexp/syntax/perl_groups.go

var perlGroup = map[string]charGroup{
        `\d`: {+1, code1},
        `\D`: {-1, code1},
        `\s`: {+1, code2},
        `\S`: {-1, code2},
        `\w`: {+1, code3},
        `\W`: {-1, code3},
}

@gopherbot please backport this to Go 1.21. This is a regression that causes valid programs to run incorrectly.

Backport issue(s) opened: #62505 (for 1.21).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

Change https://go.dev/cl/526575 mentions this issue: cmd/link: avoid deadcode of global map vars for programs using plugins