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

[JONES, BILL]

I am following what's already in the code.  While I have GNU "ld" all the 
packages are avoiding it because the GNU LD is deprecated in favor of the SUN 
LD.
It seems all the packages are already dealing with that.

Neither GNU gcc nor the SUN compilers build by default 64bit code ... so far.  
Can't code to what does not exist.

Also...by then, it would be nice if the ld.so.1 was smart enought to parse a 
LD_LIBRARY_PATH and not link with libs of the wrong elf class and move on, 
however...that's not the case.

I know your asking the "hard" questions...but the reality is all these packages 
rely on LD_LIBRARY_PATH for their 32bit ONLY support...and it just hasn't been 
thought out for the 64bit stuff.
What if LD_LIBRARY_PATH went away and you had to KNOW to use 
LD_LIBRARY_PATH_32...or as in other systems LD_LIBRARY32_PATH/LD_LIBRARY64_PATH.

I didn't invent the problem...just trying to get a clean compile...and while 
this may not be the end all answer, it's better than the NON-answer that's 
there now.

Bill

________________________________________
From: Bob Friesenhahn address@hidden
Sent: Wednesday, February 01, 2012 6:09 PM
To: JONES, BILL
Cc: address@hidden; address@hidden
Subject: RE: bug#10643: BUG REPORT libtool-2.4.2 Solaris 10 64bit - Update

On Wed, 1 Feb 2012, JONES, BILL wrote:
>
> TO THIS:
> solaris*)
>  case $LD in # libtool.m4 will add one of these switches to LD
>    *-64*) shlibsuff=_64 ;;
>    *)     shlibsuff= ;;
>  esac

Based on configure code provided in your earlier email, it seems that
-64 is not always included in $LD.  It depends on if GNU ld is used,
or Solaris /usr/ccs/bin/ld is used.  How do you propose to deal with
that?

Also, how should a compiler be dealt with which produces 64-bit output
by default on Solaris.

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