Why are we linking libtsutil.a into all the core plugins?

[ywkaras]

trafficserver/cmake/add_atsplugin.cmake

Line 22 in 33b795f

target_link_libraries(${name} PRIVATE ts::tsapi ts::tsutil)

Could we create both libtsutil.a and libtsutil_link_dummy.so, both with the same contents? Link plugins against the dummy, and only liink traffic_server ELF with libtsutil.a? (libtsutil_link_dummy.so would be an installed library for use when linking non-core plugins.)

[zwoop]

Hmmm yeh why ? This seems like it’d make each binary unnecessarily large too ? Indont know about the dummy thing but this seems bad regardless.

Why would plugins need either ? The symbols are in the core.

[ywkaras]

Hmmm yeh why ? This seems like it’d make each binary unnecessarily large too ? Indont know about the dummy thing but this seems bad regardless.

Why would plugins need either ? The symbols are in the core.

Jason may fatally face-palm if he sees this. It really is helpful to detect what will be load problems due to missing symbols at link time. If we link against the dummy .so, rather than the .a that will be linked into the core executable, the object code will not be pulled into the plugin .so.

[cmcfarlen]

For detecting load problems at build-time, consider this approach instead of complicated linker gymnastics: #11008

https://github.com/apache/trafficserver/pull/11008/files#diff-d76a50ed90f4f3c3cc59631b9348502788e6b29d38f35594880f315e7e517b58R66-R76