setoolkit-developer — Developer discussions about changes to come

Re: [SEToolkit-developer] Building SE Toolkit

[Dagobert M. <da...@ba...>]

Hi Jon,

Am 16.08.2007 um 21:05 schrieb Jon Craig:
> Further research shows that GCC no longer support "varargs.h".  I
> installed gcc 3.4.6 (as I was concerned about my current gcc install)
> and it suggests revising code to use "stdarg.h".

Ah, I see. I'll adapt autoconf to check for that.

Best regards

   -- Dagobert


>
> On 8/16/07, Dagobert Michelsen <da...@ba...> wrote:
>> Hello Jon,
>>
>> Am 16.08.2007 um 19:26 schrieb Jon Craig:
>>
>>> I'm trying to build the SE Toolkit and I am receiving the following
>>> error:
>>>
>>> gcc -DHAVE_CONFIG_H -I.  -Dsparc -DDEFAULT_SE_BASEDIR="\"/usr/ 
>>> local"\"
>>> -DDEFAULT_SE_INCLUDE="\"/usr/local/share/se/include\""
>>> -DDEFAULT_SE_LIB="\"/usr/local/lib\""   -g -O2 -MT funcs.o -MD - 
>>> MP -MF
>>> .deps/funcs.Tpo -c -o funcs.o funcs.c
>>> funcs.c: In function `yyerror':
>>> funcs.c:98: error: `__builtin_va_alist' undeclared (first use in
>>> this function)
>>> funcs.c:98: error: (Each undeclared identifier is reported only once
>>> funcs.c:98: error: for each function it appears in.)
>>> funcs.c:98: warning: second parameter of `va_start' not last named
>>> argument
>>> gmake[2]: *** [funcs.o] Error 1
>>> gmake[2]: Leaving directory `/lcl/svn/setoolkit/trunk/se'
>>> gmake[1]: *** [all-recursive] Error 1
>>> gmake[1]: Leaving directory `/lcl/svn/setoolkit/trunk/se'
>>> gmake: *** [all] Error 2
>>>
>>> My build platform includes:
>>> Sun Microsystems  sun4u SUNW,Sun-Blade-1000 (2 X UltraSPARC-III)
>>> GCC v 3.4.2
>>> I've run autoreconf -if in the "trunk/se" directory I pulled from
>>> your SVN.
>>>
>>> Hoping someone could point me in the right direction (like does SE
>>> Toolkit require SUN Studio?).
>>
>> I can reproduce the problem with gcc 3.4.3. SE should be buildable
>> with GCC,
>> so I'll treat this as a bug. SE is definitely buildable with Sun  
>> Studio.
>>
>>
>> Best regards
>>
>>   -- Dagobert
>>
>>
>>

Re: [SEToolkit-developer] Building SE Toolkit

[Dagobert M. <da...@ba...>]

Hello Jon,

Am 16.08.2007 um 19:26 schrieb Jon Craig:

> I'm trying to build the SE Toolkit and I am receiving the following  
> error:
>
> gcc -DHAVE_CONFIG_H -I.  -Dsparc -DDEFAULT_SE_BASEDIR="\"/usr/local"\"
> -DDEFAULT_SE_INCLUDE="\"/usr/local/share/se/include\""
> -DDEFAULT_SE_LIB="\"/usr/local/lib\""   -g -O2 -MT funcs.o -MD -MP -MF
> .deps/funcs.Tpo -c -o funcs.o funcs.c
> funcs.c: In function `yyerror':
> funcs.c:98: error: `__builtin_va_alist' undeclared (first use in  
> this function)
> funcs.c:98: error: (Each undeclared identifier is reported only once
> funcs.c:98: error: for each function it appears in.)
> funcs.c:98: warning: second parameter of `va_start' not last named  
> argument
> gmake[2]: *** [funcs.o] Error 1
> gmake[2]: Leaving directory `/lcl/svn/setoolkit/trunk/se'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/lcl/svn/setoolkit/trunk/se'
> gmake: *** [all] Error 2
>
> My build platform includes:
> Sun Microsystems  sun4u SUNW,Sun-Blade-1000 (2 X UltraSPARC-III)
> GCC v 3.4.2
> I've run autoreconf -if in the "trunk/se" directory I pulled from  
> your SVN.
>
> Hoping someone could point me in the right direction (like does SE
> Toolkit require SUN Studio?).

I can reproduce the problem with gcc 3.4.3. SE should be buildable  
with GCC,
so I'll treat this as a bug. SE is definitely buildable with Sun Studio.


Best regards

   -- Dagobert

[SEToolkit-developer] Building SE Toolkit

[Jon C. <can...@gm...>]

I'm trying to build the SE Toolkit and I am receiving the following error:

gcc -DHAVE_CONFIG_H -I.  -Dsparc -DDEFAULT_SE_BASEDIR="\"/usr/local"\"
-DDEFAULT_SE_INCLUDE="\"/usr/local/share/se/include\""
-DDEFAULT_SE_LIB="\"/usr/local/lib\""   -g -O2 -MT funcs.o -MD -MP -MF
.deps/funcs.Tpo -c -o funcs.o funcs.c
funcs.c: In function `yyerror':
funcs.c:98: error: `__builtin_va_alist' undeclared (first use in this function)
funcs.c:98: error: (Each undeclared identifier is reported only once
funcs.c:98: error: for each function it appears in.)
funcs.c:98: warning: second parameter of `va_start' not last named argument
gmake[2]: *** [funcs.o] Error 1
gmake[2]: Leaving directory `/lcl/svn/setoolkit/trunk/se'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/lcl/svn/setoolkit/trunk/se'
gmake: *** [all] Error 2

My build platform includes:
Sun Microsystems  sun4u SUNW,Sun-Blade-1000 (2 X UltraSPARC-III)
GCC v 3.4.2
I've run autoreconf -if in the "trunk/se" directory I pulled from your SVN.

Hoping someone could point me in the right direction (like does SE
Toolkit require SUN Studio?).

Re: [SEToolkit-developer] How to handle orcallator

[Dagobert M. <da...@ba...>]

Hi Alex,

Am 15.06.2007 um 10:07 schrieb Alex Kiernan:
> On 14/06/07, Dagobert Michelsen <da...@ba...> wrote:
>> Von "Alex Kiernan"  (Thu, 14 Jun 2007 13:19:36 +0100):
>> > We discussed this briefly before and decided to leave orcallator  
>> out
>> > of se (which I still think is the right decision), but I'm  
>> wondering
>> > if workinfo_class.se is really part of SE toolkit rather than
>> > orca/orcallator?
>>
>> I doubt that. It is only included in orcallator.se.
>
> My thinking was really that workinfo_class.se is generic functionality
> which could be used outside orcallator (for example it would be useful
> to add it into zoom).

That's a point. It should be pulled in when zoom.se is updated.
I opened a tracker for this:
   http://sourceforge.net/tracker/index.php? 
func=detail&aid=1737679&group_id=189279&atid=928692

>> > ISTR they
>> > were there because of support getting dropped for various OS  
>> versions
>> > - looks like 3.0 was the last version to support 2.5/2.5.1 (and my
>> > efforts to put it back came unstuck when I hit /proc support)
>>
>> Maybe we should ask Richard in this matter.
>
> I think that'd be useful - I don't have contact details for him.

Could you describe in a technical view what exactly the problem is?
Richard is quite busy and a good prepared question would help in
getting an answer ;-) If you want I can send you his address or
forward your request as you like.

>> > ${SE} -I${ROOTDIR}/lib/SE/3.4 ${OPTIONS} ${ROOTDIR}/lib/ 
>> orcallator.se
>> > ${INTERVAL} /dev/null 2>&1 &
>> >
>> > Maybe we ought to take this to the orcallator mailing lists?
>>
>> Yes. All the issues should be discussed there. Do you prepare a  
>> posting?
>
> Yup.

I am looking forward the discussion :-)


Best regards

   -- Dagobert

-- 
"Of course computer servers don't need thrust, since they generally
don't go anywhere."  -- Comment in TR on new HP server turbine fans

Re: [SEToolkit-developer] How to handle orcallator

[Alex K. <ale...@gm...>]

On 14/06/07, Dagobert Michelsen <da...@ba...> wrote:
> Hi Alex,
>
> Von "Alex Kiernan"  (Thu, 14 Jun 2007 13:19:36 +0100):
> > We discussed this briefly before and decided to leave orcallator out
> > of se (which I still think is the right decision), but I'm wondering
> > if workinfo_class.se is really part of SE toolkit rather than
> > orca/orcallator?
>
> I doubt that. It is only included in orcallator.se.
>

My thinking was really that workinfo_class.se is generic functionality
which could be used outside orcallator (for example it would be useful
to add it into zoom).

> > ISTR they
> > were there because of support getting dropped for various OS versions
> > - looks like 3.0 was the last version to support 2.5/2.5.1 (and my
> > efforts to put it back came unstuck when I hit /proc support)
>
> Maybe we should ask Richard in this matter.
>

I think that'd be useful - I don't have contact details for him.

> > ${SE} -I${ROOTDIR}/lib/SE/3.4 ${OPTIONS} ${ROOTDIR}/lib/orcallator.se
> > ${INTERVAL} /dev/null 2>&1 &
> >
> > Maybe we ought to take this to the orcallator mailing lists?
>
> Yes. All the issues should be discussed there. Do you prepare a posting?
>

Yup.

-- 
Alex Kiernan

Re: [SEToolkit-developer] How to handle orcallator

[Dagobert M. <da...@ba...>]

Hi Alex,

Von "Alex Kiernan"  (Thu, 14 Jun 2007 13:19:36 +0100):
> We discussed this briefly before and decided to leave orcallator out
> of se (which I still think is the right decision), but I'm wondering
> if workinfo_class.se is really part of SE toolkit rather than
> orca/orcallator?

I doubt that. It is only included in orcallator.se.

> I'm trying to figure out how to go about deploying orcallator
> (internally) against an updated SE toolkit, and what to do with the
> updated includes which orcallator ships with. We've merged all the
> changes, but not taken workinfo_class.se across.

Because it is used nowhere in se I see no problem in
leaving it in orca.

> In addition orcallator.se uses the renamed orca_... versions, whereas
> we have all the changes in those now, so we could swap back.

We could, but that change should be done at orca.

> Do we
> still need all the 3.x versions of SE support in orcallator?

IMHO no. But again this is an orca issue.

> ISTR they
> were there because of support getting dropped for various OS versions
> - looks like 3.0 was the last version to support 2.5/2.5.1 (and my
> efforts to put it back came unstuck when I hit /proc support)

Maybe we should ask Richard in this matter.

> , whereas
> I think we've all the pieces to allow a build on 2.6 and later.
> 
> FWIW as a quick fix I'm just hardcoding lib/SE/3.4 for the includes
> dir at the moment, i.e.:

...or just link 3.5 to 3.4

> ${SE} -I${ROOTDIR}/lib/SE/3.4 ${OPTIONS} ${ROOTDIR}/lib/orcallator.se
> ${INTERVAL} /dev/null 2>&1 &
> 
> Maybe we ought to take this to the orcallator mailing lists?

Yes. All the issues should be discussed there. Do you prepare a posting?


Best regards

  -- Dago

[SEToolkit-developer] How to handle orcallator

[Alex K. <ale...@gm...>]

We discussed this briefly before and decided to leave orcallator out
of se (which I still think is the right decision), but I'm wondering
if workinfo_class.se is really part of SE toolkit rather than
orca/orcallator?

I'm trying to figure out how to go about deploying orcallator
(internally) against an updated SE toolkit, and what to do with the
updated includes which orcallator ships with. We've merged all the
changes, but not taken workinfo_class.se across.

In addition orcallator.se uses the renamed orca_... versions, whereas
we have all the changes in those now, so we could swap back. Do we
still need all the 3.x versions of SE support in orcallator? ISTR they
were there because of support getting dropped for various OS versions
- looks like 3.0 was the last version to support 2.5/2.5.1 (and my
efforts to put it back came unstuck when I hit /proc support), whereas
I think we've all the pieces to allow a build on 2.6 and later.

FWIW as a quick fix I'm just hardcoding lib/SE/3.4 for the includes
dir at the moment, i.e.:

${SE} -I${ROOTDIR}/lib/SE/3.4 ${OPTIONS} ${ROOTDIR}/lib/orcallator.se
${INTERVAL} </dev/null >/dev/null 2>&1 &

Maybe we ought to take this to the orcallator mailing lists?

-- 
Alex Kiernan

Re: [SEToolkit-developer] Fwd: Some questions regarding installlocations

[Alex K. <ale...@gm...>]

On 14/06/07, Dagobert Michelsen <da...@ba...> wrote:
> Hi Alex,
>
> Am 14.06.2007 um 10:07 schrieb Alex Kiernan:
> > On 14/06/07, Dagobert Michelsen <da...@ba...> wrote:
> >> > Any solution for packaging I will probably ignore and rebuild a
> >> > complete
> >> > all binary Sun pkg file.
> >>
> >> Ok, so I'll prepare a tgz with the sources for download too.
> >
> > One thing to watch when doing `make dist', if you don't make
> > se-parser.c first it won't get included in the bundle - perhaps we
> > should force dist to depend on $(BUILT_SOURCES)?
>
> Yes. And there are some other files which should be included like
> pkg/. I was thinking of a checkout, autoreconf, remove .svn-stuff
> and tar that. If it is easy to include those files in Makefile.am
> for tardist without getting them installed that would be even bet-
> ter.
>

./configure && make dist

/ought/ to build a tarball which includes everything which goes into a
distribution. make dist-check will tell you if there are things which
are needed which aren't there.

If it doesn't its a bug.

-- 
Alex Kiernan

Re: [SEToolkit-developer] Fwd: Some questions regarding installlocations

[Dagobert M. <da...@ba...>]

Hi Alex,

Am 14.06.2007 um 10:07 schrieb Alex Kiernan:
> On 14/06/07, Dagobert Michelsen <da...@ba...> wrote:
>> > Any solution for packaging I will probably ignore and rebuild a
>> > complete
>> > all binary Sun pkg file.
>>
>> Ok, so I'll prepare a tgz with the sources for download too.
>
> One thing to watch when doing `make dist', if you don't make
> se-parser.c first it won't get included in the bundle - perhaps we
> should force dist to depend on $(BUILT_SOURCES)?

Yes. And there are some other files which should be included like
pkg/. I was thinking of a checkout, autoreconf, remove .svn-stuff
and tar that. If it is easy to include those files in Makefile.am
for tardist without getting them installed that would be even bet-
ter.


Best regards

   -- Dago

-- 
"Of course computer servers don't need thrust, since they generally
don't go anywhere."  -- Comment in TR on new HP server turbine fans

Re: [SEToolkit-developer] Fwd: Some questions regarding installlocations

[Alex K. <ale...@gm...>]

On 14/06/07, Dagobert Michelsen <da...@ba...> wrote:
> > Any solution for packaging I will probably ignore and rebuild a
> > complete
> > all binary Sun pkg file.
>
> Ok, so I'll prepare a tgz with the sources for download too.
>

One thing to watch when doing `make dist', if you don't make
se-parser.c first it won't get included in the bundle - perhaps we
should force dist to depend on $(BUILT_SOURCES)?

-- 
Alex Kiernan

Re: [SEToolkit-developer] Fwd: Some questions regarding installlocations

[Dagobert M. <da...@ba...>]

Hi Jon,

Am 13.06.2007 um 16:40 schrieb Tankersley, Jon:
> For my 2 pfennig's worth...

Since we have Euros now the Pfennig is a bit outdated ;-)

> Any solution for packaging I will probably ignore and rebuild a  
> complete
> all binary Sun pkg file.

Ok, so I'll prepare a tgz with the sources for download too.

> I need to be able to just point people at one
> place and not make them think about it.  As long as the underlying
> structure will support all three to be simultaneously present and work
> properly with the appropriate underlying hardware in place, I'll be
> fine.

Of course all packages should contain similar content (with more or
less examples and contributed stuff).

> I have to live with other guidelines for deployment and I'm not
> sure I can push 'blastwave'.

No need to do. This is just one more option for people who already
get their package from blastwave.

> I don't know if you'd be interested in my 'repackaging' scripts or  
> not.

Sure, maybe there's a hinch I can adopt.


Best regards

   -- Dagobert

-- 
"Of course computer servers don't need thrust, since they generally
don't go anywhere."  -- Comment in TR on new HP server turbine fans

[SEToolkit-developer] Fwd: Some questions regarding install locations

[Alex K. <ale...@gm...>]

On 13/06/07, Dagobert Michelsen <da...@ba...> wrote:
> Hi Alex,
>
> I managed to build a package for blastwave, however the structure
> is quite different:
> - the include files are in $prefix/share/se/include instead of
>   $prefix/include
> - the examples are in $prefix/share/se/examples instead of
>   $prefix/examples

So, I that matches the layout you get with a simple --prefix? I think
we had a conversation in the past where we talked about changing some
of that - I'm afraid I've been off on a number of other things, so
I've somewhat forgotten where we were...

> - the se-binary is now in $prefix/libexec/se.`isainfo -k`
> - $prefix/bin/se is now the script in $workdir/bin/se

If we put the binaries into sparcv7/sparcv9/i86/amd64 subdirectories,
we could use a simple isaexec wrapper (this is what I've used for our
internal stuff for several years), assuming we didn't want to deliver
sparc/x86 within the same package:

#include <stdlib.h>
#include <unistd.h>

int
main(int argc, char *argv[], char *envp[])
{
       return isaexec(getexecname(), argv, envp);
}

I was never very happy with all the voodoo which the se script did
with respect to picking up stuff magically.

> I think it would be a good idea to use these new pathes and
> provide links in the package from the old locations.
>

I agree on the new paths - seems like the right time to make setoolkit
more like everything else (and for blastwave so it fits properly into
the /opt/csw tree).

Is one approach to deliver a RICHPse package which is just a symlink
farm across into CSWsetoolkit (assuming that's what you're naming the
package - I'm just guessing here)?

--
Alex Kiernan

[SEToolkit-developer] Fwd: Some questions regarding install locations

[Dagobert M. <da...@ba...>]

--
Dagobert Michelsen (Leiter IT)          Baltic Online Computer GmbH
Firmensitz:   Alter Markt 1-2, 24103 Kiel, Telefon: +49 431 54003-0
Geschäftsführer:        Erik Cickovskis, Amtsgericht Kiel, HRB 3756
"Of course computer servers don't need thrust, since they generally
don't go anywhere."  -- Comment in TR on new HP server turbine fans


  --- the forwarded message follows ---

Re: [SEToolkit-developer] 32bit access to 64 bit kernel on orca

[Alex K. <ale...@gm...>]

On 02/05/07, Edward Goon/NYLIM <Edw...@ny...> wrote:
>
> Alex
>         I saw on a blog that you were able to resolve a problem with 32 bit
> software from Rich access the 64 bit Opteron kernel. I'm having this trouble
> now and I've updated to the latest Rich se toolkits of 3.4.1 and 3.5, both
> of which still exhibit the problem. I looked at your patch but didn't quite
> understand what you were trying to do. Could you help out and let me know
> how to fix this problem. All I get are segmentation faults.
>

The current SVN tree includes everything which was in those patches
(they were against 3.4 rather than 3.4.1, so getting them to apply
wasn't entirely straightforward).

If you check out the tree from SVN, then you can generate the build
framework using autoconf/automake/libtool using:

autoreconf -if

(we've been using autoconf-2.61, automake-1.10, libtool-1.5.22).

then building like this will get you a 64 bit version:

CPPFLAGS=-xarch=generic64 LDFLAGS=-xarch=generic64 ./configure
make
make install

will get you a 64 bit setoolkit installed/built (assuming you've got
Sun Studio somewhere in your PATH).

Alternatively Dagobert's been working on a package for Blastwave which
is almost certainly an easier route (though I'm not sure how far away
he his from having something ready to release).

-- 
Alex Kiernan

Re: [SEToolkit-developer] SE 3.5.0 and packaging for blastwave

[Dagobert M. <da...@ba...>]

Hi Jon,

Am 07.05.2007 um 17:58 schrieb Tankersley, Jon:
> I've not gotten any feedback from sourceforge folks, so I still can't
> 'log in'.
> I'm going to try to set up another account, but who knows.
>
> What to add....  Hmm.. I'd suggest someone (maybe even me) come up  
> with
> a basic 'test' engine that would test how SEToolkit runs,  
> especially on
> a new build/installation.  The examples are nice, but, they aren't the
> best for 'test and validation'.

Very good, I look forward to the tests!

> I'd agree that we could drop the orcallator stuff, leaving a README  
> with
> some text and a URL to the current location to pick it up.  I'm really
> getting pretty tired with people only getting the ancient copy of Orca
> because Blair won't update that one page.

Ok, a few ideas about this:
- Orca is GPL. Putting an Orca package for download at SF may help
- When I get back to work on the webpage a FAQ with the most common  
errors like 1.37 RAW_DISK_MAP  dirent_t may help some people right away.

> RC scripts.  I've got some RC scripts.  SMF is a bit different, we've
> not tryied to put that in yet (I do NOT have any access to the
> environment where I could work on that, thanks to some strange
> networking 'policies').
>
> I'd even contribute some 'optional' startup configuration.  We run  
> ours
> a bit differently because of some other restrictive policies.
>
> I've got some 'first of month' stuff to finish and then I'll put
> together some stuff to send.  Hopefully I'll have a working account by
> then.

That'll be fine. Some SMF examples are provided at blastwave, so I'll  
try these.


Best regards

   -- Dago

[SEToolkit-developer] SE 3.5.0 and packaging for blastwave

[Dagobert M. <da...@ba...>]

Hi,

I am currently picking up the pieces for release of 3.5.0. The  
following stuff should be in there:
- support for 32/64 bit sparc and i386/amd64
That's basically all the material in trunk/se right now. Do you have  
any more ideas what should go in there?

Regarding orcallator/orcallator.se I am getting the impression that  
it would be best to get rid of it as it is used only by orcallator  
anyway which is bundled with orca.

Additionally I am building a package for blastwave.org. For this  
there is the need to build start-scripts in RC- and SMF-flavor. The  
packaging root will be /opt/csw and all files will be put into bin,  
share, etc, etc. respectively. Let's see if autoconf (or, rather,  
me!) gets this right.


Best regards

   -- Dagobert

Re: [SEToolkit-developer] New Release 3.4.1 of SE Toolkit

[Dagobert M. <da...@ba...>]

Hi Jon,

Von "Tankersley, Jon" <jon...@ed...> (Wed, 11 Apr 2007 15:27:04 -0500):
> Not a problem...  I 'repackage' the package anyway to add some stuff
> we've put together specific for Orca, but tied in with a single package
> for installation (rc scripts, to launch, etc.)

Do you think the scripts may be useful to people outside of your company?

> I DID run into a strange problem....  I got around it, but just so you
> know...
> I'm not sure where the problem lies.
> 
> Rebuilt package
> Pkgadd worked fine.  Orcallator didn't, missing the orca_p_... files.
> Not sure why, but they weren't there in the rebuilt package.  I added
> them and rebuilt again.
> 
> Pkgrm removed everything BUT..... Didn't update
> /var/sadm/install/contents.
> Then things got really strange.  Created a RICHPse.2 and couldn't get
> anything to work again....

You installed the package twice which creates havoc. This is because
MAXINST=1000 instead of 1 in pkginfo. I don't know why Richard put
that in there, maybe for live upgrade in earlier versions which are broken
know.

> Finally removed all RICHPse entries from /var/sadm/install/contents and
> removed any and all RICHP* entries in the pkg directory.  Then I could
> re-install the package.

You could have used pkgrm twice, that should have solved your problem without
manual intervention.


Best regards

  -- Dagobert

Re: [SEToolkit-developer] [Orca-dev] New Release 3.4.1 of SE Toolkit

[Dagobert M. <da...@ba...>]

Hi Jon,

Am 11.04.2007 um 20:55 schrieb Tankersley, Jon:
> Hmm...
>
> The package didn't include an AMD binary.

The binary is dispatched for amd64 but, yes, some things won't work  
without
proper 64 bit binary.

> I was looking at the package information... Should the pkginfo and
> copyright be revised?  They could be a bit confusing.

Yes, you are right about that too. The 3.5 should have all this  
revisited.
I guess it would be a good idea if I send you the package next time  
before
releasing it...

Besides: did you get your SF account running?


Best regards

   -- Dagobert

Re: [SEToolkit-developer] Solaris10 error... (I can't post to the forum yet...)

[Dagobert M. <da...@ba...>]

Hi Jon,

Von "Tankersley, Jon" <jon...@ed...> (Wed, 11 Apr 2007 09:49:32 -0500):
> It looks like this is the case.  Dago mentioned it in a separate email.
> Looks like he built a package too.... I'll see if I can use that,

You should definitely be able to use the package from SF as this is the "official" release ;-)


Best regards

  -- Dago

Re: [SEToolkit-developer] Solaris10 error... (I can't post to the forum yet...)

[Tankersley, J. <jon...@ed...>]

It looks like this is the case.  Dago mentioned it in a separate email.
Looks like he built a package too.... I'll see if I can use that,
otherwise I have to beg/borrow/steal a system to build the binaries.=20

>-----Original Message-----
>From: Dagobert Michelsen [mailto:da...@ba...]=20
>Sent: Wednesday, April 11, 2007 8:53 AM
>To: Alex Kiernan; Tankersley, Jon
>Cc: set...@li...
>Subject: Re: [SEToolkit-developer] Solaris10 error... (I can't=20
>post to the forum yet...)
>
>Hi Alex,
>
>Von "Alex Kiernan" <ale...@gm...> (Wed, 11 Apr 2007=20
>14:39:56 +0100):
>> On 10/04/07, Tankersley, Jon <jon...@ed...> wrote:
>> > Any ideas?  This seems to fail with the normal distribution of=20
>> > SEToolkit and the version I augmented with the AMD stuff (which=20
>> > probably has the same sparv9 binary).
>>=20
>> Is this the same as:
>>=20
>>=20
>https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1698128&gr=
ou
>> p_id=3D189279&atid=3D928689
>
>Yes. I put that one into the tracker as this bug seems to be=20
>the most common one in 3.4.
>It is also the last fix from Richard Pettit which he did prior=20
>to mailing the source to me.
>
>
>Best regards
>
>  -- Dago
>

Re: [SEToolkit-developer] Solaris10 error... (I can't post to the forum yet...)

[Dagobert M. <da...@ba...>]

Hi Alex,

Von "Alex Kiernan" <ale...@gm...> (Wed, 11 Apr 2007 14:39:56 +0100):
> On 10/04/07, Tankersley, Jon <jon...@ed...> wrote:
> > Any ideas?  This seems to fail with the normal distribution of SEToolkit
> > and the version I augmented with the AMD stuff (which probably has the
> > same sparv9 binary).
> 
> Is this the same as:
> 
> https://sourceforge.net/tracker/index.php?func=detail&aid=1698128&group_id=189279&atid=928689

Yes. I put that one into the tracker as this bug seems to be the most common one in 3.4.
It is also the last fix from Richard Pettit which he did prior to mailing the source to me.


Best regards

  -- Dago

Re: [SEToolkit-developer] Solaris10 error... (I can't post to the forum yet...)

[Alex K. <ale...@gm...>]

On 10/04/07, Tankersley, Jon <jon...@ed...> wrote:
>
>
> My 'account' isn't set up to post to the forum... But I'm running into
> an interesting problem.
>
> Sol10 on E2900.  SE seg faults in the disk code regardless.
>
> I've attached what I can -
>        se_trace - se -d output
>        prt - prtdiag -v output
>        disks.out - output from the format command
>
> I don't have a compiler on this server (though I can probably snag one
> if I have to, they aren't ready for production yet).
>
> Any ideas?  This seems to fail with the normal distribution of SEToolkit
> and the version I augmented with the AMD stuff (which probably has the
> same sparv9 binary).
>
>

Is this the same as:

https://sourceforge.net/tracker/index.php?func=detail&aid=1698128&group_id=189279&atid=928689

?

-- 
Alex Kiernan

[SEToolkit-developer] Documentation and other things

[Dagobert M. <da...@ba...>]

Hi,

about documentation:
I converted the user manual to ReST format. Alex, can you
add proper handling of rst2xxx conversion for html, pdf and
man if converion tools are available?

about autoconf:
I have a problem when building with gcc under Solaris 2.6:
root@bopack6:/home/projekte/svn/SEToolkit/trunk/se/pkg/sparc > make
make  all-recursive
Making all in sex/net/lib
make  all-am
Making all in sex/gui/lib
make: Fatal error: Don't know how to make target `adrian/bin/workollator_example.sh'
Current working directory /home/projekte/svn/SEToolkit/trunk/se/pkg/sparc
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /home/projekte/svn/SEToolkit/trunk/se/pkg/sparc
*** Error code 1
make: Fatal error: Command failed for target `all'
zsh: 14998 exit 1     make

Any ideas why this is happening?

about the library-problem I wrote about:
I am currently working my way through the linkers and libraries guide and I think
it should be possible to build a version under Solaris 10 to run on earlier
Solaris version. However, libgen is only supportet as static library in Solaris 2.6
so a different binary may be necessary...


Best regards

  -- Dago

--
"Of course computer servers don't need thrust, since they generally
don't go anywhere."  -- Comment in TR on new HP server turbine fans

[SEToolkit-developer] Library problem when compiling with Studio 11 on Solaris 10

[Dagobert M. <da...@ba...>]

Hi,

when I compile the SE with the latest autoconf on Solaris 10 with SS  
11 everything works fine on
Solaris 10, 9 and 8. However, on Solaris 7 I get linker errors to libc:

bopack7# cd /opt/RICHPse/libexec
bopack7# ./se.sparc
ld.so.1: ./se.sparc: fatal: libc.so.1: version `SUNW_1.19' not found  
(required by file ./se.sparc)
zsh: killed     ./se.sparc
bopack7# ldd se.sparc
         libm.so.1 =>     /usr/lib/libm.so.1
         libkvm.so.1 =>   /usr/lib/libkvm.so.1
         libkstat.so.1 =>         /usr/lib/libkstat.so.1
         libdl.so.1 =>    /usr/lib/libdl.so.1
         libgen.so.1 =>   /usr/lib/libgen.so.1
         libsocket.so.1 =>        /usr/lib/libsocket.so.1
         libnsl.so.1 =>   /usr/lib/libnsl.so.1
         libc.so.1 =>     /usr/lib/libc.so.1
         libc.so.1 (SUNW_1.19) =>         (version not found)
         libelf.so.1 =>   /usr/lib/libelf.so.1
         libmp.so.2 =>    /usr/lib/libmp.so.2
         /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
bopack7# pvs se.sparc
         libm.so.1 (SUNW_1.1);
         libkvm.so.1 (SUNW_1.1);
         libkstat.so.1 (SUNW_0.7);
         libdl.so.1 (SISCD_2.3);
         libgen.so.1 (SUNW_1.1);
         libc.so.1 (SUNW_1.19, SUNWprivate_1.1);
bopack7# pvs /usr/lib/libc.so.1
         libdl.so.1 (SUNW_0.7, SUNWprivate_1.1, SISCD_2.3);
         libc.so.1;
         SUNW_1.18.1;
         SUNW_1.18;
         SUNW_1.17;
         SUNW_1.16;
         SUNW_1.15;
         SUNW_1.14;
         SUNW_1.13;
         SUNW_1.12;
         SUNW_1.11;
         SUNW_1.10;
         SUNW_1.9;
         SUNW_1.8;
         SUNW_1.7;
         SUNW_1.6;
         SUNW_1.5;
         SUNW_1.4;
         SUNW_1.3;
         SUNW_1.2;
         SUNW_1.1;
         SUNW_0.9;
         SUNW_0.8;
         SUNW_0.7;
         SISCD_2.3;
         SYSVABI_1.3;
         SUNWprivate_1.2;
         SUNWprivate_1.1;
bopack7# more /etc/release
                     Solaris 7 11/99 s998s_u4SunServer_10 SPARC
            Copyright 1999 Sun Microsystems, Inc.  All Rights Reserved.
                             Assembled 15 October 1999

Solaris 10 has newer versions included, so I assume that SS 11 always  
binds to libc SUNW_1.19
Is there a way to circumvent this or must we go back to build  
individual versions of se for
different operating systems like it was in 3.3 or so?

Best regards

   -- Dagobert

Re: [SEToolkit-developer] Crosscompiling for unified packaging

[Alex K. <ale...@gm...>]

On 03/04/07, Dagobert Michelsen <da...@ba...> wrote:
> Hi Alex,
>
> your post seems to come from you directly instead of the mailing list. I cited
> all for archive purpose. Have you just replied to my last mail or do I need to
> tweak something in Mailman?
>

Strange - the first one went back to the list direct, so I didn't even
think about it... looks like there's I need to reply to all (which is
what I'd normally do, but didn't even bother looking in this
instance).

> Von "Alex Kiernan" <ale...@gm...> (Mon, 2 Apr 2007 16:32:08 +0100):
> > On 02/04/07, Dagobert Michelsen <da...@ba...> wrote:
> > > Von "Alex Kiernan" <ale...@gm...> (Mon, 2 Apr 2007 10:15:15 +0100):
> > > > On 01/04/07, Dagobert Michelsen <da...@ba...> wrote:
> > > > > > Excellent - it was well worth committing it; your comments managed to
> > > > > > trigger the idea of how to make it build the "right" version for a
> > > > > > particular platform - I'll commit it shortly (I seem to have some
> > > > > > network problems at the moment).
> > > > >
> > > > > This sounds difficult to me. It must produce the correct version for
> > > > > the compiling host regardless of the compiler (SS11 or gcc) and it
> > > > > must be possible to easily overwrite this. I used setting CC to
> > > > > "/opt/SUNWspro/bin/cc -xarch=generic64" which would certainly collide
> > > > > with setting made at a different place in configure.
> > > >
> > > > My thought was to write an autoconf test which did:
> > > >
> > > > #ifdef _LP64
> > > > exit(0);
> > > > #else
> > > > exit(1)
> > > > #endif
> > > >
> > > > which will pick a 64 bit compilation option, no matter how specified,
> > > > then compare the result with what `isainfo -b' says. But you do then
> > > > need another autoconf option which says don't do this magic - on
> > > > balance, perhaps the warning is the better option. Also once you need
> > > > to do `isainfo -b', the option of cross-compiling goes out of the
> > > > window.
> > >
> > > Not necessarily. I'll expect a warning if the built binary is not suitable
> > > for the running kernel. A test with kvm_open might be more meaningful.
> > > On crosscompilation the binary won't execute and would issue a warning too.
> > >
> >
> > On a cross compile, it'd pick up the cross-compile setting from the
> > AC_... macro - for that I'd just set it to success (on the assumption
> > that if you're building using a cross you really ought to know what
> > you're doing).
>
> Ok.
>

I'll start sorting the pieces so you get a warning when it knows its
likely to be wrong.

> > > > > Should we attempt to port/investigate/document how the examples
> > > > > match to D-scripts?
> > > >
> > > > I'm not sure its worth the effort (but I guess it depends to an extent
> > > > on whether we think anyone is using se for anything more than an
> > > > orcallator base).
> > >
> > > This may be a good finger exercise for me (and others?) to become
> > > more familiar with kernel structures and D-Trace.
> > >
> > > Here are the next steps I planned:
> > > - put out a RICHPse-package for 3.4.1 on SF. The changelog must be
> > >  adjusted for the fixed issues.
> > > - repackage for blastwave.org
> > >  For this the package-name needs to be configurable. Ad hoc I would say
> > >  autoconf is not needed for this but I haven't checked the code yet.
> > >  The integration of a current version of orca (r529) needs some packages
> > >  which are installed during Orca install. This dependency can be resolved
> > >  easily with dependencies to existing Blastwave-packages. I am unsure
> > >  how to handle this for the RICHPse-style package. Any ideas?
> > > - version 3.5.0 should include autoconf (of course) and a current Orca.
> > >  Further ideas?
> >
> > I'd be inclined to split orcallator from setoolkit and orca (which
> > actually is what we've done - we install an setoolkit and orcallator
> > package on machines, and then an orca package elsewhere).
>
> Should orcallator go to orca or stay with setoolkit?

My view is orcallator should either be separate, or part of setoolkit,
but definitely not part of an orca package. I like orcallator
separate, because that way it's clear what auto-started functionality
is being delivered (but if it was part of setoolkit, I wouldn't argue
too hard).

> Should it be necessary to install orca just for the orcallator?

No - here we install an setoolkit and an orcallator package on every
host, then rsync all the data onto a pair of central servers which
then runs orca.

> Maybe we should put the updated libs in orca and continue
> to include a current version of the orcallator.

Certainly we should pull the updated libs, though there are a couple
of new classes which orcallator uses which weren't in setoolkit
originally (the workload stuff) - we'd need to clarify the licensing
on those (I think).

-- 
Alex Kiernan