A project I'm working on uses a non-standard distribution system, which internally downloads and compiles the dependency libraries. This crock launches, for each library, the configure script giving as prefix an internal directory of the compiling system. Then it runs make and make install, then it verifies the content by searching the install directory with the lib/<mylib>.a file. This last step fails.
Trying to understand what's happening, I compiled a pair of random libraries by myself, including one I'm the author of. I noticed that under my distribution (openSUSE, 64 bit) the installing path is not populated with /lib, but with /lib64 instead.
It's clear that this is a setting of the distribution, and I'm pretty sure that this setting concerns a configuration of autotools shipped with the distro.
Is there a way of changing this behavior or, as an alternative, to read this information from the system (so that I can patch the above mentioned crock)?
Thanks for your help
Update: I learnt about the --libdir flag in configure, so I think I can solve my problem. Still I would like to know if there's a way of knowing this detail from somehow querying the distribution (e.g. read some configuration file).
The configure script should never try to make assumptions about the machine, or attempt to install libraries in locations other than ${exec_prefix}/lib unless the user explicitly requests a different location for $libdir. One mechanism by which the user can explicitly request an alternate location is through a config.site file. If the file ${prefix}/share/config.site exists, it may specify an alternate value for $libdir, causing the user to unknowingly explicitly specify an alternate installation location.