Re: [gentoo-dev] Re: [PATCH/RFC] eclass/flag-o-matic.eclass: prepend-ldpath

[Gregory M. Turner]

On 10/6/2012 1:31 AM, Fabian Groffen wrote:
> On 06-10-2012 00:47:57 -0700, Gregory M. Turner wrote:
>> In dev-lang/python*, we use
>>
>>     append-ldflags '-L.'
>>
>> to ensure linking is performed against the built libpython.so in-tree,
>> rather than than in the one in $(libdir).  But, this doesn't work if
>> LDFLAGS contains "-L$(libdir)".
>>
>> We could try to fix this like:
>>
>>    export LDFLAGS="-L. ${LDFLAGS}"
>>
>> or so.  That would cover 99.9% of the cases out there.  But very rarely,
>> indiscriminately placing our '-L.' before every other clause in LDFLAGS
>> might cause an unanticipated side-effect.
> I think it would make more sense in this case to just add one more patch
> to Python, such that the build-system just inserts it.  I recall it's
> necessary at least on FreeBSD, Darwin, Solaris, but I don't recall any
> more why it works/worked on Linux fine.

I was thinking along these lines as well.  As it turned out, however, I 
was not able to find an automagical, PMS-compliant, non-crazy way to do 
it that resolved my test-case (more on that below), without effectively 
hooking econf().

Literally hooking a core API seems like a Pandora's box better left 
unopened, so this is what I came up with (note: the fpectl stuff was 
also in my overlay and the patches got entangled -- rather than editing 
the hunk by hand, I just left it.  It's orthogonal to this issue, 
however, and for present purposes can be ignored):

------>8----->
--- PORTAGE/dev-lang/python/python-2.7.3-r2.ebuild
+++ OVERLAY/dev-lang/python/python-2.7.3-r2.ebuild
@@ -218,13 +255,6 @@
  	# http://bugs.python.org/issue15506
  	export ac_cv_path_PKG_CONFIG=$(tc-getPKG_CONFIG)

-	# Set LDFLAGS so we link modules with -lpython2.7 correctly.
-	# Needed on FreeBSD unless Python 2.7 is already installed.
-	# Please query BSD team before removing this!
-	# On AIX this is not needed, but would record '.' as runpath.
-	[[ ${CHOST} == *-aix* ]] ||
-	append-ldflags "-L."
-
  	local dbmliborder
  	if use gdbm; then
  		dbmliborder+="${dbmliborder:+:}gdbm"
@@ -248,11 +278,18 @@
  		&& myconf="${myconf} --enable-framework=${EPREFIX}/usr/lib" \
  		|| myconf="${myconf} --enable-shared"

+	if [[ ${CHOST} == *-cygwin* ]] ; then
+		fpeconfig="--without-fpectl"
+		myconf="${myconf} ac_cv_func_bind_textdomain_codeset=yes"
+	else
+		fpeconfig="--with-fpectl"
+	fi
+
  	# note: for a framework build we need to use ucs2 because OSX
  	# uses that internally too:
  	# http://bugs.python.org/issue763708
-	OPT="" econf \
-		--with-fpectl \
+	OPT="" cpython_econf \
+		${fpeconfig} \
  		$(use_enable ipv6) \
  		$(use_with threads) \
  		$( (use wide-unicode && use !aqua) && echo "--enable-unicode=ucs4" 
|| echo "--enable-unicode=ucs2") \
--- PORTAGE/eclass/python.eclass
+++ OVERLAY/eclass/python.eclass
@@ -401,6 +401,64 @@
  	fi
  }

+# see http://thread.gmane.org/gmane.linux.gentoo.devel/80633/focus=80635
+_python_prepend_cwd_ldpath() {
+	local new=()
+	local f
+	local done=no
+	for f in ${LDFLAGS} ; do
+		case "${f}" in
+			-Tbss=*|-Tdata=*|-Ttext=*|-Ttext-segment=*)
+				new+=( "${f}" )
+				;;
+			-L*|-T*|--library-path*|--script*)
+				if [[ ${done} == yes ]] ; then
+					new+=( "${f}" )
+				elif [[ "${f}" == "-L." ]] ; then
+					# if it's somehow already there, don't duplicate it
+					new+=( "-L." )
+					done=yes
+				else
+					new+=( "-L." "${f}" )
+					done=yes
+				fi
+				;;
+			*)
+				new+=( "${f}" )
+				;;
+		esac
+	done
+	[[ ${done} == no ]] && new+=( "-L." )
+	export LDFLAGS="${new[*]}"
+}
+
+# @FUNCTION: cpython_econf
+# @DESCRIPTION:
+# econf() substitute for use in dev-lang/python ebuilds
+#
+# On some platforms, it is neccesary to prepend "-L." to ldpath before
+# proceeding with python's configure process.  Using cpython_econf()
+# instead of econf() will ensure that this is taken care of correctly
+# before python's configure step can proceed.  This is not needed for
+# any python ebuilds other than dev-lang/python; any other ebuild
+# calling this function will receive an error.
+cpython_econf() {
+	if [[ "${CATEGORY}/${PN}" != "dev-lang/python" ]] ; then
+		die "cpython_econf can only be used by dev-lang/python ebuilds"
+	fi
+	# econf will enforce ${EBUILD_PHASE} requirements, so we don't bother.
+	
+	# Set LDFLAGS so we link modules with -lpython2.7 correctly.
+	# Needed on FreeBSD unless Python 2.7 is already installed.
+	# Even if python is already installed, linking against the old
+	# python will cause problems, i.e., when toggling USE="threads".
+	# Also needed on cygwin.  Please query BSD team before removing this!
+	# On AIX this is not needed, and would record '.' as runpath.
+	[[ ${CHOST} == *-aix* ]] || _python_prepend_cwd_ldpath
+
+	econf "$@"
+}
+
  # @FUNCTION: python_pkg_setup
  # @DESCRIPTION:
  # Perform sanity checks and initialize environment.
<-----8<-----

Some notes about the above:

Of course we would presumably want to make a similar change in all of 
the dev-lang/python ebuilds to the one above.

We could do this 100% automagically in python_pkg_setup, which was my 
initial plan.  But my test-case involves LDPATH being "scrubbed" in 
every phase by profile.bashrc.  After python_pkg_setup() changed LDPATH, 
it just broke again in subsequent phases (at least, I think that's what 
would have happened -- I never tested it).  Yes, that's a GIGO problem; 
however, it's debatable whether Gentoo or profile.bashrc is the one 
putting the "G)arbage I)n".  The most robust route is to insert our 
LDFLAG just before econf runs -- that's how the current implementation 
does it, after all, and we potentially create a regression if we move 
this logic to pkg_setup.

Also, I decided to leave my internal API as "_python_foo," although 
today, I'd say "__python_foo" is more correct.  python.eclass is chock 
full of "_python_foo" API's, so I decided it was probably cleaner to 
follow the existing patterns for now, rather than change one lone API 
while the rest remain unchanged.

As for cpython_econf -- is it OK that it doesn't begin with "python"? 
Or should it perhaps be "python_cpython_econf?"

Thanks for your input,

-gmt