This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: [patch] Fix glitches with libstdc++ pretty printers
Tom> Let me know what you think. I think I will check this in now; we can
Tom> always revert it if we prefer a different approach. If we agree on
Tom> this direction, I'll write the documentation.
Daniel> I don't want to end up with a solution that depends on shared
Daniel> libraries. I've got plenty of use for this outside of Linux,
Daniel> and a lot of our users work only with static libraries. Just saying -
Daniel> let's not forget about that entirely.
Yeah, this is the same problem as header-only libraries -- there is no
separate objfile.
My current thinking is that this is the application author's problem.
That is, when doing the static-link-equivalent is also the best place
to note the dependencies.
There are some python-script management problems here, but nothing too
outrageous. I think it can mostly be boiled down to: if you ship a
static library, you should also ship the .py.
Then at link time the application Makefile could also dig around for
.py scripts and concatenate them into a new one for the application.
Daniel> I did like Jan's idea of matching the debug file search. That
Daniel> lets us keep GDB files outside of /usr/lib directly.
We get this for free, because we do the same loading for the objfile
that is created when gdb reads the separate debug info.
For Fedora I think we may pull the .py files into the separate debug
RPMs automatically. Though, I am not completely sure -- it seems to
me that perhaps users would want to pretty-print libstdc++ containers
without necessarily installing all of its debug info.
Tom