Naive concatenation of $LD_LIBRARY_PATH can result in an empty
colon-delimited segment; this tells glibc to load libraries from the
current directory, which is definitely wrong, and may be a security
vulnerability if the current directory is untrusted. (See #67234, for
example.) Fix this throughout the tree.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
- Replaced python override from the final stdenv, instead we
propagate our bootstrap python to stage4 and override both
CF and xnu to use it.
- Removed CF argument from python interpreters, this is redundant
since it's not overidden anymore.
- Inherit CF from stage4, making it the same as the stdenv.
In "perl: fuse configureFlags" [1] the effects of the preConfigure
phase were merged into configureFlags. After this change values with
spaces do not reach the configure script intact.
The only flag this affects is `ldflags` for Aarch32 and Mips, and perl
builds without it on armv7l-linux so it's probably no longer required
on any platform.
Fixes:
configuring
configure flags: -de -Dcc=cc <...> -Dldflags=\"-lm -lrt\"
./Configure: eval: line 1677: unexpected EOF while looking for matching `"'
./Configure: eval: line 1678: syntax error: unexpected end of file
Configure: unknown option -lrt"
[1] 3b50d0462a
In "perl: fuse configureFlags" [1] the effects of the preConfigure
phase were merged into configureFlags. After this change values with
spaces do not reach the configure script intact.
The only flag this affects is `ldflags` for Aarch32 and Mips, and perl
builds without it on armv7l-linux so it's probably no longer required
on any platform.
Fixes:
configuring
configure flags: -de -Dcc=cc <...> -Dldflags=\"-lm -lrt\"
./Configure: eval: line 1677: unexpected EOF while looking for matching `"'
./Configure: eval: line 1678: syntax error: unexpected end of file
Configure: unknown option -lrt"
[1] 3b50d0462a
When `makeWrapperArgs` variable is not set, `declare -p makeWrapperArgs`
will return with 1 and print an error message to stderr.
I did not handle the non-existence case in b0633406cb
because I thought `mk-python-derivation` will always define `makeWrapperArgs`
but `wrapProgram` can be called independently. And even with `mk-python-derivation`,
`makeWrappers` will not be set unless explicitly declared in the derivation
because of https://github.com/NixOS/nix/issues/1461.
I was lead to believe that because the builds were succeeding and I confirmed
that the mechanism fails when the variable is not defined and `-o nounset` is enabled.
It appears that `wrapPython` setup hook is not running under `-o nounset`, though,
invaldating the assumption.
Now we are checking that the variable exists before checking its type, which
will get rid of the warning and also prevent future error when `-o nounset`
is enabled in the setup hook.
For more information, see the discussion at
https://github.com/NixOS/nixpkgs/commit/a6bb2ede232940a96150da7207a3ecd15eb6328
Bash takes an assignment of a string to an array variable:
local -a user_args
user_args="(foo bar)"
to mean appending the string to the array, not parsing the string into
an array as is the case when on the same line as the declaration:
local -a user_args="(foo bar)"
b0633406cb extracted the declaration before
the newly branched code block, causing string makeWrapperArgs being added
to the array verbatim.
Since local is function scoped, it does not matter if we move it inside
each of the branches so we fix it this way.
When `makeWrapperArgs` is a Bash array, we only passed the first
item to `wrapProgram`. We need to use `"${makeWrapperArgs[@]}"`
to extract all the items. But that breaks the common string case so
we need to handle that case separately.
