build error on systems using lib64 as directory for 64-bit libraries
Swiss army knife of image processing
Brought to you by:
bfriesen
Menu
▾
▴
#289 build error on systems using lib64 as directory for 64-bit libraries
There exists GNU+Linux distributions installing 64-bit libraries under the directories /lib64, /usr/lib64, /usr/local/lib64 rather than the corresponding lib ones; on these platforms, it is also possible to install 32-bit libraries under the traditional lib directories to run programs under both 32-bit and 64-bit architectures.
On these systems, GraphicsMagick 1.3.20 fails to build because the configure.ac template hard-codes the pathname "$some_prefix/lib". Successful builds are possible by running configure with:
$ ./configure LDFLAGS='-L/usr/lib64 -L/usr/local/lib64'
but this solution is, AFAICT, undocumented and there should be a cleaner way to do it.
GraphicsMagick's configure.ac does not set any LDFLAGS at all. The compiler should know where to look for system libraries (e.g. based on -m32 or -m64) and the user is responsible for adding a search request for any additional libraries required. The user is always in charge. The use of LDFLAGS is indeed documented in GraphicsMagick installation documentation, but not specifically to address this split library directory model.
GraphicsMagick uses libtool and libtool hard-codes a run-time linking specification for libraries which are not in the system library search path as known by 'ldconfig'. I recall some discussion of this on the libtool mailing list regarding lib64 directories. GraphicsMagick always uses the most recent official libtool when released so it will have whatever smarts are known to that libtool.
The compiler should be installed in a way that it knows the correct default set of search directories for headers and libraries so that compilation works by default. For GCC, there is a built-in "spec" file which can be dumped with 'gcc -dumpspecs'. The output of this command can be written to a file in a particular location (used by GCC if it exists) in order to override it. This allows built-in parameters to be modified so that GCC behaves differently. See https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html for documentation on spec file syntax.
Regardless, I do not consider this report to be a bug in the GraphicsMagick configure script.