On 04/20/2016 07:02 AM, Yury Gribov wrote: > Pedro, > > Do you think the above is doable for gdb?
I don't know -- I'm already juggling too many balls in the air, and I'm afraid that if that depends on me, it'll take a while before I'll manage to try. Since gdb's use of private symbols is not an isolated incident, I don't think we should try to clean up all packages that make use of private symbols, in a rush. Instead, I think readline needs to take a staged approach: - Export all the private symbols that programs are using today. Simply accept today's reality. The dynamic symbol table of libreadline.so still shrinks, precedent for visibility annotations is still set, and private symbol leakage is contained, because future software will no longer be able to abuse all the other private symbols that are not exported. - Claim that the symbols may no longer be available in a future release. - Give time for packages to clean themselves up, and propose any necessary new replacement APIs. - Optionally, in the release after the next, mark the symbols as deprecated with __attribute__((deprecated)), so packages that abuse private symbols get a build-time warning. - In some future release, stop exporting the symbols. > That would of course leave the > problem of linking older gdb with new readline which will need to be > resolved by distros. Right. Thanks, Pedro Alves _______________________________________________ Bug-readline mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-readline
