Re: Error in libfetish.a

[Bob Proulx]

John D. Ballentine III wrote:
> OK, I tried again from a fresh unpack of the tar file.

Good.  It would otherwise have been a nagging concern that something
was wrong there.

> And, as suggested before, the HP make failed with yet another interesting
> series of messages:
> 
>   -g -O2 -c `test -f 'human.c' || echo './'`human.c
> human.c: In function `adjust_value':
> human.c:111: parse error before `l'
> human.c:114: `u' undeclared (first use this function)
> human.c:114: (Each undeclared identifier is reported only once
> human.c:114: for each function it appears in.)
> human.c: At top level:
> human.c:117: parse error before `return'
> *** Error exit code 1

Actually that is a compilation error and not a make error.  This one
has nothing to do with make.  Can't blame this one there.

> So, I am trying to get the GNU make and use that...  This is an interesting
> experience, but starting to get a little annoying.  I appreciate the offer
> of a pre-compiled binary, but now I am getting stubborn enough to want to do
> this myself... :)

Grandfather says, "It builds character."  :-)

> package) and got the following error:
> 
> gcc -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.    -g
> -O2
> -c `test -f 'human.c' || echo './'`human.c
> human.c: In function `adjust_value':
> human.c:111: parse error before `l'
> human.c:114: `u' undeclared (first use this function)
> human.c:114: (Each undeclared identifier is reported only once
> human.c:114: for each function it appears in.)
> human.c: At top level:
> human.c:117: parse error before `return'
> make[3]: *** [human.o] Error 1

Here is the code for this error.

104 static long double
105 adjust_value (int inexact_style, long double value)
106 {
107   /* Do not use the floorl or ceill functions, as that would mean
108      checking for their presence and possibly linking with the
109      standard math library, which is a porting pain.  So leave the
110      value alone if it is too large to easily round.  */
111   if (inexact_style != human_round_to_nearest && value < UINTMAX_MAX)
112     {
113       uintmax_t u = value;
114       value = u + (inexact_style == human_ceiling && u != value);
115     }
116 
117   return value;
118 }

Parse error before 'l' on 111 looks like UINTMAX_MAX is not being
understood properly.  But the 'u' undeclared could mean that uintmax_t
is not known.  Either way something is not happy there.

On my HP-UX 10.20 system this has a complex set of macros which I
won't reproduce here.  But you can use -E to process the file with gcc
and have it show you the result.

  gcc -E -DHAVE_CONFIG_H -I. -I.. human.c | less +/^adjust_value

What does that show on the screen for you?  For me I see the
following, and a lot more blank lines where the comments were which I
squeezed out.

  static long double
  adjust_value (int inexact_style, long double value)
  {
    if (inexact_style != human_round_to_nearest && value < 
18446744073709551615ull )
      {
        uintmax_t u = value;
        value = u + (inexact_style == human_ceiling && u != value);
      }

    return value;
  }

What does that show for you in the UINTMAX_MAX position, that
18446744073709551615ull in my output above?  It would seem that your
installation of gcc does not understand 'ull'.  Have you used gcc on
your system for many programs?  At this point I am thinking that is
your problem.  I don't think gcc is all there.  I mostly use the HP
ANSI C compiler.  But I also have gcc-2.95.2 and it compiles
coreutils-5.0 on HP-UX 10.20 fine.

Do you have the native HP ANSI C compiler?  (This is not the same as
the bundled "crippled" compiler.  The ANSI compiler is extra.)  If so
then it would compile this fine.  Just not wanting to overlook this
possibility.

On to the 'make' part of the discussion.

I shuffled the 'make' discussion to the bottom since it is only
peripheral to the coreutils part of the discussion.  In particular for
those just tuning in this is about installing GNU software on non-GNU
systems such as the HP-UX 10.20 machine under discussion.

> OK, got "make", made it without any hassle.  Question:  Where should it
> live?

My personal choice for a single machine is in /usr/local/bin/make.
This is probably simplest for you as well.  I have /usr/local/bin in
my path ahead of /usr/bin:/bin.  I always configure /etc/PATH and
/etc/MANPATH this way so that it is a system configured value for all
users on the machine.  This is typical with other systems too.

But other people feel differently.  They rename 'make' and call it
either 'gmake' or 'gnumake' or 'make.gnu' some other naming so that
they can say gmake and when 'not found' is the error they know they
have no possibility of getting a non-gnu version of make.

Since I am distributing GNU make to a large number of machines, such
as my compute cluster and desktops at work.  In that case I can't
install it in /usr/local/bin.  That would prevent users from
installing their own, possibly newer or custom version, there.  And
because I don't want to munge the system's own /usr/bin/make and I
don't want to take over /usr/local/bin/make for a large group I call
it /opt/local/bin/make there.  I put that path in /etc/PATH and
/etc/MANPATH.  That works well.  But probably more than you need.

If you are just installing on a machine or two the /usr/local/bin
default works well.

> I have just tried running it from my home directory (on the coreutils

Your home directory will work fine as well.  GNU make is a single
binary and can run from anywhere.  $HOME/bin/make is a fine place for
it.

Bob