Unable to run "make check" on Solaris 10

[Tim Cook - PAE]

Dennis,

Well, I actually am aiming for including $ORIGIN in the RPATH, so that 
the library I build will first look in the same directory for any 
dependencies.

In order to do this, I set LD_OPTIONS for the make step, for example:

     export LD_OPTIONS='-R $ORIGIN:/usr/sfw/lib'

I do not have the patience or knowledge to get this value (including the 
unexpanded dollar sign) through all the autoconf stuff, but fortunately 
LD_OPTIONS is neither seen or (re)set by any of the autoconf, configure 
or make steps.  It is just picked up by ld.

Now, if I want to run the "make check" step, I revert to not having 
LD_OPTIONS set, but then I found the bare vanilla "configure; make; make 
check" did not do enough to help the test executable find libgmp.so 
within the build tree.

Here is what I get for one of the test executables:

     potts-cl ) pwd
     /export/build/gmp-4.2.4/build.i386/tests/mpq/.libs
     potts-cl ) elfdump -d t-cmp | grep PATH
            [4]  RUNPATH           0x8c2               /usr/local/lib
            [5]  RPATH             0x8c2               /usr/local/lib
     potts-cl ) ldd t-cmp
             libgmp.so.3 =>   (file not found)
             libc.so.1 =>     /lib/libc.so.1
             libm.so.2 =>     /lib/libm.so.2

Regards,
Tim

Dennis Clarke wrote:
>> My apologies - I intended to add 2 logfiles, which are now attached:
>>
>> - make.plain.1.out.gz
>> 	Output of the "make" step
>> - make_check.plain.1.out
>> 	Output of the "make check" step
> 
> Tim, I have been working on older legacy systems because, as you know,
> Blastwave supports people still on Solaris 8 and even sun4m in some really
> edge cases. I was able to get libgmp to build and pass all tests on
> Solaris 8 with Sun Studio 8 on sun4m.
> 
> The exact same code with Studio 11 on Solaris 8 UltraSparc will not
> compile with the same environment variables.  Studio 12 is no better.
> 
> bizarre but true.
> 
> Not sure how you managed to not resolve the location of libgmp however,
> what does elfdump foo | grep RPATH say ?  What I have, and this is correct
> for the Blastwave world, is this :
> $ elfdump lib/sparcv8/libgmp.so.3.4.4 | /usr/xpg4/bin/grep -E "RPATH|RUNPATH"
>        [3]  RUNPATH          0x60ea           
> /opt/csw/lib/$ISALIST:/opt/csw/lib
>        [4]  RPATH            0x60ea           
> /opt/csw/lib/$ISALIST:/opt/csw/lib
> 
> However the C++ compiler mangled my $ISALIST :
> 
> $ elfdump lib/sparcv8/libgmpxx.so.4.0.4 | /usr/xpg4/bin/grep -E
> "RPATH|RUNPATH"
>        [5]  RUNPATH          0x97b            
> /opt/csw/lib:/opt/csw/lib/SALIST:/opt/SUNWspro/lib/rw7:/opt/SUNWspro/lib/stlport4:/opt/SUNWspro/lib:/usr/ccs/lib:/usr/lib
>        [6]  RPATH            0x97b            
> /opt/csw/lib:/opt/csw/lib/SALIST:/opt/SUNWspro/lib/rw7:/opt/SUNWspro/lib/stlport4:/opt/SUNWspro/lib:/usr/ccs/lib:/usr/lib
> 
> Strangely my $ISALIST was mangled. This looks to be due to a compiler bug
> and when I look in the output lib sure enough I see that my RPATH:RUNPATH
> has been mangled by the compiler some how.
> 
> Starting at offset 0x000100d :
> 
> 000100d  53  55  4e
>          S   U   N
> 0001010  57  70  72  69  76  61  74  65  5f  31  2e  31  00  6c  69  62
>          W   p   r   i   v   a   t   e   _   1   .   1  \0   l   i   b
> 0001020  67  6d  70  2e  73  6f  2e  33  00  6c  69  62  67  6d  70  78
>          g   m   p   .   s   o   .   3  \0   l   i   b   g   m   p   x
> 0001030  78  2e  73  6f  2e  34  00  2f  6f  70  74  2f  63  73  77  2f
>          x   .   s   o   .   4  \0   /   o   p   t   /   c   s   w   /
> 0001040  6c  69  62  3a  2f  6f  70  74  2f  63  73  77  2f  6c  69  62
>          l   i   b   :   /   o   p   t   /   c   s   w   /   l   i   b
> 0001050  2f  53  41  4c  49  53  54  3a  2f  6f  70  74  2f  53  55  4e
>          /   S   A   L   I   S   T   :   /   o   p   t   /   S   U   N
> 0001060  57  73  70  72  6f  2f  6c  69  62  2f  72  77  37  3a  2f  6f
>          W   s   p   r   o   /   l   i   b   /   r   w   7   :   /   o
> 0001070  70  74  2f  53  55  4e  57  73  70  72  6f  2f  6c  69  62  2f
>          p   t   /   S   U   N   W   s   p   r   o   /   l   i   b   /
> 0001080  73  74  6c  70  6f  72  74  34  3a  2f  6f  70  74  2f  53  55
>          s   t   l   p   o   r   t   4   :   /   o   p   t   /   S   U
> 0001090  4e  57  73  70  72  6f  2f  6c  69  62  3a  2f  75  73  72  2f
>          N   W   s   p   r   o   /   l   i   b   :   /   u   s   r   /
> 00010a0  63  63  73  2f  6c  69  62  3a  2f  75  73  72  2f  6c  69  62
>          c   c   s   /   l   i   b   :   /   u   s   r   /   l   i   b
> 00010b0  00
> 
> I have been fighting with both compilers and libgmp for at least a week
> now and it is often unclear if I am seeing a bug in the gmp code or in the
> Studio compilers.
> 
> How are you compiling libgmp? With Studio 12? Are you using the STLport
> implementation of the standard library?
> 
> Dennis Clarke
> http://www.blastwave.org/
> 
> 

-- 
Tim Cook
Performance and Applications Engineering
Menlo Park, CA USA
<> Sun Microsystems
Ph:     +1 650 257 4709
Ext:	69841