DODS_LIB not assumed correctly for systems with lib64 directories

[volter]

if test -z "$with_dods_root" -o "$with_dods_root" = "no"; then

{ $as_echo "$as_me:${as_lineno-$LINENO}: result: disabled" >&5

$as_echo "disabled" >&6; } elif test "$with_dods_root" = "yes" ; then

as_fn_error $? "--with-dods-root requires path to dods root as argument" "$LINENO" 5

else

DODS_LIB=$with_dods_root/lib DODS_INC="-I$with_dods_root/include -I$with_dods_root/include/libdap -I$with_dods_root/include/dap" DODS_BIN=$with_dods_root/bin

This piece of code does not work on systems that place their libraries in a lib64 directory.

[rroliver]

Adds --with-archlibdir= option to configure for multilib builds

[rroliver]

Have been holding off on the above patch, still not sure of the sanest way to deal with this...

For me this issue hits me on Solaris multilib builds (well ALL multilib builds)

from patch description

Add a --with-archlibdir option to allow specification of where to search for abi/arch specific libraries on multilib builds. Option defaults to 'lib'.

Does not affect the --libdir option...

Will require relatively new autotools to apply.

Apply with ( cd $(SOURCE_DIR); \

aclocal -I ./m4; \ libtoolize --force --copy; \ autoheader; \ autoconf; )

For those on solaris, can supply patches to libtool to make it behave and not eat compiler options required at link time...

Thoughts?

[Even Rouault]

I see the good intention behind the patch, but I'm afraid it is not appropriate at such, because most places where xxxxx/lib is tested are for installation prefixes in non-system locations. When you do a ./configure --prefix=xxxx on a package, it always installs its libs in xxxx/lib, not in xxxx/lib64. Most places in GDAL configure don't require to specify the root when the library is installed in a system location such as /usr/lib64, but there are perhaps just a few places in configure to fix to avoid testing explicitly -L/usr/lib

[rroliver]

Replying to rouault:

I see the good intention behind the patch, but I'm afraid it is not appropriate at such, because most places where xxxxx/lib is tested are for installation prefixes in non-system locations. When you do a ./configure --prefix=xxxx on a package, it always installs its libs in xxxx/lib, not in xxxx/lib64. Most places in GDAL configure don't require to specify the root when the library is installed in a system location such as /usr/lib64, but there are perhaps just a few places in configure to fix to avoid testing explicitly -L/usr/lib

It's not so much an issue for me, I've been maintaining these patches for Solaris for over a year and have been doing from scratch multilib builds of entire linux systems since the AMD64 was released. After so many years you get used to fighting autotools to make it work.

On solaris (or other proprietary unices) convention is all non-vendor packages are always installed somewhere under /opt, and in solaris' case for multilib builds libraries go to */lib (32bit) AND */lib/sparcv9 */lib/amd64 (64bit).

Without any mechanism short of sed editing or patching the configure scripts you can guarantee constant link time errors due to wrong elf type because of the assumptions configure makes (even on linux)

A better option would be to allow an option to specify the library and include locations for EACH external library dependency

ie: --with-geos-lib= --with-geos-inc=

to override the defaults...

but not in the way presently done for certain external deps such as expat and libkml, as they STILL add /lib to the end of the specified path and break everything.

I'm not sure of the best way to fix GDAL's configury, all I know is it is broken and needs to be fixed to restore sanity...

[Even Rouault]

Part of the issue ( the ones affecting gcore/gdaldrivermanager.cpp and ogr/ogrsf_frmts/generic/ogrsfdriverregistrar.cpp ) has been addressed by #4444 . I feel shy for the rest of gdal-1.9.0-multilib_fixes-2.patch which serves very specific purposes (sorry Solaris...)

[Even Rouault]

Forget previous comment for now. The r24986 for #4444 has been reverted

[rroliver]

The patch is not solaris specific, the patch is for _any_ multilib system where you are installing both 32 and 64 bit libraries to the same prefix under different lib directories (lib / lib64, lib / lib/sparcv9 ).

If there isn't a mechanism for explicitly specifying library location you end up attempting to link 64 bit objects to 32 bit libraries.

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.