Re: 1 test ( tests/mdemo2-make.test ) fails on Solaris 10

[Dr. David Kirkby]

Bob Friesenhahn wrote:
> On Sun, 14 Jun 2009, Dr. David Kirkby wrote:
> > However, it was pointed out to me by a Sun employee that there is no 
> > need to ever link libpthread in Solaris 10. Al the functionality has 
> > been moved to libc.
>
> Are you absolutely sure about this?  For many years, Solaris libc has 
> used weak references so that if libpthread was added to the link it 
> behaved differently.  This results in pthread symbols in libc.  The 
> reason for this approach was so that libraries/applications could use 
> the same libc, but without penalizing thread safe libraries linked into 
> single-threaded applications.  It also allowed the same libc to be used 
> with UI threads (-lthread).

Well, I can't say I am 100% sure, but I can be sure that it was stated 
by Nicholas Williams, who has a Sun email address.

http://www.mail-archive.com/address@hidden/msg43531.html

(There's a button in the bottom left to email him)

Then when I asked when this happens, he sent me a private mail

> As a matter of interest, do you know in what release of Solaris the
> functionality of libpthread was moved into libc? (Don't spend too much
> time over it if you don't know - it's not that important to me).

S10.  In S10 the process model was unified (all processes are
multi-threaded, though not necessarily in the sense of having multiple
threads, but in the sense that libraries can certainly create threads)
and static libraries were no longer delivered with Solaris, or at least
the core part of Solaris (third parties can still create static
libraries).


> > Note these 'undefined reference' messages with SUNW in the name have 
> > come up for years with different versions of gcc. In gcc 4.3.2 I don't 
> > see them, but I do see them in 4.4.0
>
> Perhaps there is a difference with how your 4.3.2 and 4.4.0 were built 
> and the misbehaving one is using the GNU linker from binutils.  I found 
> it necessary to use the GNU linker to build GCC 4.4.0 on x86 but the GNU 
> linker is otherwise not very useful under Solaris and using it under 
> Solaris is like (slowly) digging your own grave.  Once GCC 4.4.X can use 
> Solaris ld again then I will start to use it.  Complaints about weak 
> symbols are just the tip of the iceberg when using GNU ld under Solaris.
>
> Check the output of 'gcc -v'.  In my GCC 4.3.3 build I have this:
>
>   --without-gnu-ld --with-ld=/usr/ccs/bin/ld
>
> but in my GCC 4.4.0 build I have this:
>
>   --with-ld=/usr/local/lib/binutils-2.19/bin/ld

I'm using all the GNU tools.  I know this battle of Sun/GNU linker has 
gone on a long while. IMHO, more people test their code with the GNU one 
as they only have linux.

Both 4.3.2 and 4.4.0 were built using GNU tools.

In the Sage project which I'm helping with, there are more than 100 
different open-source projects included. It takes more than a day to 
build on a Sun - there is that much code. The compressed source code is 
around 200 MB in size. It was determined long ago (by others not me) 
that the more suitable linker was the GNU one. Some software assumes its 
the GNU one. Some software is dumb enough to check if the compiler is 
gcc, find it is not, then throw gcc specific flags at it.

Both gcc's were configured with the GNU linker. I did not configure the 
4.3.2 one - someone else did. But he also built gcc-4.4.0 and I assume 
in much the same way, and could not get sqlite to build properly.

I then built 4.4.0 and had the same problem. After some asking around, 
it would appear that libpthread is not needed.

Here are the two outputs from gcc -v.

address@hidden:[~] $ gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.4.0/configure --with-gnu-as 
--with-as=/home/kirkby/bin/as --with-gnu-ld 
--with-ld=/home/kirkby/bin/ld --with-gmp=/home/kirkby/dependencies/ 
--with-mpfr=/home/kirkby/dependencies/ --enable-languages=c,c++,fortran 
--prefix=/home/kirkby/dependencies/
Thread model: posix
gcc version 4.4.0 (GCC)


address@hidden:[~] $ /usr/local/sparc-solaris-toolchain/bin/gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.3.2/configure 
--prefix=/home/mabshoff/sparc-solaris-toolchain/ 
--enable-languages=c,c++,fortran --with-gnu-ld 
--with-ld=/home/mabshoff/sparc-solaris-toolchain/bin/ld --with-gnu-as 
--with-as=/home/mabshoff/sparc-solaris-toolchain/bin/as 
--with-gmp=/usr/local/gmp-4.2.3/sparc-SunOS-gcc-4.3.1-abi32/ 
--with-mpfr=/usr/local/mpfr-2.3.2/sparc-SunOS-gmp-4.2.3-gcc-4.3.1-abi32/
Thread model: posix
gcc version 4.3.2 (GCC)

Feel free to poke around in

http://sage.math.washington.edu/home/kirkby/

you should be able to work out where things are, but a few are

http://sage.math.washington.edu/home/kirkby/dependencies/
http://sage.math.washington.edu/home/kirkby/build-gcc-4.4.0/
http://sage.math.washington.edu/home/kirkby/libtool-2.2.6/

The layout of the Sage code is a bit unconventional, as it consists of 
packages with the extension .spkg which are in fact tar files compressed 
with bzip2. Why the extension .tar.bz2 was not used I will never know.

That is here.

http://sage.math.washington.edu/home/kirkby/sage-4.0.1.alpha0/