Despite being compiled with the "multitarget" useflag, gdb refused to read an vmlinux file of x86_64 type, saying that the file format was not recognized. The problem can be solved by adding "--enable-64-bit-bfd" to the configure flags passed by econf to the toplevel configure. So far, the modified package compiles and runs on x86 and x86_64, but I haven't yet tested what happens if specifying 64bit in USE but not multitarget. --- metadata.xml.orig 2010-08-02 17:25:41.000000000 +0200 +++ metadata.xml 2010-08-02 17:26:27.000000000 +0200 @@ -4,5 +4,6 @@ <herd>toolchain</herd> <use> <flag name='multitarget'>Support all known targets in one gdb binary</flag> + <flag name='64bit'>Also support 64 bit bfd targets on non 64 bit platforms</flag> </use> </pkgmetadata> --- gdb-7.1.ebuild.orig 2010-03-19 03:21:14.000000000 +0100 +++ gdb-7.1.ebuild 2010-08-02 17:19:38.000000000 +0200 @@ -24,7 +24,7 @@ && SLOT="${CTARGET}" \ || SLOT="0" KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sparc ~x86 ~x86-fbsd" -IUSE="expat multitarget nls python test vanilla" +IUSE="64bit expat multitarget nls python test vanilla" RDEPEND=">=sys-libs/ncurses-5.2-r2 sys-libs/readline @@ -62,6 +62,7 @@ $(use_with expat) \ $(use_enable nls) \ $(use multitarget && echo --enable-targets=all) \ + $(use 64bit && echo --enable-64-bit-bfd) \ $(use_with python) \ || die emake || die
i think the reason they're split is due to overhead of 64bit types on 32bit systems, but if you're using USE=multitarget, i think we can ignore it. so i'll have USE=multitarget imply 64-bit-bfd rather than creating a dedicated USE flag.
(In reply to comment #1) > i'll have USE=multitarget imply 64-bit-bfd rather than creating a > dedicated USE flag. Yes, multitarget certainly does imply that. As I see now, toolchain-binutils_src_compile() even enables 64bit support unconditionally, independently from having "multitarget" in USE flags or not. I used the (elsewhere preexisting) flag, because I wondered why the gdb/binutils folks treated that case separately. Maybe because there exist(ed) platforms where "--enable-64-bit-bfd" tend(ed) to break the package. An even more consistent solution would remove gdb's static local copy of libbfd (well, there are more ...): 686-pc-linux-gnu-gcc -march=pentium4 -mtune=pentium4 -g -O2 -pipe -Wall -Wl,-O1 -Wl,--as-needed -o gdb gdb.o libgdb.a ../readline/libreadline.a ../opcodes/libopcodes.a ../bfd/libbfd.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lncurses -lz -lm -lpython2.6 /usr/lib/libexpat.so ../libiberty/libiberty.a gnulib/libgnu.a -ldl -rdynamic ^(btw, this absolute reference to libexpat.so may manifest itself as just another bug while cross compiling) But weeding out bfd could be difficult. eselect binutils could handle that, if amended for also creating symlinks in /usr/lib: find /usr/lib -iname libbfd\* /usr/lib/binutils/i686-pc-linux-gnu/2.20.1/libbfd.a /usr/lib/binutils/i686-pc-linux-gnu/2.20.1/libbfd.la /usr/lib/binutils/i686-pc-linux-gnu/2.20.1/libbfd-2.20.1.20100303.so /usr/lib/binutils/i686-pc-linux-gnu/2.20.1/libbfd.so /usr/lib/binutils/i686-pc-linux-gnu/2.20/libbfd.a /usr/lib/binutils/i686-pc-linux-gnu/2.20/libbfd.la /usr/lib/binutils/i686-pc-linux-gnu/2.20/libbfd.so /usr/lib/binutils/i686-pc-linux-gnu/2.20/libbfd-2.20.so
yeah, i'll just add --enable-64-bit-bfd with the next gdb version unconditionally as for the other points, short answer is: no gdb is closely tied to all of the local libraries that are bundled with it and designed to be statically linked. it would be an absolute nightmare to attempt to have gdb re-use the libraries binutils. it simply isnt going to happen. libtool takes care of expat linking ... no bug in the build system there i dont use eselect binutils, but same answer applies as above.
included with gdb-7.2 http://sources.gentoo.org/sys-devel/gdb/gdb-7.2.ebuild?r1=1.1&r2=1.2
