[bug-gs] 8.12: minor issues: non-doc

[der Mouse]

>> I don't understand how t_eps managed to come out negative.
> Interesting.  Have you looked at
> <http://bugs.ghostscript.com/show_bug.cgi?id=687184> ?  Sounds like
> it might be related.

I hadn't before this, but I now have.  It might be, though my guess
would be that it's not.  My symptoms were rather different, for one
thing.  It wasn't a question of time_clear always returning zero - its
return value was increasing nicely; it's just that t_eps was so
insanely large that time_clear wasn't going to return a value greater
than it anytime soon.  (It looked like 0xffffffff in decimal, but I
didn't really look carefully; I just saw the leading 4 and about ten
digits and was sure something very fishy was up.)

> I don't understand what's going on in either case, but it's something
> new.  Was this also on a P4?

No.  I _think_ it was on a SPARCstation 20; there is some slight chance
my memory is confused and it was on the other machine I was
experimenting on, which is an AMD K6-2/500.  But as I say, the detailed
syndrome was different anyway.

The SS20 is

mainbus0 (root): SUNW,SPARCstation-20
cpu0 at mainbus0: TMS390Z50 v0 or TMS390Z55 @ 75 MHz, on-chip FPU
cpu0: physical 20K instruction (64 b/l), 16K data (32 b/l), 1024K external (32 b/l): cache enabled

whereas the K6-2 is

cpu0: family 5 model 8 step c
cpu0: AMD K6-2 (586-class)

(I don't find any indication of the cache size in the latter's boot
messages, and this is not a good time to down it to check the BIOS).
Definitely not a P4, though.

>> [...unix-gcc.mak...unixansi.mak...]
> Note also that both of these makefiles are deprecated in favor of the
> autoconf build (src/Makefile.in and src/configure.ac).

I was afraid of that; I always sigh when I see something that uses
configure, because it usually takes at least a dozen passes before I
manage to find the option set to configure to get it to DTRT - and when
it's a question of the installation directories, that takes a lot of
time, since each pass means a full build.  In some cases I've given up
and just applied my own patches post-configure to fix up the things it
gets wrong; when configure thinks it knows better than I do but is
wrong, it's pulling teeth to fix the damage.  There's even one case
(not directly ghostscript-related) where I completely gave up on
getting "make install" to work right and made by build script install
things by hand.  I was very pleased to see the install doc implying
that the edit-the-makefiles approach was still supported, even though
configure's presence implied it was probably now deprecated.

>> Adding $(PSD)/rasterop.dev to FEATURE_DEVS doesn't seem to work.
> You want $(PSD)rasterop.dev here.

Ah!  I did notice the double slash in the make output, but didn't see
any reason why that would would be wrong - I suppose it means that an
explicit rule in some makefile doesn't match.  I don't know how I
managed to miss that all the existing entries have no slash; my
apologies for unnecessary noise.  I'll have to try it again sometime
spelled right.

>> NetBSD's make(1) has a delightful little bug [...chdir("obj")...]
> Bizarre.

Yes, I think so too.  They find it useful when building the system -
which is fine, except that instead of making it optional, default off,
and turning it on in their build procedure, they made it default on.

> Is there a switch to turn off this behavior?

Not in any version I've found, assuming switch means command-line flag.
If you set MAKEOBJDIR in the environment to a nonexistent path (I like
/NON/EXIST/ENT), that effectively turns it off.  I already have my own
wrapper around make(1) to provide an additional directory to search for
included makefiles in; I just added code to the wrapper so that if
neither MAKEOBJDIRPREFIX nor MAKEOBJDIR is set in the environment, it
provides MAKEOBJDIR=/NON/EXIST/ENT.  It is not enough to set it on the
make command line (make MAKEOBJDIR=/foo/bar); it must be in the
environment.

I've filed a NetBSD bug report against make(1) for this; however -
since I don't expect NetBSD to agree that it's a code bug to have it
default on - I made it a doc-bug for not documenting it rather than a
code-bug for having it happen at all.  I phrased it in a way that made
it clear that was only the reason I classed it that way, though. :-)
(It most certainly violates least surprise; I already knew about it and
it still took dragging out the hammer of ktrace(1) before I twigged to
it, despite seeing obj/ all over the place.  And if it can baffle
someone who already knows about it like that....)

> Thanks for all the reports, we definitly appreciate your input and
> it's nice to have a fresh look at the process we've all grown used
> to.

No problem there.  I know how hard it can be to see such things from a
stranger's point of view....

Oh, one thing I forgot to mention in the non-doc stuff: there were tons
of compiler warnings.

Practically everything (or at least that's how it feels when looking at
the log) warned about src/std.h redefining int{8,16,32}_t, already
defined by /usr/include/machine/types.h.  I'm not at all sure what the
right fix is there.  There are 1368 such warnings altogether in my
build log (ie, 1368 "redefinition of `int(8|16|32)_t'" and 1368
"`int(8|16|32)_t' previously declared here" - presumably 456 sets of
six).

Other warnings, with counts:

307 cast discards `const' from pointer target type
 15 unused variable `...'
 11 `main' is usually a function
  4 no previous prototype for `...'
  2 function declaration isn't a prototype
  2 assignment discards `const' from pointer target type
  1 return-type defaults to `int'
  1 implicit declaration of function `...'
  1 `...' defined but not used

Whether you actually want to do anything about any of these, of course,
is another question entirely.  I'm just reporting 'em.  But at least
some you presumably think are worth fixing, or you wouldn't be using
the warning options you are.  I'm not at all sure what TRT is for the
int*_t warnings; most of the others are easier to see fixes for, at
least in principle....

I can, of course, provide more details, up to and including the full
build log, to anyone who wants.  However, it's pushing half a meg
(460493 bytes), so I'm not about to just dump it on the list cold. :)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B