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
