Re: SunOS4

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: peter_e(at)gmx(dot)net
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SunOS4
Date: 2001-02-22 01:08:34
Message-ID: 20010222100834A.t-ishii@sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > o no RAND_MAX or EXIT_FAILURE found. I simply added them to c.h.
>
> EXIT_FAILURE is defined in src/bin/psql/settings.h; I can't find it used
> outside psql.

So SunOS should be ok with this in current.

> RAND_MAX should be inside an #ifndef RAND_MAX, not in a
> SunOS specific section.

Ok.

> > o regex/utils.h included twice somewhere. I added #ifndef
> > UTILS_H... to utils.h
>
> Okay.

I will add REGEX_UTILS_H per Tom's suggestion.

> > o SunOS4 does not have strdup, strtoul. --> use backend/port/strtoul.c
> > etc.
>
> Okay. Instead of ../../etc. in makefiles you should use $(top_srcdir) or
> $(top_builddir).

I see.

> > o SunOS4 does not have atexit (used in psql). --> igore it
>
> Maybe on_exit() is available, or even more portable?

Let me check it.

> > o SunOS4 does not have getopt. --> use utils/getopt.c. also getopt.h
> > need to be created, and checking for getopt is needed to configure.in.
>
> Ugh.
>
> #include "../../utils/getopt.h" is definitely not good.
>
> + #ifndef HAVE_GETOPT_H
> + char *__progname = "pg_id";
> + #endif
>
> seems to be misguided.

But our getopt implementaion requires

char *__progname = "pg_id";

no?

> The getopt.h file doesn't seem necessary. The external variables should
> be defined in every program that needs them. The getopt() function
> doesn't need to be declared.

I agree with we don't need getopt.h.

> > o to make shared library I have added an entry for SunOS4 in
> > Makefile.shlib.
>
> I'm not sure that entry is right. Libtool wants it to look like
>
> $(LD) -assert pure-text -Bshareable
>
> you have
>
> $(LD) -dc -dp -Bdynamic

It comes from our makefiles/Makefile.sunos4. Let me check if what
Libtool suggests works.

> > o to make shared libraries (such as libpgeasy.so) relying on libpq,
> > "ld foo.o bar.o ... -L ../libpq -lpq" is executed but fails. I
> > changed it to:
> > ld foo.o bar.o ... ../libpq.a
> > instead.
>
> Can you elaborate on why that's necessary? Perhaps a problem with the
> command line (see above)? Why only ecpg?

Not only ecpg. libpgeasy, libpq++ also.

> > o pg_id needs Makefile.in.
>
> Nothing needs a Makefile.in. Substitution symbols go in Makefile.global.

Oh, things have been changed dramatically since 7.0. I see now.

> > included are patched for *7.0.x*. Sould I make same changes to 7.1?
> > Comments anyone?
>
> 7.0 build patches are pretty much useless for 7.1, I'm afraid. You should
> work with 7.1 before proceeding.

Of course.

BTW, I observe some regression failures under SunOS4 due to the
difference of strtol. It does not detect overflow. So, following
INSERT in regress/sql/int4.sql does not throw an error, but inserts
a random value.

-- bad input values -- should give warnings
INSERT INTO INT4_TBL(f1) VALUES ('1000000000000');

What should we do?
--
Tatsuo Ishii

In response to

  • Re: SunOS4 at 2001-02-21 16:34:32 from Peter Eisentraut

Responses

  • Re: SunOS4 at 2001-02-22 01:47:07 from Tatsuo Ishii

Browse pgsql-hackers by date

  From Date Subject
Next Message Vince Vielhaber 2001-02-22 01:21:24 Re: beta5 ...
Previous Message Tom Lane 2001-02-21 23:34:24 Re: Bug: COUNT() and ExecEvalAggref error