Compile the go standard library to use external library

Technical Discussion
1

Hi everyone,

We have an in-house filesystem that performs reads, writes, stats and the whole shebang pertaining to what a FS should do. However, the driver is smart, it can figure out what FS it is talking to and depending on that routes the request to the driver code. There is a standard library (stdio.h) wrapper file that creates a shared library (libstd.so) which is used for all the std, io and stuff.

My problem starts here. I have to make a 3rd party tool that does a lot of file reads, writes (written in go) use that shared library. After a week of trying to figure this out I feel like I am grasping at straws here. So I would love some guidance or directions on setting my path straight. Here is what I think is the solution and I might be wrong.

My theory is that if I can compile the standard go packages namely std, io, os and syscalls to somehow use the wrapper based libstd.so file, I can then re-compile the 3rd party tool using dynamic linking and it will work. I started looking at it and saw that it’s the gccgo that’s compiling the standard libraries. So I got into a rabbit hole where I am trying to compile gccgo locally so that I can use that to compile go standard libraries and I am stuck. And thus the questions:

  1. Is my theory correct? And will I have to manually compile the gccgo compiler to use the wrapper libc standard functions?
  2. Is there a better approach to all this?

Thanks for reading through the question. I appreciate your time.
Thanks

2

EDIT: I apologize for the vagueness of this question. However I am trying to figure it out as I am trying to solve it. A clarifying fact about this whole setup.

Right now the application is using go to open files. The go’s io calls is being translated to gccgo’s standard library (libstdio)<- I am not fully confident about this but this might be true. So the filesystem is being mounted to the kernel using FUSE. So the link goes like this app> go’s standard library’s open call> gccgo’s call to libstdio.so > syscalls to kernel > to fuse > to filesystem.

So the application setup is indeed working right now. However it starts failing when at scale. So the idea behind all this is to bypass the entire syslogs thingy to just calling the filesystem calls directly.

3

Go is designed with a modular architecture where the standard library provides core functionalities, and external libraries add specialized features. Compiling the standard library to use an external one would violate this modular design philosophy.