Re: 'char **environ' woes with cygwin

[Chris Faylor <cgf at cygnus dot com>]

On Fri, Aug 25, 2000 at 04:17:21AM -0400, Eli Zaretskii wrote:
>> From: Chris Faylor <cgf@cygnus.com>
>> Date: Thu, 24 Aug 2000 16:33:39 -0400
>> 
>> I've recently painfully learned that gdb explicitly declares 'char **environ'
>> all over the place.
>
>I see "extern char **environ", not "char **environ", the only
>exception being kdb-start.c.

Um.  Right.  The point is that these are being explicitly declared.

>> This presents a problem for cygwin since environ is now being imported from
>> the cygwin DLL.
>
>Could you please explain more why is this a problem.  I'm afraid I
>don't know enough about the Cygwin DLL to get the idea.

Variables and functions imported from a DLL need to include:

__declspec(dllimport)

So, for Windows, environ needs to be:

extern char __declspec(dllimport) **environ;

>> I've modified configure.in to egrep unistd.h for an environ declaration and
>> define HAVE_ENVIRON if unistd.h contains a declaration.
>
>What about systems where environ is declared in some other header?

Then, I presume that they will continue to work as they always have.  The
'extern char **environ' seems to have been in gdb for some time.

>> The question is, where do I put a:
>> 
>> #ifndef HAVE_ENVIRON
>> char **environ;
>> #endif
>
>This would probably break some ports, at least the DJGPP one (unless
>I'm missing something): the DJGPP startup code includes this
>definition, but no DJGPP header declares environ.  So we will wind up
>having multiple definitions at link time.

Sorry.  I should have added an extern.

>I think HAVE_ENVIRON cannot be based on examining the headers alone;
>you must link a test program which says "extern char **environ" and
>tries to access environ: if linking succeeds, you can define
>HAVE_ENVIRON.  The program needs to include unistd.h and any other
>header which might declare environ.

I don't see why.  Are you asserting that a unistd.h file will declare
'environ' but will not actually define it in the C library?  If that is
the case, then how did gdb ever work?  AFAICT, gdb relies on the existence
of environ.

If 'environ' is defined in unistd.h (as it is in cygwin and most of the
UNIX systems I surveyed) then the 'extern char **environ;' won't be
activated.  Otherwise, if there is no declaration in unistd.h then there
will be an 'extern char **environ;'.  The only thing 

I can't make determinations of what header files to search on systems
for which I don't have access, and it apparently doesn't matter anyway.
If this is a problem for some future port, then configure.in will have
to be changed.  Otherwise, this change should only affect targets which
define environ in unistd.h.

I was trying to avoid adding an "#ifdef __CYGWIN__" because I hate using
system-specific solutions for what is actually a generic (if minor)
problem.

cgf