$ rpm -qf /usr/lib/libexpat.la expat-devel-1.95.8-8.2.1 libtool is pretty stupid, and is trying to use the .la file from /usr/lib, instead of /usr/lib64 /bin/sh ../../libtool --tag=CC --mode=link gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o libgstneonhttpsrc.la -rpath /usr/lib64/gstreamer-0.10 -module -avoid-version -export-symbols-regex '^_*gst_plugin_desc$' libgstneonhttpsrc_la-gstneonhttpsrc.lo -Wl,--export-dynamic -pthread -L/lib64 -lgstbase-0.10 -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lxml2 -lglib-2.0 -L/usr/kerberos/lib64 -lneon -lssl -lcrypto -lz -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl -lexpat generating symbol list for `libgstneonhttpsrc.la' /usr/bin/nm -B .libs/libgstneonhttpsrc_la-gstneonhttpsrc.o | sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | /bin/sed 's/.* //' | sort | uniq > .libs/libgstneonhttpsrc.exp grep -E -e "^_*gst_plugin_desc$" ".libs/libgstneonhttpsrc.exp" > ".libs/libgstneonhttpsrc.expT" mv -f ".libs/libgstneonhttpsrc.expT" ".libs/libgstneonhttpsrc.exp" echo "{ global:" > .libs/libgstneonhttpsrc.ver cat .libs/libgstneonhttpsrc.exp | sed -e "s/\(.*\)/\1;/" >> .libs/libgstneonhttpsrc.ver echo "local: *; };" >> .libs/libgstneonhttpsrc.ver gcc -shared .libs/libgstneonhttpsrc_la-gstneonhttpsrc.o -L/lib64 -lgstbase-0.10 -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2 -lglib-2.0 -L/usr/kerberos/lib64 -lneon -lssl -lcrypto -lz -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl /usr/lib/libexpat.so -m64 -mtune=generic -Wl,--export-dynamic -pthread -Wl,-soname -Wl,libgstneonhttpsrc.so -Wl,-version-script -Wl,.libs/libgstneonhttpsrc.ver -o .libs/libgstneonhttpsrc.so /usr/lib/libexpat.so: could not read symbols: File in wrong format
Removing the .la is fixing the symptom not the cause. Why is libtool looking in /usr/lib not /usr/lib64? What package is this?
Removing .la files is also required as per the packaging guidelines: http://fedoraproject.org/wiki/Packaging/Guidelines#head-2302ec1e1f44202c9cc4bcce24cb711266557ad7 The package I'm trying to compile is gstreamer-plugins-bad (which isn't in Fedora proper). If you fancy fixing libtool, be my guest :) My best guess is that it's a remanescence of libtool not accepting /usr/lib64 as the same as /usr/lib64/
It's not required, it's advised; removing it in this case is not possible since it breaks the apr-util build IIRC (it was tried before). Regardless: every other package in the distro manages to link against expat in the presence of this file, so there is clearly something more subtle going wrong with the broken gstreamer-plugins-bad build. Mail me a link to a source RPM and I'll take a look.
The .la files also break the build of Avahi and dbus-glib (from tarballs anyway, don't know what our packages do - perhaps the packages are built in a build root without both 32 and 64 bit expat installed?). Just removing the .la files fixes these builds. .la files = evil, evil, broken idea; all they ever do on Linux is override other flags and env variables when you don't want them to.