Re: Solaris getopt_long and PostgreSQL - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: Solaris getopt_long and PostgreSQL
Date
Msg-id 49BFD4BD.7030008@sun.com
Whole thread Raw
In response to Re: Solaris getopt_long and PostgreSQL  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: Solaris getopt_long and PostgreSQL
List pgsql-hackers
Dne 17.03.09 17:24, Zdenek Kotala napsal(a):
> Dne 17.03.09 17:13, Zdenek Kotala napsal(a):
>
>>> I don’t know if I should revert that change, or port netBSD
>>> getopt_long and replace the PostgreSQL one with that.
>>
>> getopt_long is OK. Problem is getopt. getopt in core is currently
>> taken from *BSD but it could be updated.
>>
>> One possible solution should be to use internal getopt only for
>> postgres binary and for other to use solaris libc version.
>
> I'm now looking into the code and most binaries uses getopt_long which
> works fine. I think getopt_long can be used from Solaris libc. Only
> postgres and pg_resetxlog uses getopt. I think nobody has problem with
> postgres, because it is called from pg_ctl or other start/stop script
> and pg_resetxlog should be modified to use getopt_long.
>

There is a patch, please test it if it satisfy your expectation. Do not
forget run autoconf.

    Zdenek
*** pgsql.ed0f426df3ee/configure.in    2009-03-17 17:42:16.131828743 +0100
--- pgsql/configure.in    2009-03-17 17:38:58.639284000 +0100
***************
*** 1274,1280 ****
  # our versions on that platform.
  if test "$PORTNAME" = "solaris"; then
    AC_LIBOBJ(getopt)
-   AC_LIBOBJ(getopt_long)
  elif test x"$ac_cv_type_struct_option" = xyes ; then
    AC_REPLACE_FUNCS([getopt_long])
  else
--- 1274,1279 ----

pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Ignore -- testing message-id on footer
Next
From: Tom Lane
Date:
Subject: Re: Problem with zero year