[LLVMdev] llvm-gcc4 & mingw32 & bash

[Anton Korobeynikov]

Hello, Greg.

You wrote Sunday, May 14, 2006, 5:21:49 PM:

GP> Do I still need to do the "black magic"?
In fact, yes.

GP> What is this patched version of bash (do you have a patch, where do I get
GP> it?) What does "pwd builtin was just hardly disabled" mean?
There are some set of built-in commands in bash (they are called
"builtins"). For example "echo", "pwd", etc. Some other commands are
just binaries in /usr/bin directory. Our goal it to get paths like
"drive:/path" from pwd, not "/drive/path". We can tunnel output of
/usr/bin/pwd thru cygpath to get correct path. But this won't work,
since /usr/bin/pwd is not actually called, because of presence of
builtin.

We should disable that builtin to get everything work. Well, we can
done it executing "enable -n pwd" in .bashrc script. But this won't
work, since configure scripts are executing in non-interactive mode.
We can set up BASH_ENV environmental variable to point to some script,
which will be called during initialize.

But this again won't work. Configure's are executing in "bash-as-sh"
mode. It ignores BASH_ENV variable and even more - it ignores ENV
variable, which should work as BASH_ENV in this case. That's why all
that magic exists.

Another way - patch bash and disable pwd builtin by default. This is
not good at all. But it works ;) Mine patchjust directly patches
bash.exe excutable, so it isn't usable on the systems, different than
mine.

The most fine way is to modify configure scripts for libstdc++ to
allow them use PWD_CMD by default as other configures (gcc, etc) does.
I'm currently working on this feature.

-- 
With best regards,
 Anton                          mailto:asl at math.spbu.ru

Sunday, May 14, 2006 5:24:54 PM

Faculty of Mathematics & Mechanics, Saint-Petersburg State University