[gccsdk] Environment handling bugs

John Tytgat John.Tytgat at aaug.net
Sun Feb 10 04:57:10 PST 2008

In message <7f81a56e4f.peter at chocky.org>
          Peter Naulls <peter at chocky.org> wrote:

> I found a couple of inconsistencies in the UnixLib variable/environment
> handling.  The first is that putenv didn't behave the same as setenv
> when it came to the behaviour we describe in the README regarding
> variables with a '$' in them.  That is an easy fix, which I will check
> in soon.


> The second, and incidentally, this is precisely the reason that Firefox
> doesn't start on some machines (it relies on the state of environment
> variables it sets when launching a child process to handle creating an
> initial profile), is that sometimes/often there's no environment (i.e.,
> sulproc->environ is NULL) passed to an 'exec'ed process.  Why this is, I
> don't know - I didn't look at the module source, but this seems to be
> where the problem lies (the environment is setup correctly in the
> parent).   In the meantime, there are a couple of ways I can work around
> this.

This sounds remarkably like the problem I had with getting gcc4 to work
on RISC OS, i.e. the cc1 compiler needed to inherit a couple of crutial
environment variables set by the gcc frontend and it was only after fixing
SUL module that this worked.  A change BTW which resulted in a couple of
regression reports and which I still have to look at in detail how we can
address this.

You probably find more detail in ChangeLog entries I made and by svn log/diff
digging but the problem was that the program name given to exec() wasn't
matching the one in SUL initialise call so that meant that the new process
didn't inherit the environment.  I solved this by canonicalising the exec
filename using Run$Path + check if this is a real file.  But again, this
seems to result in some unwanted behaviour still.

BTW, good news you found the cause of this problem.

> Here is my test program:
> [...]

If you think it is worthwhile, please check in your test file in a (possible
new) subdirectory of recipe/files/libunixlib/test so that it can be used
later to verify if we don't have broken something.  Something we didn't do
enough during UnixLib development IMHO.

FYI, the Perl script in recipe/files/libunixlib/gen-auto.pl will be called
from recipe/scripts/reconf-libunixlib and automatically add all test programs
found there so you don't need to update Makefile.am files.

John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven

More information about the gcc mailing list