[gentoo-portage-dev] ia64 rpaths and python building...

[gentoo-portage-dev] ia64 rpaths and python building...

[Markus Duft]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

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

[-- Attachment #2: portage-2.2.00.14771-ia64-rpath.patch --]
[-- Type: text/plain, Size: 1265 bytes --]

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

Re: [gentoo-portage-dev] ia64 rpaths and python building...

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1313 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-portage-dev] ia64 rpaths and python building...

[Ned Ludd]

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..