Re: Detecting glibc getopt?

Is this resolved?

---------------------------------------------------------------------------

> I have traced down the postmaster-option-processing failure that Thomas
> reported this morning.  It appears to be specific to systems running
> glibc: the problem is that resetting optind to 1 is not enough to
> put glibc's getopt() subroutine into a good state to process a fresh
> set of options.  (Internally it has a "nextchar" pointer that is still
> pointing at the old argv list, and only if the pointer points to a null
> character will it wake up enough to reexamine the argv pointer you give
> it.)  The reason we see this now, and didn't see it before, is that
> I rearranged startup to set the ps process title as soon as possible
> after forking a subprocess --- and at least on Linux machines, that
> "nextchar" pointer is pointing into the argv array that's overwritten
> by init_ps_display.
> 
> While I could revert that change, I don't want to.  The idea was to be
> sure that a postmaster child running its authentication cycle could be
> identified, and I still think that's an important feature.  So I want to
> find a way to make it work.
> 
> Looking at the source code of glibc's getopt, it seems there are two
> ways to force a reset:
> 
> * set __getopt_initialized to 0.  I thought this was an ideal solution
> since configure could check for the presence of __getopt_initialized.
> Unfortunately it seems that glibc is built in such a way that that
> symbol isn't exported :-(, even though it looks global in the source.
> 
> * set optind to 0, instead of the more usual 1.  This will work, but
> it requires us to know that we're dealing with glibc getopt and not
> anyone else's getopt.
> 
> I have thought of two ways to detect glibc getopt: one is to assume that
> if getopt_long() is available, we should set optind=0.  The other is to
> try a runtime test in configure and see if it works to set optind=0.
> Runtime configure tests aren't very appealing, but I don't much care
> for equating HAVE_GETOPT_LONG to how we should reset optind, either.
> 
> Opinions anyone?  Better ideas?
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026