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
