This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] Environment variables passed to inferior for Cygwin build ( follow up on mingw fix for PR 10989)
- From: Eli Zaretskii <eliz at gnu dot org>
- To: "Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 04 Oct 2011 06:40:35 -0400
- Subject: Re: [RFC] Environment variables passed to inferior for Cygwin build ( follow up on mingw fix for PR 10989)
- References: <E1R2jDx-00035B-Fq@fencepost.gnu.org> <E1R5YPa-0007H0-0B@fencepost.gnu.org> <E1R7mEx-0003rs-PZ@fencepost.gnu.org> <4E7FBF9E.firstname.lastname@example.org> <20110926171511.GJ17681@adacore.com> <20111004075325.GB13895@calimero.vinschen.de> <004801cc827b$e752bfd0$b5f83f70$@email@example.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> From: "Pierre Muller" <firstname.lastname@example.org>
> Date: Tue, 4 Oct 2011 11:56:35 +0200
> But, after looking into it, I suspect that your proposal
> was about setting only environment variables that have
> been explicitly modified within GDB... but the environment list is a
> simple array of 'char *'.
> Furthermore, there is no recording inside GDB code of
> environment variables that were explicitly modified.
> in_env contains all environment variables coming from GDB startup.
> Thus, if I use your suggestion,
> call cygwin_internal (CW_SYNC_WINENV); first
> and set environment variables after,
> PATH variable stays in cygwin form, which leads to a failure within
> CreateProcess call because some DLLs are not found.
> Using cygwin_internal (CW_SYNC_WINENV);
> after settings individual environment variables
> using SetEnvironmentVariable call
> work, but I am not sure this is what you wanted.
> I am still sending here the patch, so you can test it, if you want.
> In fact, I suppose that the out_env part is not really needed:
> if no environment pointer is given, CreateProcess takes the environment of
> the parent process (which is GDB!), but we just modified it
> so that probably, leaving that part out would give the same result.
I'm confused: what problem(s) are you trying to fix in your patch?
Can you please enumerate the problems, and why do you think they
exist? I think there's a misunderstanding here (I thought that about
the previous discussion in April, and I fear we will just repeat the
same misunderstanding now).
To comment on the part of what you say that I do understand: using
SetEnvironmentVariable in this case is not TRT, because that changes
the environment of GDB itself. By contrast, "set environment" and
"unset environment" commands are supposed to affect only the
environment of the inferior, without any effect on GDB itself. That
is why I didn't use SetEnvironmentVariable in my patch.