the problem is that configure searches for libexpat in /lib, /usr/lib, etc (the 'normal' library paths), and completely ignores /usr/${CHOST}/usr/lib ... actually the best solution is to remove the searching routines and just use '-lexpat', which lets the compiler decide which shared library / archive to link against. It should be no trouble to put a patch together, I'll see what I can do. Reproducible: Always
no actual information as to what problem you're having. the expat check in gdb is using the perfectly standard autoconf code.
Created attachment 255317 [details] build.log of sys-devel/gdb-7.0.1
Created attachment 255319 [details] armv4tl-softfloat-linux-gnueabi-emerge --info
=== configuring in common ... checking for libexpat... no configure: error: expat is missing or unusable ... config.log says that it's trying to use /usr/lib/libexpat.so rather than the one that the linker would choose to use in /usr/${CHOST}/usr/lib. It works fine when building for the same architecture, but for cross compiling, it's broken.
Created attachment 255321 [details] gdb-7.0.1/gdb/config.log
my solution was to patch the autoconf scripts to use LIBEXPAT='-lexpat' rather than the first one that it found via a search in /lib /usr/lib, etc. Maybe this could be solve by setting PKG_CONFIG_PATH... I haven't checked.
expat doesnt provide a pkg-config .pc file, nor does the code use pkg-config to discover expat, so it wouldnt work i cant see any place where that /usr/lib/... is coming from. all my local tests show it doing the right thing and only using -lexpat, and the autoconf code looks correct to me too. you'll have to go into the gdb-7.0.1/gdb/ subdir and manually run configure through `bash -x` and see if you have the same problem. and if you do, post that output as an attachment.
