bug#10643: BUG REPORT libtool-2.4.2 Solaris 10 64bit - Update

[JONES, BILL]

Bob,



The only way I know to not need LD_LIBRARY_PATH is to use "-R" on the link line 
with the path to the locations of YOUR shared libs.



Assuming we stay with LD_LIBRARY_PATH....see below:

OK I was able to resolve all the issues with a simple but wide ranging 
correction to: aclocal.m4 and libtool.m4 and the resulting configure scripts.

Unfortunately not all the packages I was building liked getting that tickled, 
so some of then ran automake ... and of those, some worked and some didn't.

gettext didn't work very well..I had to change configure manually.

Here is the change:
In every file that contained this block of code (and variants) (which is more 
than just aclocal.m4...also libtool.m4 and others)

FROM THIS:
solaris*)
  version_type=linux # correct to gnu/linux during the next big refactor
  need_lib_prefix=no
  need_version=no
  library_names_spec='${libname}${release}${shared_ext}$versuffix 
${libname}${release}${shared_ext}$major $libname${shared_ext}'
  soname_spec='${libname}${release}${shared_ext}$major'
  shlibpath_var=LD_LIBRARY_PATH
  shlibpath_overrides_runpath=yes
  hardcode_into_libs=yes
  # ldd complains unless libraries are executable
  postinstall_cmds='chmod +x $lib'
  ;;

TO THIS:
solaris*)
  case $LD in # libtool.m4 will add one of these switches to LD
    *-64*) shlibsuff=_64 ;;
    *)     shlibsuff= ;;
  esac
  version_type=linux # correct to gnu/linux during the next big refactor
  need_lib_prefix=no
  need_version=no
  library_names_spec='${libname}${release}${shared_ext}$versuffix 
${libname}${release}${shared_ext}$major $libname${shared_ext}'
  soname_spec='${libname}${release}${shared_ext}$major'
  shlibpath_var=LD_LIBRARY_PATH${shlibsuff}
  shlibpath_overrides_runpath=yes
  hardcode_into_libs=yes
  # ldd complains unless libraries are executable
  postinstall_cmds='chmod +x $lib'
  ;;

This mirrors the code done for irix.

There were also minor changes to other tools scripts where they were focused on 
LD_LIBRARY_PATH and I added support for LD_LIBRARY_PATH_64.

I then rebuilt from scratch my entire build environment ... these tools in this 
order:
autoconf-2.68
automake-1.4-p6
automake-1.11.1
readline-5.2
libsigsegv-2.10
libiconv-1.14
zlib-1.2.5
expat-2.0.1
gettext-0.18.1.1
ncurses-5.7
pcre-8.21
grep-2.10
gawk-4.0.0
sed-4.2.1
xz-5.0.3
gzip-1.4
gmp-4.2.1
coreutils-8.15
libtool-2.4.2



I am putting a list of all the tweaks I made to get it to work for those who 
are interested.  The final result was that all tests for LIBTOOL either PASSED, 
WORKED AS EXPECTED OR were skipped.



## ------------- ##
## Test results. ##
## ------------- ##

110 tests behaved as expected.
16 tests were skipped.
make[3]: Leaving directory 
`/appl/archives/build_tools/tools/build/libtool-2.4.2'
make[2]: Leaving directory 
`/appl/archives/build_tools/tools/build/libtool-2.4.2'
make[1]: Leaving directory 
`/appl/archives/build_tools/tools/build/libtool-2.4.2'





How could this get distributed to all the tools so all can benefit?



Bill


________________________________________
From: Bob Friesenhahn address@hidden
Sent: Monday, January 30, 2012 2:33 PM
To: JONES, BILL
Cc: address@hidden; address@hidden
Subject: RE: bug#10643: BUG REPORT libtool-2.4.2 Solaris 10 64bit - Update

On Mon, 30 Jan 2012, JONES, BILL wrote:
>
> HOWEVER, once the first set of tests passed another section I have
> never seen before started...and it has failures also...I had to
> change all instances of configure in the directory tree, but still
> not all the tests passed...I sent the results of testsuite.log from
> the server with the bug# in the subject.
>
> In test/cdemo/configure I see this code...so there IS a mechanism to
> detect which bit size being used.  Could this be leveraged in the
> LD_LIBRARY_PATH section?

My preference is to find a way to remove any existing
LD_LIBRARY_PATH_32 or LD_LIBRARY_PATH_64 definitions from the
environment so that only LD_LIBRARY_PATH will be used.  It does not
seem to me that any LD_LIBRARY_PATH type variable set in the user's
environment should be allowed to influence execution since libtool and
its wrapper scripts are supposed to have full knowledge of the
necessary linkage.  Testing the linkage is important part of 'make
check'.  Is there a reason why this approach would be faulty?

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/