Create .so file(s) with symbol definitions for the plugin API

[bneradt]

it would be helpful to have the symbols declared in include/ts built into a separate .so file (or maybe files) for its definitions rather than having them all defined in traffic_server.

[bneradt]

Zhengxi Li is currently looking into implementing this, but we cannot officially assign him because he is not a committer yet. I'll assign myself as a proxy.

[jpeach]

it would be helpful to have the symbols declared in include/ts built into a separate .so file (or maybe files) for its definitions rather than having them all defined in traffic_server.

What would be the use case for that?

[bneradt]

it would be helpful to have the symbols declared in include/ts built into a separate .so file (or maybe files) for its definitions rather than having them all defined in traffic_server.

What would be the use case for that?

Presently, the InkAPI symbols are all linked in directly to the traffic_server binary, so plugins have no .so to link against and verify symbols against. It would be handy to have an .so for plugins to link against.

@bryancall has also seen binary compatibility issues in registers across minor releases that we're hoping the compiler will not produce if the symbols are built into a library.

There is a plan to discuss this further in the summit either tomorrow or the next day.

[jpeach]

I see. IIUC, if you actually separate the API symbols into a different DSO, then all their dependencies would either need to be in that DSO, or resolved from the traffic_server binary. Neither sounds ideal, unfortunately.

[bryancall]

@jpeach What is the issue of resolving the symbols that are in the traffic_server binary that the API DSO depends on?

I wrote up and example of how this would work: https://github.com/bryancall/plugin_dso

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. Marking it stale to flag it for further consideration by the community.