Unable to run "make check" on Solaris 10

Dennis Clarke dclarke at blastwave.org
Mon Mar 9 01:08:10 CET 2009


> 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/




More information about the gmp-bugs mailing list