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

[JONES, BILL]

Bob,

For you question about the /usr/local/lib/libiconv.la, I have built several 
other tools from GNU that detect the new 
/appl/gfpip/local/lib/sparcv9/libiconv.la properly over the /usr/local/lib 
version.

NOTE:  I changed all the test "configure" files to add _64 to the Solaras 
instances of LD_LIBRARY_PATH and ALL TESTS PASSED....
NOTE:  The section of code in f77demo/configure that defined shlibpath_var is 
duplicated, and I changed both instances.  Same goes for tagdemo/configure. 
libtool-2.4.2/configure.


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?

*-*solaris*)
  # Find out which ABI we are using.
  echo 'int i;' > conftest.$ac_ext
  if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_compile\""; } >&5
  (eval $ac_compile) 2>&5
  ac_status=$?
  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
  test $ac_status = 0; }; then
    case `/usr/bin/file conftest.o` in
    *64-bit*)
      case $lt_cv_prog_gnu_ld in
      yes*)
        case $host in
        i?86-*-solaris*)
          LD="${LD-ld} -m elf_x86_64"
          ;;
        sparc*-*-solaris*)
          LD="${LD-ld} -m elf64_sparc"
          ;;
        esac
        # GNU ld 2.21 introduced _sol2 emulations.  Use them if available.
        if ${LD-ld} -V | grep _sol2 >/dev/null 2>&1; then
          LD="${LD-ld}_sol2"
        fi
        ;;
      *)
        if ${LD-ld} -64 -r -o conftest2.o conftest.o >/dev/null 2>&1; then
          LD="${LD-ld} -64"
        fi
        ;;
      esac
      ;;
    esac
  fi
  rm -rf conftest*
  ;;
esac

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

OK...so I went to the source tree an edited configure.

cd src/libtool-2.4.2/tests/demo
vi configure

Changed:

solaris*)
  ...
  shlibpath_var=LD_LIBRARY_PATH

TO
solaris*)
  ...
  shlibpath_var=LD_LIBRARY_PATH_64

Reran the test and everthing worked.

If configure had --enable-64bit and handled it....


Your next point about libtool:
So if I have more than one "lib" and I need it to pay attention to my/lib 
instead of /usr/local/lib, how can I make libtool stop running home to mommy.

crle
Yes...I know crle...it's a system wide root enabled demon that the company 
police would rather not have users have access to.  Can't use it for this.  
-R{path} will have to do for compiled objects, so build scripts have to know 
what they are doing.

Bill

________________________________________
From: Bob Friesenhahn address@hidden
Sent: Sunday, January 29, 2012 9:31 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:

> Bob,
>
> I believe this is what is happening.
>
> The test scripts are setting LD_LIBRARY_PATH to include the .libs
> directory for the temporary shared library, but the linker only
> seems to be looking at LD_LIBRARY_PATH_64.
>
> I was going to try to hack the test scripts to see if I changed it to _64 to 
> see if the test suddenly worked.

Keep in mind that the wrapper does entirely wrap the exe so there is
no need to re-run the whole 'make check' to test a change to the
wrapper.  Just try running the wrapper before and after and see if
things change.

You can also edit the 'libtool' script (in the build tree) directly.
I see two occurances of LD_LIBRARY_PATH.  You can replace these two
occurances with LD_LIBRARY_PATH_64 and see if things clear up.

> I see support for such tests in other tools, but not in
> libtool...and glib is giving me a headache as well since it wants to
> always link with /usr/local/lib/libiconv.so instead of honoring the
> -R -L options in LDFLAGS and/or LD_LIBRARY_PATH_64...the spelled out
> path in actually on the command line put there by the bundled
> libtool with glib...which is why I was trying to get a better
> working version...libtool in glib is 2.2.

Ugh.  Is there a /usr/local/lib/libiconv.la file?

The Solaris 10 ld.so.1 manual page suggests that LD_LIBRARY_PATH_64
may influence where the linker ('ld') searches for libraries as well.
The manual page is not very clear on this.

> o .libs/gslice.o .libs/gslist.o .libs/gstdio.o .libs/gstrfuncs.o 
> .libs/gstring.o .libs/gtestutils.o .libs/gthread.o .libs/gthreadpool.o 
> .libs/gtimer.o .libs/gtree.
> o .libs/guniprop.o .libs/gutf8.o .libs/gunibreak.o .libs/gunicollate.o 
> .libs/gunidecomp.o .libs/gurifuncs.o .libs/gutils.o .libs/gvariant.o 
> .libs/gvariant-core.o .
> libs/gvariant-parser.o .libs/gvariant-serialiser.o .libs/gvarianttypeinfo.o 
> .libs/gvarianttype.o .libs/gprintf.o .libs/giounix.o .libs/gspawn.o  -Wl,-z 
> -Wl,allextr
> act libcharset/.libs/libcharset.a pcre/.libs/libpcre.a -Wl,-z 
> -Wl,defaultextract  -R/usr/local/lib -R/usr/local/lib 
> -R/appl/gfpip/local/lib/sparcv9:/usr/local/lib/
> sparcv9 -L/appl/gfpip/local/lib/sparcv9:/usr/local/lib/sparcv9 
> /usr/local/lib/libiconv.so -L/usr/local/lib -L/usr/lib -L/usr/openwin/lib 
> -L/usr/local/ssl/lib -L/us
> r/X11R6/lib -L/usr/local/BerkeleyDB.4.7/lib /usr/local/lib/libintl.so 
> -L/usr/local/BerkeleyDB.4.2/lib -lc  -m64 -m64
> ld: fatal: file /usr/local/lib/libiconv.so: wrong ELF class: ELFCLASS32
> ld: fatal: File processing errors. No output written to 
> .libs/libglib-2.0.so.0.2513.0
> collect2: ld returned 1 exit status
>
> The above example is the libtook in /usr/local/lib/libtool since I am having 
> problems with the 64bit one.
>
> All the above in RED seems to be added by libtool, but I can't find
> it anywhere in the source or build directories....

Sorry, I don't see color.  I assume that the RED bit includes
/usr/local/lib/libiconv.so.  Check for a /usr/local/lib/libiconv.la
file.  This is just a text file so you can use 'cat' on it and see its
content.  Libtool searches for .la files to learn more about how to
link with a library.

> Then glib was next....with the problems.
>
> I need glib for atk which I need for vim as well as glib.

You have likely entered a twisty turny path of conflicting
dependencies.  Other problems commonly encountered on Solaris 10 is
with pkg-config, which likes to offer up dependencies on old libraries
that you don't want to use.

> These are the environment variables I am using:
>
> #
> # Setup basic LIBRARY paths
> #
> LD_LIBRARY_PATH_64=${LIBTARGET64}:/usr/local/lib/sparcv9
> export LD_LIBRARY_PATH LD_LIBRARY_PATH_64

LD_LIBRARY_PATH is pretty evil.  I use 'crle' to configure the system
search paths on my Solaris 10 systems rather than attempting to use
environment variables:

% crle -64

Configuration file [version 4]: /var/ld/64/ld.config
   Default Library Path (ELF):   /lib/64:/usr/lib/64:/usr/local64/lib
   Trusted Directories (ELF):    /lib/secure/64:/usr/lib/secure/64  (system 
default)

Command line:
   crle -64 -c /var/ld/64/ld.config -l /lib/64:/usr/lib/64:/usr/local64/lib

Some people are deathly afraid of invoking 'crle', but it seems
similar to Linux 'ldconfig' that people don't seem to be so afraid of.

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