ia64 rpaths and python building...
 

Hey!

I recently did some ia64-hpux hacking in prefix, and i stumbled over
alittle problem:

the native linker collects -L options on the command line, and python
uses -L. while building. this results in . beeing in rpath.

now when $PWD == $S, there is libpython-*.so, and executing the already
installed python finds (through rpath ".") this local libpython. this
(although binary exactly the same) refuses to load installed extensions
(Fatal Python Error: ....).

The problem was caused by the filter-bash-environment.py call in
ebuild.sh, _only_ during the "test" phase seemingly.

the attached patch fixes the problem for me - what do you think? I guess
there are better ways to tackle the problem, but i needed to get this to
work ;)

Cheers, Markus
Only in portage.orig/bin: .ebuild.sh.swp
diff -ru portage.orig/bin/ebuild.sh portage/bin/ebuild.sh
--- portage.orig/bin/ebuild.sh 2009-12-14 10:18:06 +0100
+++ portage/bin/ebuild.sh 2009-12-14 14:45:55 +0100
@@ -1791,7 +1791,15 @@
"
fi

- EPYTHON= "${PORTAGE_BIN_PATH}"/filter-bash-environment.py "${filtered_vars}"
+ (
+ # at least on _some_ platforms, RPATH may contain ".". now if merging
+ # python, and PWD at call-time of this filter is ${S}, it can be, that
+ # there is a ./libpython-x.x.so, which gets loaded. Even if the to-be-
+ # installed is binary identical to the already-installed one: this leads
+ # to "Fatal Python error: Interpreter not initialized (version mismatch?)"
+ cd "${T}"
+ EPYTHON= "${PORTAGE_BIN_PATH}"/filter-bash-environment.py "${filtered_vars}"
+ )
}

# @FUNCTION: preprocess_ebuild_env
@@ -2270,7 +2284,7 @@
# Save the env only for relevant phases.
if ! hasq "$EBUILD_SH_ARGS" clean help info nofetch ; then
umask 002
- save_ebuild_env | filter_readonly_variables > "$T/environment"
+ save_ebuild_env | filter_readonly_variables > "$T/environment" || exit $?
chown ${PORTAGE_USER:-portage}:${PORTAGE_GROUP:-portage} "$T/environment" &>/dev/null
chmod g+w "$T/environment" &>/dev/null
fi

ia64 rpaths and python building...
 

On Thursday 17 December 2009 04:38:36 Markus Duft wrote:
> I recently did some ia64-hpux hacking in prefix, and i stumbled over
> alittle problem:
>
> the native linker collects -L options on the command line, and python
> uses -L. while building. this results in . beeing in rpath.
>
> now when $PWD == $S, there is libpython-*.so, and executing the already
> installed python finds (through rpath ".") this local libpython. this
> (although binary exactly the same) refuses to load installed extensions
> (Fatal Python Error: ....).
>
> The problem was caused by the filter-bash-environment.py call in
> ebuild.sh, _only_ during the "test" phase seemingly.
>
> the attached patch fixes the problem for me - what do you think? I guess
> there are better ways to tackle the problem, but i needed to get this to
> work ;)

this ignores the real problem. there should never be an installed binary
whose rpath includes $PWD. this is a terrible security issues waiting to bite
you in the ass, or cause random failures depending on what the user's cwd is
at any point in time.

the second change (adding the || exit) is a good idea in theory, but the
proposed change is incorrect. use the assert helper so that the exit values
of all commands in the pipeline are checked.
-mike

ia64 rpaths and python building...
 

On Thu, 2009-12-17 at 05:21 -0500, Mike Frysinger wrote:
> On Thursday 17 December 2009 04:38:36 Markus Duft wrote:
> > I recently did some ia64-hpux hacking in prefix, and i stumbled over
> > alittle problem:
> >
> > the native linker collects -L options on the command line, and python
> > uses -L. while building. this results in . beeing in rpath.
> >
> > now when $PWD == $S, there is libpython-*.so, and executing the already
> > installed python finds (through rpath ".") this local libpython. this
> > (although binary exactly the same) refuses to load installed extensions
> > (Fatal Python Error: ....).
> >
> > The problem was caused by the filter-bash-environment.py call in
> > ebuild.sh, _only_ during the "test" phase seemingly.
> >
> > the attached patch fixes the problem for me - what do you think? I guess
> > there are better ways to tackle the problem, but i needed to get this to
> > work ;)
>
> this ignores the real problem. there should never be an installed binary
> whose rpath includes $PWD. this is a terrible security issues waiting to bite
> you in the ass, or cause random failures depending on what the user's cwd is
> at any point in time.
>
> the second change (adding the || exit) is a good idea in theory, but the
> proposed change is incorrect. use the assert helper so that the exit values
> of all commands in the pipeline are checked.
> -mike

Yep to everything Mike said..