This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]