On Jun 13, 2011, at 8:30 PM, Christopher Samuel wrote:
> Well oddly only one of the 2 locations had been built
> (the one with the makelog), but just in case I've redone
> it from scratch - compressed and attached.
Ok, these seem consistent. Thanks!
It looks like our test might not be hitting the same corner case as the final
executable:
-----
configure:10145: checking for pci_init in -lpci
configure:10170: gcc -o conftest -I/usr/local/rsync/3.0.7/include
-I/usr/local/openmpi/1.4.2-intel/include -L/usr/local/rsync/3.0.7/lib
-L/usr/local/openmpi/1.4.2-intel/lib conftest.c -lpci >&5
configure:10170: $? = 0
configure:10179: result: yes
-----
Meaning: we had no problem linking against libpci.a in configure. So the hwloc
build continued.
I can only assume that we're invoking some other libpci function in the code
base that eventually ends up invoking other internal libpci functions that end
up needing the __res_query symbol. Since linkers only pull in the relevant
.o's from libraries (as determined by symbol-linking graphs), this seems like a
plausible explanation.
So I guess we need to add another test to configure -- to see if we need to
explicitly link in -lresolv.
Chris -- can you try linking this simple app to see if it causes the linker
error, and further try adding -lresolv to see if that fixes the error?
------
#ifdef __cplusplus
extern "C"
#endif
char pci_lookup_name ();
int
main ()
{
return pci_lookup_name ();
;
return 0;
}
-----
Try with:
gcc -o conftest conftest.c -lpci
gcc -o conftest conftest.c -lpci -lresolv
FWIW, on my RHEL 5 machine (with only libpci.a), both link commands seem to
work (but my libpci.a doesn't have a __res_query symbol).
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
