Of course bstdc++.so.6.0.14-gdb.py is not an ELF file.  But what is the bug?

Subject: Re:  libstdc++.so.6.0.14-gdb.py is not an ELF
 file

Some people dislike a few warnings from ldconfig.  I think having this as 
a text file alongside the library is much better than alternative 
suggestions of embedding it in the library in some way; for one thing, a 
separate text file is much easier to adjust when libraries from a native 
build are being used in a cross environment, or from a cross build are 
being used in a native environment, and the relative positions of 
pythondir and libdir need changing.

What's the status here? Any chance we could frame the subject as something that has conflict, instead of a statement everyone agrees with?

ldconfig warnings vs. libstdc++.so.6.0.14-gdb.py

would it be possible to get a configure flag specifying where to install these files, which we could then set to gdb's auto-load directory?

(In reply to comment #4)
> would it be possible to get a configure flag specifying where to install these
> files, which we could then set to gdb's auto-load directory?

Google has a tough time with the search string unless you break it up since _some_ WebPages add spaces between various parts of the string. (EG: "/ usr / local / lib / libstdc + +. so.6.0.14-gdb.py").


There is this (as best I can tell from the translation) suggested fix:

Korean -> English: http://translate.google.ca/translate?hl=en&sl=ko&u=http://lunatine.springnote.com/pages/6524343&ei=PCcpTanIOITWtQOU18H9Bg&sa=X&oi=translate&ct=result&resnum=1&ved=0CB4Q7gEwAA&prev=/search%3Fq%3D%2522/usr/local/lib/libstdc%252B%252B.so.6.0.14-gdb.py%2522%2BGDB%2B7.2%2Binstallation%26hl%3Den%26biw%3D1177%26bih%3D764%26prmd%3Divns

Origonal URL: http://lunatine.springnote.com/pages/6524343

Rob

Why don't we just install this file in /usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0/ instead of $(DESTDIR)$(toolexeclibdir)/ by default?


BTW Gentoo does this by default:

	# Move pretty-printers to gdb datadir to shut ldconfig up
	gdbdir=/usr/share/gdb/auto-load${LIBPATH/\/lib\//\/$(get_libdir)\/}
	for i in "${D}"${LIBPATH}{,/32}/*-gdb.py; do
		if [[ -e ${i} ]]; then
			basedir="$(dirname ${i/${D}${LIBPATH}/})"
			sed -i -e "s:^\(libdir = \).*:\1'${LIBPATH}${basedir}':" "${i}" #348128
			insinto "${gdbdir}${basedir}"
			doins "${i}"
			rm "${i}"
		fi
	done

(In reply to comment #6)
> Why don't we just install this file in
> /usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0/ instead of
> $(DESTDIR)$(toolexeclibdir)/ by default?

Who's "we"?

I have several versions of GDB and GCC installed, which GDB data dir should I put the printers in, all of them?  That would need root access in some cases.

> BTW Gentoo does this by default:

Gentoo is a distro and can decide to put the system compiler's files in the system debugger's data dir, not everyone who installs GCC can do that.

(In reply to comment #7)
> (In reply to comment #6)
> > Why don't we just install this file in
> > /usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0/ instead of
> > $(DESTDIR)$(toolexeclibdir)/ by default?
> 
> Who's "we"?

The big other :-)

> I have several versions of GDB and GCC installed, which GDB data dir should I
> put the printers in, all of them?  That would need root access in some cases.

All versions of GDB would look into the same directory structure. And there
would be one subdirectory for each different GCC version.
And of course you'll need root access in this case, but *we* could fall
back to the current location for a installation without root access.

Hmm yes, this is only really an issue for people who install libstdc++ into a directory that ldconfig searches, which for most people means it only affects the system compiler, which means distros can fix it for their users as Gentoo does.

For everyone who installs GCC themselves without root access, they probably don't get the ldconfig warnings anyway, so don't care.

A config option allowing that to be automated would make things a little easier for those who do want to move the file.

Several years have passed. Closing