I'm having trouble building a few Autotool-based libraries on Fedora 26, x86_64. The 64-bit Fedora puts third party and vendor libraries in /usr/local/lib64
. Ubuntu 17 uses /usr/local/lib
so the same projects build OK.
I've been using --libdir=/usr/local/lib64
but three libraries resist it. I lack a config.site
for /usr/local
so I am trying to add one. The Autoconf manual on Site Defaults is a tad bit confusing to me when it discusses usr/local
's config.site
. It says:
[discussion of
/usr
version ofconfg.site
] ...Likewise, on platforms where 64-bit libraries are built by default, then installed in /usr/local/lib64 instead of /usr/local/lib, it is appropriate to install /usr/local/share/config.site:
# /usr/local/share/config.site for platforms that prefer # the directory /usr/local/lib64 over /usr/local/lib. test "$libdir" = '${exec_prefix}/lib' && libdir='${exec_prefix}/lib64'
The problem I am having is, is the modification above appended to the /usr/local
version of config.site
? Or does it replace an existing block of code? Or can I just copy it where it belongs without modification?
Or maybe, what does a cat of /usr/local/share/config.site
look like?
Here is the config.site
for /usr
. Its not clear to me if it needs modification or how to modify it.
$ cat /usr/share/config.site
# This is the config.site file to satisfy FHS defaults when installing below
# /usr.
#
# You may override this file by your config.site using the CONFIG_SITE env
# variable.
#
# Note: This file includes also RHEL/Fedora fix for installing libraries into
# "/lib/lib64" on 64bit systems.
if test -n "$host"; then
# skip when cross-compiling
return 0
fi
if test "$prefix" = /usr \
|| { test "$prefix" = NONE && test "$ac_default_prefix" = /usr ; }
then
test "$sysconfdir" = '${prefix}/etc' && sysconfdir=/etc
test "$sharedstatedir" = '${prefix}/com' && sharedstatedir=/var
test "$localstatedir" = '${prefix}/var' && localstatedir=/var
ARCH=`uname -m`
for i in x86_64 ppc64 s390x aarch64; do
if test $ARCH = $i; then
test "$libdir" = '${exec_prefix}/lib' && libdir='${exec_prefix}/lib64'
break
fi
done
fi
--libdir
option does not result in your libraries going where you want them, then it seems unlikely that adding or modifying site defaults would do the trick, either. The point of the defaults is largely to avoid you having to specify installation locations by hand, but you're already past that. – Radiosed
to patch%{_libdir}
ingnutls.spec
. I guess my next question is, is GnuTLS doing the right thing by settingsys_lib_dlsearch_path_spec
in the first place? It seems like Autotools/Autoconf should drive the entire process. That is,sys_lib_dlsearch_path_spec
fiddling should not be present, and%{libdir}
should be used throughout. – Yvonneyvonnersys_lib_dlsearch_path_spec
andgnutls.spec
(is it too much for a comment)? That should allow you to answer this question aboutconfig.site
in/usr/local
withlib64
without worrying about the misbehaving projects. Then, in the new question, you can address the problems withsys_lib_dlsearch_path_spec
. – Yvonneyvonnerconfigure
in that way. It is fairly common for these to patchconfigure
to suppress RPATH entries being recorded in ELF objects, but I have never before seen a patch of the kind you're pointing out here. HOWEVER, I don't think it's directly related to your original question. I don't see how a patch such as that could affect where the build system installs libraries that it builds. It seems to be about whereconfigure
looks for shared libs that are already installed. – Radio