Re: perl 5.8.4 is out

[Stas Bekman]

It seems that a few people have some problems with 5.8.4. So to repeat again, 
if you have problems please do report them to the perl5porters list via 
perlbug. If you don't report problems, they won't get fixed. The instructions 
are available from here:

  http://search.cpan.org/~nwclark/perl-5.8.4/pod/perl584delta.pod#Reporting_Bugs

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

[RELEASE CANDIDATE] GTop 0.13

[Stas Bekman]

For those wondering what GTop has to do with modperl, it's needed for 
Apache::VMonitor and we also use it the mod_perl core maintenance to trace 
memory leaks and just bad memory bloats. We wish we had a different lib to 
interface but there is nothing better known to us at the moment. So please 
bear with us.

A new version of libgtop was released, which (2.0.5+) no longer worked with 
GTop-0.12, so thanks to Radoslaw Zielinski this new release candidate may work 
for you. Please test this version:

  http://apache.org/~stas/GTop-0.13.tar.gz

Especially if you have libgtop < 2.6.0. since that's the only version GTop 
0.13 was tested with so far. Thanks.

[BTW, I saw that libgtop 2.8.0 is out, but I didn't try it...]

Changes since 0.12:

0.13 - Mon Apr 26 23:28:44 PDT 2004

- Makefile.PL cleanups by Radoslaw Zielinski <[EMAIL PROTECTED]>.

- adjust the build/source to support glibtop 2.5+. Thanks to Radoslaw
  Zielinski <[EMAIL PROTECTED]> for the help and patches.
- include the t/threads.t in the distro

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: GTop-0.12 compile and installation problems

[Pete Geenhuizen]

Stas,
Well this is all very dissappointing.  I compiled and installed
libgtool-2.0.1 because none of he more recent version would compile with
the exception of libgtool-2.0.6, but that version is missing xmalloc.h.

Unfortunately GTop still won't compile.

So now I don't know what to do.  No matter what I try I can't seem to make
any headway.  So I guess I'll just have to pass on this until someone can
figure out what it takes to get this working.

Pete
-- 
"Unencumbered by the thought process"
--1992-2000 Click and Clack presidential campaign slogan

Stas Bekman said:
> Pete Geenhuizen wrote:
>> Stas,
>> Thanks for the reply, unfortunately no such luck with this version I'm
>> afraid but a little progress non the less.
>>
>> My version of libgtop 2.6.0 doesn't have xmalloc.h, I changed that to
>> malloc.h which got me passed that, and now the Server compiles, and now
>> I
>> get the attached errs errors.  There's an xmalloc.h error here as well.
>
> Yeah, I had the same issue. I simply copied xmalloc.h (w/ some
> adjustments)
> from the glibtop source. But it's not enough since the .so lib is compiled
> w/o
> xmalloc.[ch] symbols, so it won't work anyway.
>
> In any case this is a problem w/ bleed edge systems, the stable version
> works
> fine. So meanwhile try installing the older libs.
>
> I've emailed Frederic Crozat, the mandrake packager, asking why that
> interface
> was dropped. I've CC'ed him to this email. It looks like at least on
> mandrake
> a whole bunch of shared libraries is gone:
>
> The older has:
>
> /tmp/libgtop-2.0.6/lib/.libs> ldd /usr/lib/libgtop-2.0.so.0.0.8
>  linux-gate.so.1 =>  (0xe000)
>  libgtop_common-2.0.so.0 => /usr/lib/libgtop_common-2.0.so.0
> (0x4001e000)
>  libgtop_sysdeps-2.0.so.0 => /usr/lib/libgtop_sysdeps-2.0.so.0
> (0x40023000)
>  libc.so.6 => /lib/tls/libc.so.6 (0x4002d000)
>  libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x40175000)
>  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)
>
> The bleed version has too few libs:
>
> /tmp/libgtop-2.0.6/lib/.libs> ldd /usr/lib/libgtop-2.0.so.2.1.0
>  linux-gate.so.1 =>  (0xe000)
>  libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x40027000)
>  libc.so.6 => /lib/tls/libc.so.6 (0x40093000)
>  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)
>
> But if I build 2.0.6 by myself from tar.gz source, I get the same libs as
> the
> older version. So I hope Frederic can help us here.
>
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org   http://ticketmaster.com
>


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: GTop-0.12 compile and installation problems

[Radoslaw Zielinski]

Stas Bekman <[EMAIL PROTECTED]> [27-04-2004 00:15]:
> Cool, so we have Radoslaw, who understands in glib/gnome and forwarded a 
[...]

Uh, not really... :-)  I just poked around in the *.h files / libgtop's
documentation / changelogs and hacked it until it built.

> Radoslaw, do you know how can we #ifdef on 2.0.6 in the C code? I spent 
> hours trying to figure it out but in vain. The only way I see is to run

> pkgconfig --modversion libgtop-2.0

Looks like a proper solution to me.

> and then define our own define, which I did here:
> http://apache.org/~stas/GTop-0.13.tar.gz (which is not quite working, 
> because of the missing glibtop_free symbol.)

Changelog says, that all custom memory management routines have been
substituted by those from glib.  Therefore, glibtop_free became g_free.
I couldn't find any references to glibtop_free_r (I'm too lazy to search
in diffs between versions ;-), but it appears, that only the second
(IIRC) argument needs to be freed, so I used the g_free as well.

-- 
Radosław Zieliński <[EMAIL PROTECTED]>
[ GPG key: http://radek.karnet.pl/ ]


pgp0.pgp
Description: PGP signature

Re: GTop-0.12 compile and installation problems

[Pete Geenhuizen]

Stas,
Right after I had decided to hold off on this I get this email, and now
I'm confused.

If I use xmalloc.h I get all sorts of errors, so I went back to
libgtop-2.0.6 and changed xmalloc.h to the Solaris version of malloc.h. 
That allowed the Server to build, however GTop still fails with the
following errors

GTop.xs: In function `XS_GTop_field_u_int64_t':
GTop.xs:112: error: `u_int64_t' undeclared (first use in this function)
GTop.xs:112: error: (Each undeclared identifier is reported only once
GTop.xs:112: error: for each function it appears in.)
GTop.xs:112: error: `ptr' undeclared (first use in this function)
GTop.xs:112: error: parse error before ')' token
GTop.c: In function `XS_GTop__Mountentry_dev':
GTop.c:1050: error: `u_int64_t' undeclared (first use in this function)
GTop.c:1050: error: parse error before "RETVAL"
GTop.c:1066: error: `RETVAL' undeclared (first use in this function)
GTop.c: In function `XS_GTop__MapEntry_flags':
GTop.c:1149: error: `u_int64_t' undeclared (first use in this function)
GTop.c:1149: error: parse error before "RETVAL"
GTop.c:1165: error: `RETVAL' undeclared (first use in this function)
GTop.c: In function `XS_GTop__MapEntry_start':
GTop.c:1180: error: `u_int64_t' undeclared (first use in this function)
GTop.c:1180: error: parse error before "RETVAL"
GTop.c:1196: error: `RETVAL' undeclared (first use in this function)
GTop.c: In function `XS_GTop__MapEntry_end':
GTop.c:1211: error: `u_int64_t' undeclared (first use in this function)
GTop.c:1211: error: parse error before "RETVAL"
GTop.c:1227: error: `RETVAL' undeclared (first use in this function)
GTop.c: In function `XS_GTop__MapEntry_offset':
GTop.c:1242: error: `u_int64_t' undeclared (first use in this function)
GTop.c:1242: error: parse error before "RETVAL"
GTop.c:1258: error: `RETVAL' undeclared (first use in this function)
GTop.c: In function `XS_GTop__MapEntry_perm':
GTop.c:1273: error: `u_int64_t' undeclared (first use in this function)
GTop.c:1273: error: parse error before "RETVAL"
GTop.c:1289: error: `RETVAL' undeclared (first use in this function)
GTop.c: In function `XS_GTop__MapEntry_inode':
GTop.c:1304: error: `u_int64_t' undeclared (first use in this function)
GTop.c:1304: error: parse error before "RETVAL"
GTop.c:1320: error: `RETVAL' undeclared (first use in this function)
GTop.c: In function `XS_GTop__MapEntry_device':
GTop.c:1335: error: `u_int64_t' undeclared (first use in this function)
GTop.c:1335: error: parse error before "RETVAL"
GTop.c:1351: error: `RETVAL' undeclared (first use in this function)
make: *** [GTop.o] Error 1

So all in all I'm still not getting too far.

Pete
-- 
"Unencumbered by the thought process"
--1992-2000 Click and Clack presidential campaign slogan

Stas Bekman said:
> Cool, so we have Radoslaw, who understands in glib/gnome and forwarded a
> patch :)
>
> We still need to support older libgtop, so it can't be applied as is. Need
> to
> figure out how to keep both generations working. But meanwhile Pete and
> Paul,
> try Radoslaw's patch (attached).
>
> Radoslaw, do you know how can we #ifdef on 2.0.6 in the C code? I spent
> hours
> trying to figure it out but in vain. The only way I see is to run
>
> pkgconfig --modversion libgtop-2.0
>
> and then define our own define, which I did here:
> http://apache.org/~stas/GTop-0.13.tar.gz (which is not quite working,
> because
> of the missing glibtop_free symbol.)
>
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org   http://ticketmaster.com
>


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: GTop-0.12 compile and installation problems

[Radoslaw Zielinski]

Stas Bekman <[EMAIL PROTECTED]> [27-04-2004 01:00]:
> Radoslaw Zielinski wrote:
>> Stas Bekman <[EMAIL PROTECTED]> [27-04-2004 00:15]:
[...]
> >>http://apache.org/~stas/GTop-0.13.tar.gz (which is not quite working, 
> >>because of the missing glibtop_free symbol.)
>> Changelog says, that all custom memory management routines have been
>> substituted by those from glib.  Therefore, glibtop_free became g_free.
>> I couldn't find any references to glibtop_free_r (I'm too lazy to search
>> in diffs between versions ;-), but it appears, that only the second
>> (IIRC) argument needs to be freed, so I used the g_free as well.
> which Changelog you are reffering to? libgtop-2.0.6/ChangeLog from the 
> source package doesn't mention anything like that.

Yes, it does (libgtop-2._6.0_, of course):

  2003-10-20  Bastien Nocera  <[EMAIL PROTECTED]>
  [...]
  * lib/xmalloc.c: removed xmalloc.h
  replace all the xmalloc crap by glib memory management functions

Maybe not in the most greppable way, unless you search for (missing)
xmalloc.h... ;-)

> I need to know an exact version where this has happened so I can ifdef
> properly.

  2003-10-20  Bastien Nocera  <[EMAIL PROTECTED]>
  * Makefile.am: fix distchecking, release 2.5.0

-- 
Radosław Zieliński <[EMAIL PROTECTED]>
[ GPG key: http://radek.karnet.pl/ ]


pgp0.pgp
Description: PGP signature

Re: new version Re: GTop-0.12 compile and installation problems

[Radoslaw Zielinski]

Stas Bekman <[EMAIL PROTECTED]> [27-04-2004 02:04]:
> Ok, please try this candidate:
> http://apache.org/~stas/GTop-0.13.tar.gz

> I have tested it only with 2.6.0. I hope it is still working with earlier 
> ones.

Doesn't work with 2.6.0 (unless you have the xmalloc.h from some old
installation).

  [...]
  athlon-pld-linux-gcc -c  -I/usr/include/libgtop-2.0 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include   -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS 
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-O2 -march=athlon   -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" -fPIC 
"-I/usr/lib/perl5/5.8.4/athlon-pld-linux-thread-multi/CORE"   io.c
  In file included from io.c:24:
  daemon.h:34:29: glibtop/xmalloc.h: Nie ma takiego pliku ani katalogu
  [...]

-- 
Radosław Zieliński <[EMAIL PROTECTED]>
[ GPG key: http://radek.karnet.pl/ ]


pgp0.pgp
Description: PGP signature

Re: new version Re: GTop-0.12 compile and installation problems

[Radoslaw Zielinski]

Stas Bekman <[EMAIL PROTECTED]> [27-04-2004 06:30]:
> Radoslaw Zielinski wrote:
>> Stas Bekman <[EMAIL PROTECTED]> [27-04-2004 02:04]:
>>> Ok, please try this candidate:
[...]
>>> I have tested it only with 2.6.0. I hope it is still working with earlier 
>>> ones.
>> Doesn't work with 2.6.0 (unless you have the xmalloc.h from some old
>> installation).
[...]
>>   daemon.h:34:29: glibtop/xmalloc.h: Nie ma takiego pliku ani katalogu
[...]
> Nie ma, tak nie ma :) This means that my hack to insert -DGTOP_2_5_PLUS 

Oops, forgotten locale ;-)

> define doesn't work for you. Check Server/Makefile.PL it loads config.pl 
> and calls the code that should insert -DGTOP_2_5_PLUS define.

It works, error was elsewhere.  I didn't built it "by hand", but by
changing the version in the .spec file.  It contained:

  GTOP_LIB="`pkg-config --libs libgtop-2.0`" \
  GTOP_INCLUDE="`pkg-config --cflags libgtop-2.0`" \
  %{__perl} Makefile.PL \
  INSTALLDIRS=vendor
  %{__make} \
  OPTIMIZE="%{rpmcflags}" \
  INC="`pkg-config --cflags libgtop-2.0`" \
  EXTRALIBS="`pkg-config --libs libgtop-2.0`

After removing all (but INSTALLDIRS and OPTIMIZE) variable definitions,
it worked fine.  You assigned the -DGTOP_2_5_PLUS to INC; this caused
the problem, as it was overwritten...  I'd suggest using the DEFINE
argument for WriteMakefile; patch attached.

BTW #1: I never touched XS, but things like this always turn my "search
for memory leaks" warning on...
  PERL_DL_NONLAZY=1 /usr/bin/perl5.8.4 [...]
  t/basic..ok  
  t/threadsok 3/6Attempt to free unreferenced scalar: SV 0x8219bb8 during global 
destruction.
  t/threadsok 4/6Attempt to free unreferenced scalar: SV 0x8258008 during global 
destruction.
  t/threadsok 5/6Attempt to free unreferenced scalar: SV 0x822f660 during global 
destruction.
  t/threadsok  
  All tests successful.

BTW #2: `perl -w Makefile.PL` looks rather messy... ;-)

-- 
Radosław Zieliński <[EMAIL PROTECTED]>
[ GPG key: http://radek.karnet.pl/ ]
diff -ur GTop-0.13/config.pl GTop-0.13.new/config.pl
--- GTop-0.13/config.pl 2004-04-27 01:51:05.0 +0200
+++ GTop-0.13.new/config.pl 2004-04-27 07:01:54.937378080 +0200
@@ -30,10 +30,10 @@
 $gver = '';
 }
 
-my $inc  = join " ", $GTOP_INCLUDE, $gver, $ginc, $config{incs};
+my $inc  = join " ", $GTOP_INCLUDE, $ginc, $config{incs};
 my $libs = join " ", $GTOP_LIB, $config{libs};
 
-return ($inc, $libs);
+return ($inc, $libs, $gver);
 }
 
 sub get_glibtop_config_core {
Tylko w GTop-0.13.new: GTop.pod
diff -ur GTop-0.13/Makefile.PL GTop-0.13.new/Makefile.PL
--- GTop-0.13/Makefile.PL   2004-04-27 01:50:26.0 +0200
+++ GTop-0.13.new/Makefile.PL   2004-04-27 07:06:23.588536896 +0200
@@ -247,7 +247,7 @@
 }
 
 require "./config.pl";
-my($inc, $libs) = get_glibtop_config();
+my($inc, $libs, $defines) = get_glibtop_config();
 
 if (DEBUG) {
 warn "Using INC: $inc\n";
@@ -260,6 +260,7 @@
VERSION_FROM => 'lib/GTop.pm',
INC  => $inc,
LIBS => [$libs],
+   DEFINE   => $defines,
TYPEMAPS => [qw(typemap.gtop typemap)],
PREREQ_PM=> \%prereq,
clean=> {
diff -ur GTop-0.13/Server/Makefile.PL GTop-0.13.new/Server/Makefile.PL
--- GTop-0.13/Server/Makefile.PL2004-04-27 01:44:13.0 +0200
+++ GTop-0.13.new/Server/Makefile.PL2004-04-27 07:05:13.446200152 +0200
@@ -26,13 +26,14 @@
 close CONST;
 
 require "../config.pl";
-my($inc, $libs) = get_glibtop_config();
+my($inc, $libs, $defines) = get_glibtop_config();
 
 WriteMakefile(
 NAME => "GTop::Server",
 VERSION_FROM => "Server.pm",
 INC  => $inc,
 LIBS => [split /\s+/, $libs],
+DEFINE => $defines,
 OBJECT => 'io.o main.o gnuserv.o version.o access.o Server.o',
 clean   => {
FILES => "server_config_flags.h constants.c",


pgp0.pgp
Description: PGP signature

Re: new version Re: GTop-0.12 compile and installation problems

[Radoslaw Zielinski]

Stas Bekman <[EMAIL PROTECTED]> [27-04-2004 07:59]:
> Radoslaw Zielinski wrote:
[...]
>>  t/threadsok 5/6Attempt to free unreferenced scalar: SV 0x822f660 
>>  during global destruction.
>>  t/threadsok  
>>  All tests successful.
> That's a bug in perl:
[...]

Uh.

>> BTW #2: `perl -w Makefile.PL` looks rather messy... ;-)
> Yeah, thanks. fixed all but this one:

> Argument "" isn't numeric in numeric lt (<) at 
> /usr/lib/perl5/5.8.3/ExtUtils/MakeMaker.pm line 390.

--- Makefile.PL~2004-04-27 07:49:29.0 +0200
+++ Makefile.PL 2004-04-27 08:11:16.996648896 +0200
@@ -9,7 +9,7 @@
 use constant DEBUG => 1;
 
 my %prereq = (
-"Test::More" => "",
+"Test::More" => 0,
 );
 
 my %interface = (

> There is no numeric lt at that line. If you can take a look and report a 
> bug to the makemaker list that would be great.

That line contains "if ()..."; our evil operator is used few lines later
in corresponding elsif, which belongs to the same #line from perl's
point of view.

Reporting it would IMHO be a waste of bits, as it's (at least somehow)
documented; man ExtUtils::MakeMaker:

  PREREQ_PM
  [...]
desired version is the value. If the required version number is 0, we
only check if any version is installed already.

-- 
Radosław Zieliński <[EMAIL PROTECTED]>
[ GPG key: http://radek.karnet.pl/ ]


pgp0.pgp
Description: PGP signature

Re: new version Re: GTop-0.12 compile and installation problems

[Pete Geenhuizen]

Well a little headway, the Server compiles but not GTop.  In case it
matters, Solaris 9 doesn't have pkgconfig, it does have pkg-config.

Here's the output from the build and make.

Pete
-- 
"Unencumbered by the thought process"
--1992-2000 Click and Clack presidential campaign slogan

Stas Bekman said:
>
>> That line contains "if ()..."; our evil operator is used few lines later
>> in corresponding elsif, which belongs to the same #line from perl's
>> point of view.
>
> Ah cool, I've committed the fix, thanks!
>
>> Reporting it would IMHO be a waste of bits, as it's (at least somehow)
>> documented; man ExtUtils::MakeMaker:
>>
>>   PREREQ_PM
>>   [...]
>> desired version is the value. If the required version number is 0,
>> we
>> only check if any version is installed already.
>
> Yeah, but when you get a huge chunk of code that you didn't write and need
> to
> figure out where this warning is coming from, it is helpful for the core
> application to give you the hint. At least set to call Carp::cluck. but
> never
> mind :)
>
> so if you are happy with it now, I'll post a release candidate and release
> a
> new version tomorrow, unless someone complains (e.g. i haven't tested it
> with
> pre-2.5.0, which the changes may have broken, I hope not :)
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org   http://ticketmaster.com
>
Script started on Tue Apr 27 05:32:55 2004
{root} 5:32:56am[41]: perl Makefile.PL
Using INC:   -I/usr/local/include/libgtop-2.0 -I/usr/local/include/glib-2.0 
-I/usr/local/lib/glib-2.0/include  
Using LIBS:  -R/usr/X11R6.4/lib -L/usr/local/lib -L/usr/local/lib -L/usr/X11R6.4/lib 
-lXau -lgtop-2.0 -lglib-2.0  
Checking if your kit is complete...
Looks good
Note (probably harmless): No library found for -lXau
Writing Makefile for GTop::Server
Writing Makefile for GTop
{root} 5:33:05am[42]: make
cp lib/GTop.pm blib/lib/GTop.pm
cp GTop.pod blib/lib/GTop.pod
cp config.pl blib/lib/config.pl
make[1]: Entering directory `/export/data/xfer/GTop-0.13/Server'
cp Server.pm ../blib/lib/GTop/Server.pm
cc -c  -I/usr/local/include/libgtop-2.0 -I/usr/local/include/glib-2.0 
-I/usr/local/lib/glib-2.0/include   -fno-strict-aliasing -I/usr/local/include 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O   -DVERSION=\"0.01\" 
-DXS_VERSION=\"0.01\" -fPIC "-I/usr/local/lib/perl5/5.8.2/sun4-solaris/CORE"  
-DGTOP_2_5_PLUS io.c
cc -c  -I/usr/local/include/libgtop-2.0 -I/usr/local/include/glib-2.0 
-I/usr/local/lib/glib-2.0/include   -fno-strict-aliasing -I/usr/local/include 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O   -DVERSION=\"0.01\" 
-DXS_VERSION=\"0.01\" -fPIC "-I/usr/local/lib/perl5/5.8.2/sun4-solaris/CORE"  
-DGTOP_2_5_PLUS main.c
cc -c  -I/usr/local/include/libgtop-2.0 -I/usr/local/include/glib-2.0 
-I/usr/local/lib/glib-2.0/include   -fno-strict-aliasing -I/usr/local/include 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O   -DVERSION=\"0.01\" 
-DXS_VERSION=\"0.01\" -fPIC "-I/usr/local/lib/perl5/5.8.2/sun4-solaris/CORE"  
-DGTOP_2_5_PLUS gnuserv.c
cc -c  -I/usr/local/include/libgtop-2.0 -I/usr/local/include/glib-2.0 
-I/usr/local/lib/glib-2.0/include   -fno-strict-aliasing -I/usr/local/include 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O   -DVERSION=\"0.01\" 
-DXS_VERSION=\"0.01\" -fPIC "-I/usr/local/lib/perl5/5.8.2/sun4-solaris/CORE"  
-DGTOP_2_5_PLUS version.c
cc -c  -I/usr/local/include/libgtop-2.0 -I/usr/local/include/glib-2.0 
-I/usr/local/lib/glib-2.0/include   -fno-strict-aliasing -I/usr/local/include 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O   -DVERSION=\"0.01\" 
-DXS_VERSION=\"0.01\" -fPIC "-I/usr/local/lib/perl5/5.8.2/sun4-solaris/CORE"  
-DGTOP_2_5_PLUS access.c
/usr/local/bin/perl /export/usr/lib/perl5/5.8.2/ExtUtils/xsubpp  -typemap 
/usr/local/lib/perl5/5.8.2/ExtUtils/typemap -typemap typemap  Server.xs > Server.xsc 
&& mv Server.xsc Server.c
Please specify prototyping behavior for Server.xs (see perlxs manual)
cc -c  -I/usr/local/include/libgtop-2.0 -I/usr/local/include/glib-2.0 
-I/usr/local/lib/glib-2.0/include   -fno-strict-aliasing -I/usr/local/include 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O   -DVERSION=\"0.01\" 
-DXS_VERSION=\"0.01\" -fPIC "-I/usr/local/lib/perl5/5.8.2/sun4-solaris/CORE"  
-DGTOP_2_5_PLUS Server.c
Running Mkbootstrap for GTop::Server ()
chmod 644 Server.bs
rm -f ../blib/arch/auto/GTop/Server/Server.so
LD_RUN_PATH="/usr/local/lib" cc  -G -L/usr/local/lib io.o main.o gnuserv.o version.o 
access.o Server.o  -o ../blib/arch/auto/GTop/Server/Server.so   -lgtop-2.0   
chmod 755 ../blib/arch/auto/GTop/Server/Server.so
cp Server.bs ../blib/arch/auto/GTop/Server/Server.bs
chmod 644 ../blib/arch/auto/GTop/Server/Server.bs
make[1]: Leaving directory `/export/data/xfer/GTop-0.13/Server'
/usr/loca

[MP2] apachectl doesn't run PerlModule code?

[John Wittkoski]

-8<-- Start Bug Report 8<--
1. Problem Description:

Running 'apachectl configtest' doesn't seem to run perl code in httpd.conf.

Perhaps I'm doing something wrong here, but according to the docs, 
running 'apachectl configtest' should run any perl code in http.conf (or 
included files) specified by PerlModule and/or PerlRequire.

This is using apache 2.0.49 and mod_perl 1.99_13 with perl 5.8.3 on OS X 
10.3 (NOT using the default apache and perl that Apple supplies, these 
were built as myself in a test directory).

For example, if I put the following at the end of an almost generic 
httpd.conf (only host and port changed from the default install):

LoadModule perl_module modules/mod_perl.so
PerlModule Not::Here

Running 'apachectl start' fails as expected because Not::Here doesn't exist.

Running 'apachectl configtest' reports 'Syntax OK'.

If I create an actual file for Not::Here, but put invalid perl code in 
it, I get similar results.

Did I miss a config step here or is this broken? A similar setup with 
Apache 1.3.29 and mod_perl 1.29 works as expected.

Note that mod_perl in all other respects works fine in this same setup, 
it is only the behavior of 'apachectl configtest' that seems odd.



2. Used Components and their Configuration:

*** mod_perl version 1.9913

*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
   MP_AP_PREFIX   => /Users/jpw/web2/httpd
   MP_COMPAT_1X   => 1
   MP_GENERATE_XS => 1
   MP_LIBNAME => mod_perl
   MP_USE_DSO => 1
   MP_USE_STATIC  => 1


*** /Users/jpw/web2/httpd/bin/httpd -V
Server version: Apache/2.0.49
Server built:   Apr 27 2004 11:22:15
Server's Module Magic Number: 20020903:7
Architecture:   32-bit
Server compiled with
  -D APACHE_MPM_DIR="server/mpm/prefork"
  -D APR_HAS_MMAP
  -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
  -D APR_USE_POSIXSEM_SERIALIZE
  -D APR_USE_PTHREAD_SERIALIZE
  -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
  -D APR_HAS_OTHER_CHILD
  -D AP_HAVE_RELIABLE_PIPED_LOGS
  -D HTTPD_ROOT="/Users/jpw/web2/httpd"
  -D SUEXEC_BIN="/Users/jpw/web2/httpd/bin/suexec"
  -D DEFAULT_PIDLOG="logs/httpd.pid"
  -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
  -D DEFAULT_LOCKFILE="logs/accept.lock"
  -D DEFAULT_ERRORLOG="logs/error_log"
  -D AP_TYPES_CONFIG_FILE="conf/mime.types"
  -D SERVER_CONFIG_FILE="conf/httpd.conf"


*** /Users/jpw/web2/perl/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration:
   Platform:
 osname=darwin, osvers=7.3.0, archname=darwin-2level
 uname='darwin gabriel.office.aol.com 7.3.0 darwin kernel version 
7.3.0: fri mar 5 14:22:55 pst 2004; 
root:xnuxnu-517.3.15.obj~4release_ppc power macintosh powerpc '
 config_args='-Dprefix=/Users/jpw/web2/perl -de'
 hint=recommended, useposix=true, d_sigaction=define
 usethreads=undef use5005threads=undef useithreads=undef 
usemultiplicity=undef
 useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
 use64bitint=undef use64bitall=undef uselongdouble=undef
 usemymalloc=n, bincompat5005=undef
   Compiler:
 cc='cc', ccflags ='-pipe -fno-common -DPERL_DARWIN -no-cpp-precomp 
-fno-strict-aliasing -I/usr/local/include',
 optimize='-Os',
 cppflags='-no-cpp-precomp -pipe -fno-common -DPERL_DARWIN 
-no-cpp-precomp -fno-strict-aliasing -I/usr/local/include'
 ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build 
1495)', gccosandvers=''
 intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
 alignbytes=8, prototype=define
   Linker and Libraries:
 ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -L/usr/local/lib'
 libpth=/usr/local/lib /usr/lib
 libs=-ldbm -ldl -lm -lc
 perllibs=-ldl -lm -lc
 libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a
 gnulibc_version=''
   Dynamic Linking:
 dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
 cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup 
-L/usr/local/lib'


Characteristics of this binary (from libperl):
   Compile-time options: USE_LARGE_FILES
   Built under darwin
   Compiled at Apr 21 2004 18:36:56
   %ENV:
 PERL_LWP_USE_HTTP_10="1"
   @INC:
 /Users/jpw/web2/perl/lib/5.8.3/darwin-2level
 /Users/jpw/web2/perl/lib/5.8.3
 /Users/jpw/web2/perl/lib/site_perl/5.8.3/darwin-2level
 /Users/jpw/web2/perl/lib/site_perl/5.8.3
 /Users/jpw/web2/perl/lib/site_perl
 .

*** Packages of interest status:

Apache::Request: -
CGI: 3.05
LWP: 5.79
mod_perl   : 1.9913


3. This is the core dump trace: (if you get a core dump):

No core trace

This report was generated by t/REPORT on Tue Apr 27 15:28:57 2004 GMT.

-8<-- End Bug Report --8<--





-- 
Report problem

Re: [MP2] apachectl doesn't run PerlModule code?

[Geoffrey Young]

> For example, if I put the following at the end of an almost generic 
> httpd.conf (only host and port changed from the default install):
> 
> LoadModule perl_module modules/mod_perl.so
> PerlModule Not::Here
> 
> Running 'apachectl start' fails as expected because Not::Here doesn't exist.
> 
> Running 'apachectl configtest' reports 'Syntax OK'.

I think you're running into the "perl module loading is deferred" thingy
that is the default behavior in mp2. if you stuck a valid  section
above it you would probably see configtest fail, since an interpreter would
be loaded.

basically, PerlModule no longer runs module code at the time that the
PerlModule directive is parsed unless an interpreter is already resident in
the configuration process.  I'm not entirely certain as to the rationale for
this, but I think it has something to do with startup times, overhead,
interpreter pools, etc.

now, I have problems with this sometimes - there are quite a few places
where I want PerlModule to run code, and _not_ doing so presents a vary
large problem.  in fact, people who depend on the mp1 behavior currently
have no recourse except to force in an interpreter via .  well, in mp2
we also have PerlLoadModule, which always runs module code on loading,
except that it is exclusively for the use of directive handlers (another
mistake I think, but not a battle I was able to win).

HTH

--Geoff

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [MP2] apachectl doesn't run PerlModule code?

[John Wittkoski]

Geoffrey Young wrote on 4/27/04, 12:22 PM:


 > I think you're running into the "perl module loading is deferred" thingy
 > that is the default behavior in mp2. if you stuck a valid  section
 > above it you would probably see configtest fail, since an interpreter
 > would
 > be loaded.
 >
 > basically, PerlModule no longer runs module code at the time that the
 > PerlModule directive is parsed unless an interpreter is already
 > resident in
 > the configuration process.  I'm not entirely certain as to the
 > rationale for
 > this, but I think it has something to do with startup times, overhead,
 > interpreter pools, etc.
 >
 > now, I have problems with this sometimes - there are quite a few places
 > where I want PerlModule to run code, and _not_ doing so presents a vary
 > large problem.  in fact, people who depend on the mp1 behavior currently
 > have no recourse except to force in an interpreter via .  well,
 > in mp2
 > we also have PerlLoadModule, which always runs module code on loading,
 > except that it is exclusively for the use of directive handlers (another
 > mistake I think, but not a battle I was able to win).
 >
 > HTH
 >
 > --Geoff


Geoff,
Thanks for the hint, that fixed things. If I put ANY   
section in the config - even if there is nothing in that block - it 
triggers the interpreter to start, and the rest of the PerlModule and 
PerlRequire statements in the config are executed.

I guess the docs I was looking at that mentioned PerlModule/PerlRequire 
get executed with 'configtest' were for 1.x, although this is behavior 
that I would expect to be similar between both versions. I don't know 
how often people run into this - perhaps a note could be added to the 
"Migrating to 2.0" pages on perl.apache.org about the difference in 
bahavior.

In my case, I am not concerned about startup time or overhead, but being 
able to use 'apachectl configtest' to let the module validate it's own 
config file (which is separate from httpd.conf) before restarting apache 
to make sure the whole thing can survive a restart.

Thanks,

--John




-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: new version Re: GTop-0.12 compile and installation problems

[Stas Bekman]

Pete Geenhuizen wrote:
Well a little headway, the Server compiles but not GTop.  In case it
matters, Solaris 9 doesn't have pkgconfig, it does have pkg-config.
Yes, it was a typo in the email, it uses pkg-config everywhere. The 
configuration works fine for you.

Here's the output from the build and make.
[...]
/usr/local/bin/perl /usr/local/lib/perl5/5.8.2/ExtUtils/xsubpp  -typemap 
/usr/local/lib/perl5/5.8.2/ExtUtils/typemap -typemap typemap.gtop -typemap typemap -typemap 
typemap  GTop.xs > GTop.xsc && mv GTop.xsc GTop.c
cc -c  -I/usr/local/include/libgtop-2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include   
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O   
-DVERSION=\"0.13\" -DXS_VERSION=\"0.13\" -fPIC 
"-I/usr/local/lib/perl5/5.8.2/sun4-solaris/CORE"  -DGTOP_2_5_PLUS GTop.c
GTop.xs: In function `XS_GTop_field_u_int64_t':
GTop.xs:120: error: `u_int64_t' undeclared (first use in this function)
Well, nothing has changed in GTop itself. Were you able to build GTop before 
on Solaris? On linux u_int64_t is defined in:

/usr/include/sys/types.h:__extension__ typedef unsigned long long int u_int64_t;

Can you figure out where yours is defined and include that header in GTop.xs? 
To find that header I did:

grep -Ir u_int64_t /usr/include/ | grep typedef

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [MP2] apachectl doesn't run PerlModule code?

[Stas Bekman]

Geoffrey Young wrote:
For example, if I put the following at the end of an almost generic 
httpd.conf (only host and port changed from the default install):

   LoadModule perl_module modules/mod_perl.so
   PerlModule Not::Here
Running 'apachectl start' fails as expected because Not::Here doesn't exist.

Running 'apachectl configtest' reports 'Syntax OK'.


I think you're running into the "perl module loading is deferred" thingy
that is the default behavior in mp2. if you stuck a valid  section
above it you would probably see configtest fail, since an interpreter would
be loaded.
basically, PerlModule no longer runs module code at the time that the
PerlModule directive is parsed unless an interpreter is already resident in
the configuration process.  I'm not entirely certain as to the rationale for
this, but I think it has something to do with startup times, overhead,
interpreter pools, etc.
The main rationale I think is because of the restart, loading is twice as 
slow. So the more things you can postpone until after restart the faster your 
server will start.

It should be very easy to match the mp1 behavior. You already suggested that 
an empty \n section will trigger an early startup. And we could 
introduce a special directive for that, to make it less hackish. I'm not sure 
what's the best default behavior. This is something that we can always fix 
later. So let's see whether it is good or not when more people move in.

But yes, I'll document that in the porting/compat doc now. Thanks for 
suggestion, John.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [MP2] apachectl doesn't run PerlModule code?

[Geoffrey Young]

> The main rationale I think is because of the restart, loading is twice
> as slow. So the more things you can postpone until after restart the
> faster your server will start.

I suppose that's a consideration.  but I hate to not have functionality just
because it takes the server a while to start.  for most production
environments, which are behind some kind of load-balancer, a slow start or
restart really doesn't matter.  large, complex applications already can take
minutes to start.

> 
> It should be very easy to match the mp1 behavior. You already suggested
> that an empty \n section will trigger an early startup. 

that's really not an option.  if I create a module that relies on code
running during startup I don't want to say in the docs 'oh, and you have to
fake a  section to get the module working properly.'

> And
> we could introduce a special directive for that, to make it less
> hackish.

we've discussed this at length before:

  http://marc.theaimsgroup.com/?t=10534376728&r=1&w=2

after re-reading the entire thread, I'm pretty sure we are each on the same
side of the argument as we were then.  I know I am :)

--Geoff

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [MP2] apachectl doesn't run PerlModule code?

[Stas Bekman]

Geoffrey Young wrote:
The main rationale I think is because of the restart, loading is twice
as slow. So the more things you can postpone until after restart the
faster your server will start.


I suppose that's a consideration.  but I hate to not have functionality just
because it takes the server a while to start.  for most production
environments, which are behind some kind of load-balancer, a slow start or
restart really doesn't matter.  large, complex applications already can take
minutes to start.

It should be very easy to match the mp1 behavior. You already suggested
that an empty \n section will trigger an early startup. 


that's really not an option.  if I create a module that relies on code
running during startup I don't want to say in the docs 'oh, and you have to
fake a  section to get the module working properly.'

And
we could introduce a special directive for that, to make it less
hackish.


we've discussed this at length before:

  http://marc.theaimsgroup.com/?t=10534376728&r=1&w=2

after re-reading the entire thread, I'm pretty sure we are each on the same
side of the argument as we were then.  I know I am :)
Let's not mix things, Geoff. In this thread you were trying to make 
PerlLoadModule do what it wasn't designed for. This current thread is talking 
about an early startup in general. While related, they aren't the same things. 
If we have turned PerlLoadModule into what you were trying to make it, it 
still doesn't solve John's problem.

And since you've mention this thread, it goes:

"BTW, one other reason for postponing startup is to be able to specify
PerlSwitches anywhere in the config file and PerlInterp* directives as well
(as Doug has reminded me). Something that won't work after perl was started."
So if you force an early startup, you can not use PerlSwitches and you better 
remove the whole feature, since it becomes useless.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [MP2] apachectl doesn't run PerlModule code?

[Geoffrey Young]

> Let's not mix things, Geoff.

fine.  I've moved to [EMAIL PROTECTED]

--Geoff

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [MP2] apachectl doesn't run PerlModule code?

[John Wittkoski]

Geoffrey Young wrote on 4/27/04, 1:56 PM:
 >
 > > The main rationale I think is because of the restart, loading is twice
 > > as slow. So the more things you can postpone until after restart the
 > > faster your server will start.
 >
 > I suppose that's a consideration.  but I hate to not have
 > functionality just
 > because it takes the server a while to start.  for most production
 > environments, which are behind some kind of load-balancer, a slow
 > start or
 > restart really doesn't matter.  large, complex applications already
 > can take
 > minutes to start.


I can see how startup time (or restart time) could be important in many 
situations. However, when running "apachectl configtest", aren't you 
running a new httpd process, separate from the real server? In that case 
startup time should not be critical - why not load the interpreter? When 
doing a real server start (or restart), the code gets executed as 
expected (without using the  force trigger), so when the 
interpreter is loaded isn't an issue (as far as my original problem is 
concerned). It is only with "configtest" do I see this behavior. Is it 
that mod_perl cannot easily distinguish between a "normal" start and a 
"test" start?


Thanks,

--John





-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [MP2] apachectl doesn't run PerlModule code?

[John Wittkoski]

Another note, just FYI:

To trigger the interpreter to load, putting this in httpd.conf (or in an 
included file) doesn't work:




But this does:


# foo


Obviously something wants a non-null data in the Perl section before 
firing off the interpreter.


--John





-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: new version Re: GTop-0.12 compile and installation problems

[Stas Bekman]

Pete Geenhuizen wrote:
This is my first attempt at GTop.

Unfortunately Solaris doesn't support a recursive grep, and equally 
unfortunately I wan't able to find u_init64_t anywhere.

With some Googleing around I came across this fix to compiling libgtop on 
Solaris 8 and 9

" For the meantime, I patched glibtop.h to have

#ifndef u_int64_t
#define u_int64_t unsigned long long int
#endif "
I applied the above to glibtop.h and that allowed GTop to finally compile.
It should have been applied to GTop.xs, as it has nothing to do with glibtop 
itself I believe. I'll apply it.

With that done, back to what started this whole thing, Apache::VMonitor.  Using 
cpan the compile works, but the tests fail with this error which causes the 
install to fail.

waiting 60 seconds for server to start: ...glibtop: kvm_open(): Error 0
(126)Cannot assign requested address: make_sock: could not bind to address 
[::1]:8531
no listening sockets available, shutting down
Unable to open logs
Hmm, please upgrade your Apache-Test to the latest version and try again. It's 
a known IPv6 issue with Apache-Test, fixed in the latest release.

So I installed VMonitor without the test and was able to point my browser at it 
and got a nice display.

Unfortunately the system function doesn't appear to be working, I don't know if 
that is related to the u_int64_t cludge, but here's what it shows.

CPU:   0.0% user, 0.0% nice, 0.0% sys, 0.0% idle
Mem:   768M av,  455M used,  313M free,0K shared,0K buff
Swap:  325K av,   30K used,  295K free, 0 pagein, 0 pageout
Not sure if any of this helps, but this what I have now.
I guess libgtop is just not fully functioning under Solaris. That's not GTop's 
problem, but the underlying C libgtop library. You may need to ask whoever 
supports it (which I could never find).

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: new version Re: GTop-0.12 compile and installation problems

[Stas Bekman]

Stas Bekman wrote:
Pete Geenhuizen wrote:

This is my first attempt at GTop.

Unfortunately Solaris doesn't support a recursive grep, and equally 
unfortunately I wan't able to find u_init64_t anywhere.

With some Googleing around I came across this fix to compiling libgtop 
on Solaris 8 and 9

" For the meantime, I patched glibtop.h to have

#ifndef u_int64_t
#define u_int64_t unsigned long long int
#endif "
I applied the above to glibtop.h and that allowed GTop to finally 
compile.


It should have been applied to GTop.xs, as it has nothing to do with 
glibtop itself I believe. I'll apply it.
Actually i'm not sure how safe it is.
http://www.opensource.apple.com/darwinsource/10.3/OpenSSH-39/openssh/defines.h
does:
#ifndef HAVE_U_INT64_T
# if (SIZEOF_LONG_INT == 8)
typedef unsigned long int u_int64_t;
#   define HAVE_U_INT64_T 1
# else
#  if (SIZEOF_LONG_LONG_INT == 8)
typedef unsigned long long int u_int64_t;
#  endif
# endif
#endif
Though this is from darwin, so Solaris may have a different flag. Googling for 
"Solaris u_int64_t typedef" gives quite a lot of hits, one using HAVE_INT64_T. 
So try to google with these words and I hope you will find the most correct 
ifdef setting. Thanks.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [MP2] apachectl doesn't run PerlModule code?

[Stas Bekman]

John Wittkoski wrote:
Another note, just FYI:

To trigger the interpreter to load, putting this in httpd.conf (or in an 
included file) doesn't work:



But this does:


# foo

Obviously something wants a non-null data in the Perl section before 
firing off the interpreter.
Yup thanks, that has been documented already:

http://perl.apache.org/docs/2.0/user/porting/compat.html#Server_Startup

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [MP2] apachectl doesn't run PerlModule code?

[Stas Bekman]

John Wittkoski wrote:
Geoffrey Young wrote on 4/27/04, 1:56 PM:
 >
 > > The main rationale I think is because of the restart, loading is twice
 > > as slow. So the more things you can postpone until after restart the
 > > faster your server will start.
 >
 > I suppose that's a consideration.  but I hate to not have
 > functionality just
 > because it takes the server a while to start.  for most production
 > environments, which are behind some kind of load-balancer, a slow
 > start or
 > restart really doesn't matter.  large, complex applications already
 > can take
 > minutes to start.
I can see how startup time (or restart time) could be important in many 
situations. However, when running "apachectl configtest", aren't you 
running a new httpd process, separate from the real server? In that case 
startup time should not be critical - why not load the interpreter? When 
doing a real server start (or restart), the code gets executed as 
expected (without using the  force trigger), so when the 
interpreter is loaded isn't an issue (as far as my original problem is 
concerned). It is only with "configtest" do I see this behavior. Is it 
that mod_perl cannot easily distinguish between a "normal" start and a 
"test" start?
Please take a look at my reply to Geoff, the startup time is not the only 
reason. A more significant reason is that PerlSwitches must be set before perl 
starts. If you want to set PerlSwitches inside vhosts, and perl has already 
been started, you are out of luck. Here is why you want this feature:

http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlSwitches_
http://perl.apache.org/docs/2.0/user/config/config.html#C_Clone_
http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_
With a  hack section, or a new directive to do just that - force the 
startup of the interpreter, you have a complete control over things. If we 
start early by default, then you're out of control.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html