setoolkit-developer Mailing List for SE Toolkit (Page 2)
Brought to you by:
dmichelsen
Menu
▾
▴
setoolkit-developer — Developer discussions about changes to come
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(13) |
May
(2) |
Jun
(11) |
Jul
|
Aug
(19) |
Sep
(3) |
Oct
(3) |
Nov
(7) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(12) |
Feb
(3) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2009 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|
From: Tankersley, J. <jon...@ed...> - 2007-11-23 02:51:12
|
I'd expressed some concerns with the inclusion of the orcallator.se file... Orcallator is starting Orcallator has started chrdbt01# "/opt/RICHPse/orcallator/orcallator.se", line 387: Can't find include file orca_p_vmstat_class.se "/opt/RICHPse/include/live_rules.se", line 115: error: syntax error "/opt/RICHPse/include/live_rules.se", line 115: fatal: Errors detected. Exiting. "stdin", line 0: error: syntax error "stdin", line 0: fatal: Errors detected. Exiting. The necessary files aren't included, so I'd say not call it orcallator.se, or we'd have to include more of Orca's patches in the SEToolkit build. But here's the REAL issue. I've got a fairly new Sun system and the most recent package as posted to Sourceforge doesn't work. The version I built from an early 3.4.1 without the e1000 and some other patches didn't work either, but actually RAN for a while before dying with a Segmentation Fault in the disk section. Running the test of the kvmname.se, it gets: host# bin/se examples/kvmname.se Warning: Cannot init kvm: Illegal seek Warning: Kvm not initialized: Variables will have invalid values Segmentation Fault host# /etc/init.d/percol start Warning: Cannot init kvm: Illegal seek Warning: Kvm not initialized: Variables will have invalid values: Near line 6156 It is acting like the AMD kernel stuff isn't available. I've attached some information from the old build's run where it segfaults in the disk section and a compressed copy of the pertinent /var/adm/messages file from boot to 'up and running'. Below is some version info, and a prtdiag. Unfortunately I don't have access to a server of this type with a compiler. host# /opt/RICHPse/bin/se -v se - Version 3.4.1 (08:20 PM 02/28/07) for i386 host# /usr/platform/`arch -k`/sbin/prtdiag System Configuration: Sun Microsystems Sun Fire X4600 M2 BIOS Configuration: American Megatrends Inc. 080012 04/19/2007 BMC Configuration: IPMI 1.5 (KCS: Keyboard Controller Style) =3D=3D=3D=3D Processor Sockets = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Version Location Tag -------------------------------- -------------------------- Dual-Core AMD Opteron(tm) Processor 8220 CPU 1 Dual-Core AMD Opteron(tm) Processor 8220 CPU 2 Dual-Core AMD Opteron(tm) Processor 8220 CPU 3 Dual-Core AMD Opteron(tm) Processor 8220 CPU 4 =3D=3D=3D=3D Memory Device Sockets = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Type Status Set Device Locator Bank Locator ------- ------ --- ------------------- -------------------- DDR2 in use 0 DIMM0 BANK0 DDR2 in use 0 DIMM1 BANK1 =3D=3D=3D=3D On-Board Devices = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D LSI serial-ATA #1 Gigabit Ethernet #1 Gigabit Ethernet #2 ATI Rage XL VGA =3D=3D=3D=3D Upgradeable Slots = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ID Status Type Description --- --------- ---------------- ---------------------------- 0 in use PCI-X PCIX SLOT0 1 available PCI-X PCIX SLOT1 2 available other PCIExp SLOT2 3 available other PCIExp SLOT3 4 available other PCIExp SLOT4 5 available other PCIExp SLOT5 6 available other PCIExp SLOT6 7 available other PCIExp SLOT7 |
|
From: Tankersley, J. <jon...@ed...> - 2007-11-15 21:11:31
|
Think I found it... My svn 'connection' was hosed so I wasn't up to date.=20 -----Original Message----- From: set...@li... [mailto:set...@li...] On Behalf Of Tankersley, Jon Sent: Thursday, November 15, 2007 2:58 PM To: set...@li... Subject: [SEToolkit-developer] Patches for ZFS, e1000g/ipge/bnx, UDP =20 I was noticing that the patches are for the orcallator.cfg, not for orcallator.se. I'm guessing there's a need for a patch there too? I've got a system that someone else supports that has noticed that the e1000gN interfaces in ifconfig shows are NOT being gathered by SEToolkit/orcallator. ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SEToolkit-developer mailing list SET...@li... https://lists.sourceforge.net/lists/listinfo/setoolkit-developer |
|
From: Tankersley, J. <jon...@ed...> - 2007-11-15 20:58:32
|
=20 I was noticing that the patches are for the orcallator.cfg, not for orcallator.se. I'm guessing there's a need for a patch there too? I've got a system that someone else supports that has noticed that the e1000gN interfaces in ifconfig shows are NOT being gathered by SEToolkit/orcallator. |
|
From: Dagobert M. <da...@ba...> - 2007-10-26 11:28:02
|
Hi Alex, Am 26.10.2007 um 12:52 schrieb Alex Kiernan: > Just reading the woes in orca-users (kvm stuff on x86) its clear we > really need to get a 3.5.0 out... Yes, a colleague of mine (Henrik Rathje, hrat) is doing some work on the webpage. I set up tasks for this at http://sourceforge.net/pm/task.php? group_project_id=54035&group_id=189279&func=browse > what do we need to get done? > > Looking at the bugs, I think we need to fix/close these: > > 1778516 Files still reference /opt/RICHPse akiernan This is an important one and requires major work. > 1777670 Documentation build process not converted to autotools > akiernan Looks almost finished. > 1735840 X libraries not found on Solaris 8 with 64 bit dmichelsen Easy to fix. > 1716738 Enhance packaging dmichelsen Almost done, Blastwave package can be released if 3.5.0 is ready. Orca is almost ready, only SMF-manifests for orca graphs are missing. > 1716643 Documentation should be converted to ReST dmichelsen Done for the manual, converted to html and online at http://www.setoolkit.org/cms/node/3 Not much left to fix. The webpage still doesn't look as good as it could be. > and I think we can leave these for the time being: > > 1691307 Build fails on 2.5.1 nobody > 1691280 Errors from live_rules.se on 2.6 nobody Ok. We should leave them unassigned. If no one feels like fixing it we can still change status to "won't fix" > Is there anything else we should be tracking? I'm going to make a > concerted effort to get the ones which need time from me out the way! If the prototype is ready the "two Jons" have offered to stress test the RICHPse- and Blastwave-style packages with all use cases they have. 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 |
|
From: Alex K. <ale...@gm...> - 2007-10-26 10:52:04
|
Just reading the woes in orca-users (kvm stuff on x86) its clear we really need to get a 3.5.0 out... what do we need to get done? Looking at the bugs, I think we need to fix/close these: 1778516 Files still reference /opt/RICHPse akiernan 1777670 Documentation build process not converted to autotools akiernan 1735840 X libraries not found on Solaris 8 with 64 bit dmichelsen 1716738 Enhance packaging dmichelsen 1716643 Documentation should be converted to ReST dmichelsen and I think we can leave these for the time being: 1691307 Build fails on 2.5.1 nobody 1691280 Errors from live_rules.se on 2.6 nobody Is there anything else we should be tracking? I'm going to make a concerted effort to get the ones which need time from me out the way! -- Alex Kiernan |
|
From: Alex K. <ale...@gm...> - 2007-10-17 13:14:50
|
Meant to CC this here, but got the wrong email address :| ---------- Forwarded message ---------- From: Alex Kiernan <ale...@gm...> Date: 17 Oct 2007 14:07 Subject: Patches for ZFS, e1000g/ipge/bnx, UDP To: orc...@or... Cc: set...@so... A number of small patches for orcallator/orca: http://www.alexk1.demon.co.uk/e1000g-ipge-bnx.patch - add e1000g, ipge and bnx interfaces to the list of known GbE interfaces http://www.alexk1.demon.co.uk/zfs.patch - add ZFS to the list of filesystem types which are tracked http://www.alexk1.demon.co.uk/watch-udp.patch - add UDP kstats monitoring -- Alex Kiernan -- Alex Kiernan |
|
From: Dagobert M. <da...@ba...> - 2007-09-21 15:46:06
|
Hi, Am 21.09.2007 um 15:51 schrieb Alex Kiernan: > On 21/09/2007, Jon Craig <can...@gm...> wrote: >> dirent = *((dirent_t *) direnth<18446744071550557968>) >> ksh: 17047 Segmentation Fault > > That sounds a lot like the problem which is fixed in SVN tree by the > pulling readdir code into se itself. Yes, that is http://sourceforge.net/tracker/index.php? func=detail&aid=1698128&group_id=189279&atid=928689 which is fixed in 3.4.1. Best regards -- Dagobert |
|
From: Alex K. <ale...@gm...> - 2007-09-21 13:51:55
|
On 21/09/2007, Jon Craig <can...@gm...> wrote:
> Wondering if anyone else has a SPARC64 VI based platform and/or
> Sol10-09/07 install. We are putting a new M5000 16-Core 32G machine
> into production this weekend and I've run into a spot of trouble with
> "se - Version 3.4 (03:59 PM 01/05/05) for sparcv9". When I run any
> example that excercises diskinfo.se I get a core dump. I've traced it
> down to the portion of diskinfo.se that is using readdir to get file
> names. I've extracted that code into the script (list_dir.se):
>
> main(int argc, string argv[]) {
> string dirname;
> ulong dirh;
> ulong direnth;
> int fdcnt;
> dirent_t dirent;
>
> dirname = sprintf(".");
> if((dirh = opendir(dirname)) != NULL) {
> for(fdcnt = 0; ((direnth = readdir(dirh)) != NULL);fdcnt++) {
> dirent = *((dirent_t *) direnth);
> printf("%04d -> %s\n", fdcnt, dirent.d_name);
> }
> }
> }
>
> When I run this with debug on I eventually get:
>
> fdcnt++;
> dirent = *((dirent_t *) direnth<18446744071550557872>)
> printf(<%04d -> %s\n>, fdcnt<178>, dirent.d_name<c4t5006048AD52EC107d146s0>)
> 0178 -> c4t5006048AD52EC107d146s0
> fdcnt++;
> dirent = *((dirent_t *) direnth<18446744071550557920>)
> printf(<%04d -> %s\n>, fdcnt<179>, dirent.d_name<c4t5006048AD52EC107d146s1>)
> 0179 -> c4t5006048AD52EC107d146s1
> fdcnt++;
> dirent = *((dirent_t *) direnth<18446744071550557968>)
> ksh: 17047 Segmentation Fault
>
> When I get a core dump on a directory, that directory will always dump
> core at the same place, so it's very reproducible. The only thing I
> can see is that the memory address referenced by direnth is fairly
> close to the 64bit boundry, but fairly close shouldn't matter. Any
> thoughts or suggestions would be appreciated. As an aside, we've
> begun using sun drivers and it breaks all the code that assumes the
> target will be an integer number. In fact, the target is now the WWN
> of the device and fairly long. I can send the full debug if anyone wants it.
>
That sounds a lot like the problem which is fixed in SVN tree by the
pulling readdir code into se itself.
--
Alex Kiernan
|
|
From: Jon C. <can...@gm...> - 2007-09-21 13:36:41
|
Wondering if anyone else has a SPARC64 VI based platform and/or
Sol10-09/07 install. We are putting a new M5000 16-Core 32G machine
into production this weekend and I've run into a spot of trouble with
"se - Version 3.4 (03:59 PM 01/05/05) for sparcv9". When I run any
example that excercises diskinfo.se I get a core dump. I've traced it
down to the portion of diskinfo.se that is using readdir to get file
names. I've extracted that code into the script (list_dir.se):
main(int argc, string argv[]) {
string dirname;
ulong dirh;
ulong direnth;
int fdcnt;
dirent_t dirent;
dirname = sprintf(".");
if((dirh = opendir(dirname)) != NULL) {
for(fdcnt = 0; ((direnth = readdir(dirh)) != NULL);fdcnt++) {
dirent = *((dirent_t *) direnth);
printf("%04d -> %s\n", fdcnt, dirent.d_name);
}
}
}
When I run this with debug on I eventually get:
fdcnt++;
dirent = *((dirent_t *) direnth<18446744071550557872>)
printf(<%04d -> %s\n>, fdcnt<178>, dirent.d_name<c4t5006048AD52EC107d146s0>)
0178 -> c4t5006048AD52EC107d146s0
fdcnt++;
dirent = *((dirent_t *) direnth<18446744071550557920>)
printf(<%04d -> %s\n>, fdcnt<179>, dirent.d_name<c4t5006048AD52EC107d146s1>)
0179 -> c4t5006048AD52EC107d146s1
fdcnt++;
dirent = *((dirent_t *) direnth<18446744071550557968>)
ksh: 17047 Segmentation Fault
When I get a core dump on a directory, that directory will always dump
core at the same place, so it's very reproducible. The only thing I
can see is that the memory address referenced by direnth is fairly
close to the 64bit boundry, but fairly close shouldn't matter. Any
thoughts or suggestions would be appreciated. As an aside, we've
begun using sun drivers and it breaks all the code that assumes the
target will be an integer number. In fact, the target is now the WWN
of the device and fairly long. I can send the full debug if anyone wants it.
Cheers,
Jon Craig
|
|
From: Dagobert M. <da...@ba...> - 2007-08-23 08:24:53
|
Hi Alex, Am 21.08.2007 um 13:31 schrieb Alex Kiernan: >> 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/=20 >> workollator_example.sh' >> Current working directory /home/projekte/svn/SEToolkit/trunk/se/=20 >> pkg/sparc >> *** Error code 1 >> make: Fatal error: Command failed for target `all-recursive' >> Current working directory /home/projekte/svn/SEToolkit/trunk/se/=20 >> pkg/sparc >> *** Error code 1 >> make: Fatal error: Command failed for target `all' >> zsh: 14998 exit 1 make >> >> Any ideas why this is happening? >> > > Did you get to the bottom of this? No. I'll recheck this. Best regards -- Dago --=20 Dagobert Michelsen (Leiter IT) Baltic Online Computer GmbH Firmensitz: Alter Markt 1-2, 24103 Kiel, Telefon: +49 431 54003-0 Gesch=E4ftsf=FChrer: 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 |
|
From: Dagobert M. <da...@ba...> - 2007-08-22 23:04:13
|
Hi Jon, Von "Jon Craig" <can...@gm...> (Wed, 22 Aug 2007 15:31:30 -0400): > Fair enough, do we have an officially supported list of releases? > The last release by Rich supported Solaris 8 - 10; SPARC 64bit only, > Intel 32bit only. This is of course supported. Alex did some work to bring back support back to 2.6, there are some problems with 2.5.1 though: http://sourceforge.net/tracker/index.php?func=detail&aid=1691307&group_id=189279&atid=928689 It should be possible right now to build 32/64 bit for Solaris versions between 2.6 and 11 (Nevada), if not this is treated as an error. Best regads -- Dago -- 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 |
|
From: Jon C. <can...@gm...> - 2007-08-22 19:31:36
|
Fair enough, do we have an officially supported list of releases? The last release by Rich supported Solaris 8 - 10; SPARC 64bit only, Intel 32bit only. I have access to several SPARC solaris 8 and 10 boxes, but I would need to martial up resources for the other releases and I would need to find myself an x86 box. On 8/22/07, Dagobert Michelsen <da...@ba...> wrote: > Fellow developers, > > Am 22.08.2007 um 16:17 schrieb Jon Craig: > > Here's an email from my sourceforge account > > (jon...@us...). As for role to play, I > > guess anything thats needed. > > A warm welcome to Jon who just joined the project. As a first task > it would be nice if you could test out what we currently have in the > coming build of 3.5.0 including autoconf-stuff, examples etc. on > current and ancient versions of Solaris Sparc and Solaris x86. > Jon Tankersley is currently working on a standardized test suite > to quickly check for full functionality. As this one is fairly > important to have help is welcome. > > Jon (Tankersley): Can you send me your account-name? > > > Best regards > > -- Dagobert > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > SEToolkit-developer mailing list > SET...@li... > https://lists.sourceforge.net/lists/listinfo/setoolkit-developer > |
|
From: Dagobert M. <da...@ba...> - 2007-08-22 18:45:46
|
Fellow developers, Am 22.08.2007 um 16:17 schrieb Jon Craig: > Here's an email from my sourceforge account > (jon...@us...). As for role to play, I > guess anything thats needed. A warm welcome to Jon who just joined the project. As a first task it would be nice if you could test out what we currently have in the coming build of 3.5.0 including autoconf-stuff, examples etc. on current and ancient versions of Solaris Sparc and Solaris x86. Jon Tankersley is currently working on a standardized test suite to quickly check for full functionality. As this one is fairly important to have help is welcome. Jon (Tankersley): Can you send me your account-name? Best regards -- Dagobert |
|
From: Alex K. <ale...@gm...> - 2007-08-21 12:03:29
|
On 21/08/07, Dagobert Michelsen <da...@ba...> wrote: > Hi, > > Von "Alex Kiernan" <ale...@gm...> (Tue, 21 Aug 2007 06:00:17 +0100): > > On 20/08/07, Dagobert Michelsen <da...@ba...> wrote: > > > as you may have notices I continued to work on the 3.5.0 release. > > > I have already pulled in all include files from Orca which you > > > proposed. > > > > > > Alex: Good to see you working on the docs. > > > > I spotted you'd been doing something and thought I really must get > > around to getting the odds & ends I had comitted! > > doc/se.1m contains the path to the default include path. This > should be automatically adjusted to $seincludedir which is > set in Makefile.am. Should this be set in configure.ac so > se.1m can be modified in AC_CONFIG_FILES or is there a > better alternative? > Ah, there's a bunch of others (startup scripts etc.) which could do with similar treatment. I'll stick a bug in for it. > > > Jon: You said something about throrough script testing. Is there > > > anything you can commit so we can include that in 3.5.0? > > > > Thoughts on 64 bit automagic welcome... from memory we were planning > > on some simple wrappers which would do the right thing? > > How about the configure-directive > --with-memory-model=(auto | 32 | 64) (default=auto) > which adds the 64 bit flags when memory-model=auto and > isainfo -b = 64 or memory-model=64. Compiler flags for > Sun Studio 10, Sun Studio 12 and gcc should be tried then. > My big problem is where to put them and how they interact with the other options. The naive place to put them is CFLAGS, but that's wrong (http://www.gnu.org/software/autoconf/manual/autoconf.html#Preset-Output-Variables), which is where the whole problem gets messy - if I got passed some flags do I start trying to pick out the pieces, or what. Hence why I'd be entirely happy to add: <blink><bold><italic>THE BINARY YOU ARE BUILDING WON'T RUN ON THE PLATFORM YOU'RE COMPILING IT ON</italic></bold></blink> type warning to the autoconf and provide folk with a set of wrappers which pass the right options in (having done the equivalent of a `env -'). Not that I'm bitter about having fought this kind of battle with autoconf'd programs a zillion times you understand... :) -- Alex Kiernan |
|
From: Alex K. <ale...@gm...> - 2007-08-21 11:31:22
|
On 10/04/07, Dagobert Michelsen <da...@ba...> wrote: > 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? > I've done html. I'll look at pdf... > 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? > Did you get to the bottom of this? -- Alex Kiernan |
|
From: Alex K. <ale...@gm...> - 2007-08-21 10:35:02
|
On 05/04/07, Dagobert Michelsen <da...@ba...> wrote: > 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? > It's the only way to do it right, given the way its structured at the moment. We could abstract out those pieces which are OS dependent (and compile these on the relevant platform) then compile what's left on the earliest platform we care about and then dynamically bind all the pieces together at run time. But that seems more effort than it's worth. -- Alex Kiernan |
|
From: Dagobert M. <da...@ba...> - 2007-08-21 08:38:39
|
Hi, Von "Alex Kiernan" <ale...@gm...> (Tue, 21 Aug 2007 06:00:17 +0100): > On 20/08/07, Dagobert Michelsen <da...@ba...> wrote: > > as you may have notices I continued to work on the 3.5.0 release. > > I have already pulled in all include files from Orca which you > > proposed. > > > > Alex: Good to see you working on the docs. > > I spotted you'd been doing something and thought I really must get > around to getting the odds & ends I had comitted! doc/se.1m contains the path to the default include path. This should be automatically adjusted to $seincludedir which is set in Makefile.am. Should this be set in configure.ac so se.1m can be modified in AC_CONFIG_FILES or is there a better alternative? > > Jon: You said something about throrough script testing. Is there > > anything you can commit so we can include that in 3.5.0? > > Thoughts on 64 bit automagic welcome... from memory we were planning > on some simple wrappers which would do the right thing? How about the configure-directive --with-memory-model=(auto | 32 | 64) (default=auto) which adds the 64 bit flags when memory-model=auto and isainfo -b = 64 or memory-model=64. Compiler flags for Sun Studio 10, Sun Studio 12 and gcc should be tried then. Best regards -- Dagobert -- 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 |
|
From: Alex K. <ale...@gm...> - 2007-08-21 05:00:23
|
On 20/08/07, Dagobert Michelsen <da...@ba...> wrote: > Hi, > > as you may have notices I continued to work on the 3.5.0 release. > I have already pulled in all include files from Orca which you > proposed. > > Alex: Good to see you working on the docs. I spotted you'd been doing something and thought I really must get around to getting the odds & ends I had comitted! > Jon: You said something about throrough script testing. Is there > anything you can commit so we can include that in 3.5.0? > Thoughts on 64 bit automagic welcome... from memory we were planning on some simple wrappers which would do the right thing? -- Alex Kiernan |
|
From: Dagobert M. <da...@ba...> - 2007-08-20 14:04:27
|
Hi, as you may have notices I continued to work on the 3.5.0 release. I have already pulled in all include files from Orca which you proposed. Alex: Good to see you working on the docs. Jon: You said something about throrough script testing. Is there anything you can commit so we can include that in 3.5.0? Best regargds -- Dago --=20 Dagobert Michelsen (Leiter IT) Baltic Online Computer GmbH Firmensitz: Alter Markt 1-2, 24103 Kiel, Telefon: +49 431 54003-0 Gesch=E4ftsf=FChrer: 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 |
|
From: Jon C. <can...@gm...> - 2007-08-17 17:04:23
|
> Am 17.08.2007 um 14:47 schrieb Jon Craig: > > I've had several occasions where basic RE just couldn't do what I > > needed and I've longed for full extended REs. > > I am interested in what those occasions are? Biggest one was work I was doing with workollator. I wanted the match to expand to things like multiple users. So the use of grouping with or "(tom|dick|harry)" would be handy. Also, trying to match multiple things in ps_args when building workloads. > > That was my initial > > impetus to getting the SE Toolkit environment to build. What are > > others thoughts on using regcomp/regexec over compile/step to enable > > extended regular expressions. I've got a patch that implements this. > > Please submit the patch as 'gdiff -Naur' at > http://sourceforge.net/tracker/? > atid=928691&group_id=189279&func=browse > For integration checks in autoconf for regex.h are needed and should be > honoured. I'll submit the patch. I noticed that the kstat module is using regcomp over compile, so the binary is already using the other library/functions in a different spot. This is my first work on a "shared" project using sourceforge and my first experience using autoconf/automake, so I'm on a bit of a learning curve. > > The gcc problem has been fixed. Everywhere in the code stdarg.h was > used but in funcs.c :-( > Yeah! |
|
From: Dagobert M. <da...@ba...> - 2007-08-17 13:24:42
|
Hi Jon, Am 17.08.2007 um 14:47 schrieb Jon Craig: > I've had several occasions where basic RE just couldn't do what I > needed and I've longed for full extended REs. I am interested in what those occasions are? > That was my initial > impetus to getting the SE Toolkit environment to build. What are > others thoughts on using regcomp/regexec over compile/step to enable > extended regular expressions. I've got a patch that implements this. Please submit the patch as 'gdiff -Naur' at http://sourceforge.net/tracker/?=20 atid=3D928691&group_id=3D189279&func=3Dbrowse For integration checks in autoconf for regex.h are needed and should be honoured. The gcc problem has been fixed. Everywhere in the code stdarg.h was used but in funcs.c :-( Best regards -- Dagobert --=20 Dagobert Michelsen (Leiter IT) Baltic Online Computer GmbH Firmensitz: Alter Markt 1-2, 24103 Kiel, Telefon: +49 431 54003-0 Gesch=E4ftsf=FChrer: 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 |
|
From: Jon C. <can...@gm...> - 2007-08-17 12:47:51
|
I've had several occasions where basic RE just couldn't do what I
needed and I've longed for full extended REs. That was my initial
impetus to getting the SE Toolkit environment to build. What are
others thoughts on using regcomp/regexec over compile/step to enable
extended regular expressions. I've got a patch that implements this.
gunthar:/lcl/svn/setoolkit/trunk/se> diff -e run.c.orig run.c
2814a
*/
if ((reg_status=regcomp(&re, right.var_un.var_string,
REG_EXTENDED|REG_NOSUB))!= 0)
se_fatal("compile failed: op \"=~\", reason=%d", reg_status);
reg_status = regexec(&re, left.var_un.var_string, (size_t) 0, NULL, 0);
regfree(&re);
return reg_status != 0;
.
2811a
/*
.
2808a
*/
if ((reg_status=regcomp(&re, right.var_un.var_string,
REG_EXTENDED|REG_NOSUB))!= 0)
se_fatal("compile failed: op \"=~\", reason=%d", reg_status);
reg_status = regexec(&re, left.var_un.var_string, (size_t) 0, NULL, 0);
regfree(&re);
return reg_status == 0;
.
2805a
/*
.
2775a
regex_t re;
int reg_status;
.
23c
/* #include <regexpr.h> */
#include <regex.h>
#include <sys/types.h>
.
|
|
From: Dagobert M. <da...@ba...> - 2007-08-17 07:05:35
|
Hello Jon, Am 17.08.2007 um 05:00 schrieb Jon Craig: > Once I got past my gcc issues I noticed that the binaries/objects > being generated were 32bit. When I started toptool as a test I > noticed it complained about not being able to initialize libkvm. I > manually added a '-m64' to my Makefiles to force gcc to build 64bit > binaries and was immediately faced with not have a 64bit version of > libgcc. You do not a gcc build with 64 bit libraries, yes. If you don't want to go through the hassle of building that yourself you can use the one from blastwave which has 64 bit libraries: http://www.blastwave.org/filesearch/gcc3corert > Not wanting to work through building a 64 bit version of libgcc, I > instead resurected by SUN Studio 11 install and re-ran autoreconf to > setup for builds using SUNWspro. While successful, I noticed this too > built 32 bit objects. I again manually added "-xtarget=3Dgeneric64 > -xarch=3Dv9" to my "CFLAGS" line in the Makefile to force 64bit = builds. > This was successful, and comparing the ldd output between this new > build and a 3.4.1 version in /opt/RICHPse, they now match. That's how I make the package, so they really should match ;-) http://setoolkit.svn.sourceforge.net/viewvc/setoolkit/trunk/se/pkg/=20= Makefile?revision=3D23&view=3Dmarkup > Toptool starts like a champ and no longer displays the libkvm error. > If it would be of value I can continue forward with a GCC build, but > lacking an interest by others I would most likely just stick with > SUNWspro. I personally like the idea of being able to choose between gcc and Sun Studio, although I prefer the latter. If you are willing to work on those issues I'll be happy to commit that patch :-) Best regards -- Dagobert --=20 Dagobert Michelsen (Leiter IT) Baltic Online Computer GmbH Firmensitz: Alter Markt 1-2, 24103 Kiel, Telefon: +49 431 54003-0 Gesch=E4ftsf=FChrer: 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 |
|
From: Jon C. <can...@gm...> - 2007-08-17 03:00:44
|
Once I got past my gcc issues I noticed that the binaries/objects being generated were 32bit. When I started toptool as a test I noticed it complained about not being able to initialize libkvm. I manually added a '-m64' to my Makefiles to force gcc to build 64bit binaries and was immediately faced with not have a 64bit version of libgcc. Not wanting to work through building a 64 bit version of libgcc, I instead resurected by SUN Studio 11 install and re-ran autoreconf to setup for builds using SUNWspro. While successful, I noticed this too built 32 bit objects. I again manually added "-xtarget=generic64 -xarch=v9" to my "CFLAGS" line in the Makefile to force 64bit builds. This was successful, and comparing the ldd output between this new build and a 3.4.1 version in /opt/RICHPse, they now match. Toptool starts like a champ and no longer displays the libkvm error. If it would be of value I can continue forward with a GCC build, but lacking an interest by others I would most likely just stick with SUNWspro. |
|
From: Jon C. <can...@gm...> - 2007-08-16 20:06:48
|
I've resolved my issues and got a successful compile with the following patch to "func.c": gunthar:/lcl/svn/setoolkit/trunk/se> diff -e funcs.c.orig funcs.c 98c va_start(args, s); . 23c #include <stdarg.h> . I don't have a copy of SUN Studio so I can't test this patch against it, but hopefully it will compile and alleviate needing conditional configurations. I also had to install SUN Patch 1200050-06 as I was missing two header files included from "mib2.h", which was included by "mib.c". You may want to add these to your autoconf so they can be checked in the future. The missing header files were: #include <sys/tsol/label.h> /* For brange_t */ #include <sys/tsol/label_macro.h> /* For brange_t */ Thanks for you assistance, Jon On 8/16/07, Dagobert Michelsen <da...@ba...> wrote: > 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 > >> > >> > >> > > |
