5

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).

Dacav
  • 13,590
  • 11
  • 60
  • 87
  • This has nothing to do with autoconf on the system, since you are not running autoconf. – William Pursell Feb 12 '12 at 14:07
  • @WilliamPursell: I'm not, but I'm running the `configure` script. My guess is that the `configure` based compile system can read some configuration from the operating system (e.g. some file in `/etc/`) in order to determine where the OS is expected to find the libraries. – Dacav Feb 13 '12 at 12:28
  • If the configure script is looking in /etc/, that is a bug in the package. I've never seen the behavior you are describing. It may be that you are generating configure scripts with a patched version of autoconf. Does the configure script contain the line "libdir='${exec_prefix}/lib'" ? – William Pursell Feb 13 '12 at 12:41
  • @WilliamPursell, I don't know if the configure script is looking in `/etc/`: it was just a way of saying that this is a system-dependent behavior. A patched version of autoconf is more likely, since the behavior is not concerning a single configure script, but basically every library that I compile manually. – Dacav Feb 13 '12 at 15:02
  • 1
    Is libdir being assigned in /usr/local/share/config.site, or in a $CONFIG_SITE? – William Pursell Feb 14 '12 at 10:45
  • @WilliamPursell: BINGO! That's exactly what I was searching for. Please answer to the question, I'll be happy to accept your answer! Thanks to your answer I've found http://www.delorie.com/gnu/docs/autoconf/autoconf_138.html – Dacav Feb 14 '12 at 15:36

2 Answers2

5

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.

William Pursell
  • 204,365
  • 48
  • 270
  • 300
4

That's a good answer by William Pursell. I just wanted to add, since this question specifically concerns openSUSE, that openSUSE doesn't install a file called config.site. The equivalent file is actually installed into /usr/share/site via the site-config rpm, and then activated via /etc/profile/site.{c,}sh which exports the CONFIG_SITE environment variable to point to this file. That variable is then honoured by autoconf, as you may have already seen.

Adam Spiers
  • 17,397
  • 5
  • 46
  • 65