Fw: Squid 3.0 Compilation issues on IA64

From: GV <gv@dont-contact.us>
Date: Mon, 26 May 2003 00:39:58 -0700

For archiving....

----- Original Message -----
From: "GV" <gv@visolve.net>
To: "Henrik Nordstrom" <hno@marasystems.com>
Cc: <squid-dev@squid-cache.org>
Sent: Monday, May 26, 2003 12:37 AM
Subject: Re: Squid 3.0 Compilation issues on IA64

>
> Hello Henrik,
>
> Bug IDs are 658 and 659 respectively. Please let me know, if you need more
> information on this issue.
>
> Regards,
> GV
>
> > Please open two bug reports.
> >
> > 1. A bug report with the assertion error, and a backtrace of where it
> > happens.
> >
> > 2. A bug report with the warnings.
> >
> > Regards
> > Henrik
> >
> > On Sun, 25 May 2003, GV wrote:
> >
> > > Hello Henrik,
> > >
> > > Thanks for your response. Looks like the problem is more than what I
> thought
> > > off. Please see the details below.
> > >
> > > I fixed all the warnings, most of them are from debug statements and
> just
> > > commented them out. Other warnings and fixes are as follows...
> > >
> > > 1. "HttpReply.cc" - typecast to ssize_t solves this warning
> > >
> > > 161 size_t s = XMIN(end + 1, (ssize_t)4096);
> > > ^^^^^^^
> > > HttpReply.cc: In function `int httpReplyParse (HttpReply *, const char
> *,
> > > long int)':
> > > HttpReply.cc:161: no matching function for call to `min (long int,
int)'
> > >
> > > 2. "mem.cc" - %d to %ld
> > >
> > > cc1plus: warnings being treated as errors
> > > mem.cc: In function `void memBufStats (StoreEntry *)':
> > > mem.cc:125: warning: int format, different type arg (arg 3)
> > > mem.cc:125: warning: int format, different type arg (arg 4)
> > > mem.cc: In function `void Mem::PoolReport (const MemPoolStats *, const
> > > MemPoolMeter *, StoreEntry *)':
> > > mem.cc:622: warning: int format, different type arg (arg 4)
> > > mem.cc:622: warning: int format, different type arg (arg 5)
> > > mem.cc:622: warning: int format, different type arg (arg 9)
> > > mem.cc:622: warning: int format, different type arg (arg 10)
> > > mem.cc:622: warning: int format, different type arg (arg 13)
> > > mem.cc:622: warning: int format, different type arg (arg 14)
> > >
> > > storeAppendPrintf(sentry, "Large buffers: %ld (%ld KB)\n",
> > > 124 HugeBufCountMeter.level,
> > > 125 HugeBufVolumeMeter.level / 1024);
> > >
> > > 598 storeAppendPrintf(e,
> > > 599 "%d\t %ld\t %ld\t %.2f\t %.1f\t" /*
alloc
> */
> > > 600 "%d\t %ld\t %ld\t %.1f\t" /* in use */
> > > 601 "%d\t %ld\t %ld\t" /* idle */
> > > 602 "%.0f\t %.1f\t %.1f\t %.1f\n", /*
saved
> */
> > > 603 /* alloc */
> > > 604 mp_st->items_alloc,
> > >
> > > 3. "stat.c" - %6d to %6ld
> > >
> > > cc1plus: warnings being treated as errors
> > > stat.cc: In function `void info_get (StoreEntry *)':
> > > stat.cc:691: warning: int format, different type arg (arg 3)
> > > stat.cc:693: warning: int format, different type arg (arg 3)
> > >
> > > 690 storeAppendPrintf(sentry, "\tmemPool accounted:
%6ld
> KB
> > > %3d%%\n",
> > > 691 mp_stats.TheMeter->alloc.level >>
10,
> > > percent(mp_stats.TheMet er->alloc.level, t));
> > > 692 storeAppendPrintf(sentry, "\tmemPool unaccounted:
%6ld
> KB
> > > %3d%%\n",
> > > 693 (t - mp_stats.TheMeter->alloc.level)
> >>
> > > 10, percent((t - mp_s tats.TheMeter->alloc.level), t));
> > >
> > > > > Finally, I am NOT quite happy about the hack I did, but works
fine.
> > > > > I did some quick testing with my netscape. Looks better except the
> > > > > above log messages. May be I should fix all the warnings, instead
> > > > > of removing "-Werror" flag from the compilation. If I come up with
> > > > > some changes to make the above issue vanished, will the changes be
> > > > > acceptable to go into CVS?
> > > >
> > > > The warnings should be fixed.
> > >
> > > Please see the above details. As I stated already, other warnings are
> from
> > > debug statements. I can send them, if you need.
> > >
> > > But this[Warning fixes] does NOT solve the runtime issue, I have
> reported
> > > earlier. Still, the assertion is getting failed in the same location.
> > >
> > > 2003/05/25 16:44:08| Starting Squid Cache version 3.0.DEVEL-20030524
for
> > > ia64-unknown-linux-gnu...
> > > 2003/05/25 16:44:08| assertion failed: mem.cc:230: "size ==
> > > StrPoolsAttrs[i].obj_size"
> > > Aborted
> > >
> > > Any help will be much appreciated to proceed further.
> > >
> > > > > Another weired thing I have seen is, regardless of the value I
have
> > > > > set for "mem_pools" "on" or "off", I always have seen "mem_pools
> > > > > are off" in the log file as follows. I am NOT quite sure about
> > > > > this, just wanted to know, if there is a known issue...
> > > > > Log info : Memory pools are 'off'; limit: 0.00 MB
> > > >
> > > > And you did not request to have the pools disabled when you built
your
> > > > Squid? (--disable-mempools)
> > >
> > > I have used only default option with my own prefix. By default,
mempools
> > > should be on, I guess.
> > >
> > > Regards
> > > GV
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> www.ViSolve.net - The Open Source Solutions Provider
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
>
Received on Mon May 26 2003 - 01:39:54 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:57 MST