Build fails on Solaris 10 (Oct 2008)

[GoogleCodeExporter]

A vanilla build of perftools 1.0 on Solaris 10 (Oct 2008, i386) fails with
several missing symbols (including nanosleep and inet_ntoa) during link.

The nanosleep function requires librt, and the inet_ntoa function requires
both libsocket and libnsl to link properly.  The included build files don't
have a provision for these anywhere.

The attached patch modifies configure.ac to determine whether these
libraries are needed, and include them in the link if so.

Original issue reported on code.google.com by roger.a....@gmail.com on 24 Feb 2009 at 5:35

Attachments:

• solaris-fix.patch

[GoogleCodeExporter]

Does everything compile on solaris 10 for you after this patch?  If so, that's
interesting, since solaris 10 has a buggy libstdc++.la that should cause 
problems for
you when building.  (Maybe it got fixed in later versions?)  I talk about this, 
and
the workaround, in the INSTALL file.  It's true you need to do something 
special to
get the build working under solaris, and I like your idea of moving that 
'something
special' from the INSTALL file to autoconf.

However, given that we need to link in solaris/libstdc++.la anyway, I think it 
may be
better to just detect we're running on a solaris system, and add all the flags
solaris needs, rather than adding autoconf macros.  I could be convinced either 
way.

The INSTALL file mentions -lrt, but doesn't mention -lnsl, which is a bug on my 
part,
since I know it needs it (my internal solaris builds use it).  I haven't needed
-lsocket, however.  Can you confirm it's necessary for you, in order to build?

I wonder if an easier fix would be to just get rid of inet_ntoa entirely -- 
it's only
used for a test, and an uninteresting one at that.  But we do need to keep 
nanosleep,
so maybe there's not much point.

OK, I'll do some sort of fix for this for the next release.

Original comment by csilv...@gmail.com on 24 Feb 2009 at 8:29

• Changed state: Accepted
• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Craig, let me poke around on my installation a little bit so I can answer your
questions better.  But for now, yes, I can do a full vanilla build and install 
on
Solaris 10 after this patch, with no extra steps necessary.  I remember the
libstdc++.la problem you're talking about, but I didn't bump into it on this 
one -
perhaps because Sun fixed it for this release (the Oct 2008 release).  I'll 
verify
that and post again.

You're right, INSTALL mentions -lrt, that's just my fault for expecting 
configure to
be self-contained.  :)  I'm juggling so many platforms here that I forgot to 
check
for that.  -lsocket is only required for inet_ntoa, and as I recall -lnsl is 
required
for -lsocket.  I do need both for the build to complete.  If you can eliminate 
the
inet_ntoa call, both of those go away though.  I like that answer.

-lrt is definitely needed for nanosleep, so we're stuck there.  I think the m4 
code I
supplied answers that one pretty well though.  (Credit where credit is due... I
borrowed heavily from existing configure macros for it.)

Original comment by roger.a....@gmail.com on 24 Feb 2009 at 8:43

[GoogleCodeExporter]

OK, I checked.  Both my installs of Sol10 5-08 and 10-08 have a valid 
libstdc++.la
file.  Unfortunately I don't know the specific patch that fixed this - I'm 
using the
free downloads for builds only.  Anyway, I remember very clearly that my 
original
install of the 11-06 release had the bad file, so I know what you're talking 
about. 
I don't have that VM around anymore to test quickly, though.

I should point out that I'm using the Sun-supplied gcc in the /usr/sfw tree.  
Anybody
using the Sun compiler, Blastwave install, or custom install is going to have a 
very
different experience.  (That's what I love about Solaris.)  FWIW, I *do* get 
helper
utils from Blastwave, so that might be worth mentioning in the INSTALL file as 
an
alternative to building them yourself.

So... this solution works great for me, but I don't doubt you still want to 
support
users who have the libstdc++.la problem.  My thought would be to add yet another
check to configure to handle that case automatically.  It ought to be very easy 
to do
- have configure do a trial link without the -Lsrc/solaris flag, and if that 
fails
try it with.  That's much the same way I do the -lrt check.  I'm willing to 
tackle
this bit too, if you like.  I'll just have to break my libstdc++.la file to 
test it!

Original comment by roger.a....@gmail.com on 24 Feb 2009 at 11:26

[GoogleCodeExporter]

No worries -- I have a simple check in mind for libstdc++.la, which I'll do 
when I
add in these other solaris checks.

Original comment by csilv...@gmail.com on 25 Feb 2009 at 7:56

[GoogleCodeExporter]

Original comment by csilv...@gmail.com on 25 Feb 2009 at 11:09

• Changed state: Started

[GoogleCodeExporter]

This should be fixed in perftools 1.1, just released.  Solaris should compile 
just
fine without any special action required on the user's part.

Original comment by csilv...@gmail.com on 11 Mar 2009 at 9:20

• Changed state: Fixed