pcp
[Top] [All Lists]

Re: [pcp] PCP on OpenSolaris

To: Nathan Scott <nscott@xxxxxxxxxx>
Subject: Re: [pcp] PCP on OpenSolaris
From: Max Matveev <makc@xxxxxxxxx>
Date: Tue, 9 Jun 2009 22:59:28 +1000
Cc: pcp@xxxxxxxxxxx
In-reply-to: <647681153.6030381244505641945.JavaMail.root@xxxxxxxxxxxxxxxxxx>
References: <647681153.6030381244505641945.JavaMail.root@xxxxxxxxxxxxxxxxxx> <1132154685.6054271244516786850.JavaMail.root@xxxxxxxxxxxxxxxxxx> <520040377.6029471244505447489.JavaMail.root@xxxxxxxxxxxxxxxxxx>
>>>>> "nscott" == Nathan Scott writes:

 nscott> Whatever that is...  SMF stuff?

/etc/init.d/foo is so '70s, cool kids these days use "other stuff" to
start their services: Services Management Framework.

 nscott> What was the reason for using gcc on OpenSolaris? If core bits like
 nscott> Perl are compiled with the Sun compiler, shouldn't PCP be compiled
 nscott> with that too? 

Simpliest - I've had it installed. Second simple - after installing
SunStudioExpress configure does not think it can compile libgen.h and
other headers, then gmake adding its own stuff to compiler flags like
-Wall. Finally, it's likely that I'll need to link pcp libraries with
Solaris binaries compiled with gcc - all that kind of suggests that I
may want to start with gcc.

 nscott> - how difficult is the packaging side of things on OpenSolaris?
Old SVR4 style seems to be very much like Irix: a manifest, pkginfo to
supply version and package name and you get the package. I'm not yet
comfortable enough with new IPS packaging to comment.

 nscott> - whats the status of Qt4 on OpenSolaris?
NFI.

 nscott> From a quick google search, I'm guessing that KDE (and hence
 nscott> probably Qt) on OpenSolaris is built with the Sun compilers.
 nscott> So, it would seem to be wise to stick with those...?
>From my experince with C++ and Solaris, gcc and SunStudio really don't
like each other: different name mangling, different STL
implementations, different everything. Plain C supposed to be
compatible between gcc and SunStudio.

 nscott> Most of your changes (except builddefs) seem to be independent
 nscott> of compiler used, so I think I'll just pull 'em all in for the
 nscott> next point release and you can follow up on the compiler issue
 nscott> later.
I'll see if I can convince configure what new compiler can grok
libgen...

max

<Prev in Thread] Current Thread [Next in Thread>