-
Notifications
You must be signed in to change notification settings - Fork 778
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why are we linking libtsutil.a into all the core plugins? #11032
Comments
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. |
For detecting load problems at build-time, consider this approach instead of complicated linker gymnastics: #11008 |
trafficserver/cmake/add_atsplugin.cmake
Line 22 in 33b795f
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.)
The text was updated successfully, but these errors were encountered: