Improving internal module usage workaround and go compiler patch

[dann-merlin]

I'm exploring the possibility of using goloader and kind of dislike the approach of copying the module files. I was wondering if there was a less invasive approach.

I tried just copying the folder into the local directory, but this again did not work, as it was using the internal module in goloaders code. However I successfully compiled goloader by creating a symlink instead:

cd jit
ln -s $GOROOT/src/cmd/internal ./objfile

Would this be a feasable workaround? It seems so simple, so I'm kind of guessing that there's a good reason it's not already done this way ^^

In the same vein: I was wondering if there could also be a workaround to having to patch the go compiler If you would not patch it, would goloader still work, but crash in the case of type mismatches? Or is this patch a necessity?

[eh-steve]

The symlink works when compiling that package but is less useful if you want to import goloader into arbitrary other modules. You’d need to symlink it to a path that everyone has, or every time you want to use it.

As for the compiler patch, this is purely to provide the equivalent of a ptab without needing to make the JIT package a plugin (main). If you don’t patch it, exported symbols won’t be associated with their corresponding GoTypes and so an interface{} can’t be constructed.

The patch has an upstream CL and proposal

[dann-merlin]

Thanks for your response! Looks like the compiler patch issue might soon be fixed. Nice work!

Concerning the symlink, I'm not sure if I fully understand it yet, so let me try to summarize: If goloader is changed to use that symlink workaround, any project that used this goloader version would need to have the go library at the same absolute path (which is obviously bad). But loaded code would not be affected by this, right?

So if I distribute a binary that uses such a modified goloader module and users that have a different directory structure would try to load a go module with it, would that still work?

Because in this case, I might just use goloader as a git submodule, let Go use that submodule instead and in my build script I would dynamically change the symlink appropriately, such that it is correct at compile time.

[eh-steve]

I’m still not sure how making a system-specific symlink at compile time is much better than a system-specific copy?