When to use PYTHONPREFIX_SITELIBDIR?
A port I maintain, multimedia/gpodder, needs to install a set of Python
modules from another distfile called mygpoclient.
Here are the pertinent excerpts from the port Makefile, as I inherited
it from the previous maintainer:
DISTFILES= ${DISTNAME}${EXTRACT_SUFX}:DEFAULT \
${MGC_DISTNAME}${EXTRACT_SUFX}:mygpoclient
...
MGC_DISTNAME= mygpoclient-1.4
MGC_WRKSRC= ${WRKDIR}/${MGC_DISTNAME}/mygpoclient
...
pre-build:
@${PYTHON_CMD} ${PYTHON_LIBDIR}/compileall.py ${MGC_WRKSRC}
@${PYTHON_CMD} -O ${PYTHON_LIBDIR}/compileall.py ${MGC_WRKSRC}
pre-install:
@${MKDIR} ${PYTHON_SITELIBDIR}/mygpoclient
@(cd ${MGC_WRKSRC} && ${COPYTREE_SHARE} .
${PYTHON_SITELIBDIR}/mygpoclient)
The pkg-plist then contains multiple lines of the following form, to
delete the files installed in the pre-install step:
...
%%PYTHON_SITELIBDIR%%/mygpoclient/api.py
%%PYTHON_SITELIBDIR%%/mygpoclient/api.pyc
...
I've submitted a PR to update gpodder to 2.8 (and now 2.9), but the
committers are reporting plist errors related to these mygpoclient
files. The files are not being removed when gpodder is pkg-deleted.
While researching this, I ran some simple tests using
ports-mgmt/genplist and noticed that the mygpoclient files were being
installed under /usr/local/lib and NOT under the tmp prefix as expected.
("genplist create /tmp/portname" sets PREFIX to /tmp/portname and
installs the port there. I like to use it as a quick-and-dirty test of
the install.)
So I tried using PYTHONPREFIX_SITELIBDIR in the pre-install commands,
and this seemed to work here on my own machine, testing with both
genplist and tinderbox. (The pkg-plist lines were unchanged.)
Today, however, I got another report of a plist failure. I'm not
sure if the version tested was using PYTHONPREFIX_SITELIBDIR and
will ask the committer about that. But I would like to get some
advice from this list: is my approach correct? Is there a better
way to accomplish the goal?
___
freebsd-python@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-python
To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
py-numpy build failure, multiple definition of `__i686.get_pc_thunk.bx'
I've encountered the problem described in PR146801, which unfortunately was closed without getting to the root cause. (The problem seems to have gone away as mysteriously as when it appeared. No one seems to know why either event occurred.) py-numpy is, as you know, used by many other ports. So I'd really like to know how to fix this. FreeBSD 8.2-PRERELEASE #0: Thu Feb 3 17:45:33 PST 2011 Portstree also updated on Feb 3. Default python version is 2.7. (But pkg_add -r wants to install py26-numpy. So that solution is unavailable.) customize UnixCCompiler customize UnixCCompiler using build_ext customize Gnu95FCompiler customize Gnu95FCompiler using build_ext building 'numpy.core._sort' extension compiling C sources C compiler: gcc45 -DNDEBUG -mtune=generic -msse -msse2 -msse3 -mfpmath=sse -O2 -fno-strict-aliasing -pipe -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x2 -mtune=generic -msse -msse2 -msse3 -mfpmath=sse -O2 -fno-strict-aliasing -pipe -Wl,-rpath=/usr/local/lib/gcc45 -fPIC compile options: '-Inumpy/core/include -Ibuild/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/local/include/python2.7 -Ibuild/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/multiarray -Ibuild/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/umath -c' gcc45: build/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/_sortmodule.c cc -shared -pthread -mtune=generic -msse -msse2 -msse3 -mfpmath=sse -O2 -fno-strict-aliasing -pipe -Wl,-rpath=/usr/local/lib/gcc45 build/temp.freebsd-8.2-PRERELEASE-i386-2.7/build/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/_sortmodule.o -Lbuild/temp.freebsd-8.2-PRERELEASE-i386-2.7 -lm -o build/lib.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/_sort.so build/temp.freebsd-8.2-PRERELEASE-i386-2.7/build/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/_sortmodule.o(.text.__i686.get_pc_thunk.bx+0x0): In function `__i686.get_pc_thunk.bx': : multiple definition of `__i686.get_pc_thunk.bx' /usr/lib/crtbeginS.o(.gnu.linkonce.t.__i686.get_pc_thunk.bx+0x0): first defined here build/temp.freebsd-8.2-PRERELEASE-i386-2.7/build/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/_sortmodule.o(.text.__i686.get_pc_thunk.bx+0x0): In function `__i686.get_pc_thunk.bx': : multiple definition of `__i686.get_pc_thunk.bx' /usr/lib/crtbeginS.o(.gnu.linkonce.t.__i686.get_pc_thunk.bx+0x0): first defined here error: Command "cc -shared -pthread -mtune=generic -msse -msse2 -msse3 -mfpmath=sse -O2 -fno-strict-aliasing -pipe -Wl,-rpath=/usr/local/lib/gcc45 build/temp.freebsd-8.2-PRERELEASE-i386-2.7/build/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/_sortmodule.o -Lbuild/temp.freebsd-8.2-PRERELEASE-i386-2.7 -lm -o build/lib.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/_sort.so" failed with exit status 1 *** Error code 1 Stop in /usr/ports/math/py-numpy. ___ freebsd-python@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: py-numpy build failure, multiple definition of `__i686.get_pc_thunk.bx'
On Fri 04 Feb 2011 at 02:05:44 PST Kostik Belousov wrote: On Thu, Feb 03, 2011 at 09:15:00PM -0800, Charlie Kester wrote: ... customize UnixCCompiler customize UnixCCompiler using build_ext customize Gnu95FCompiler customize Gnu95FCompiler using build_ext building 'numpy.core._sort' extension compiling C sources C compiler: gcc45 -DNDEBUG -mtune=generic -msse -msse2 -msse3 -mfpmath=sse -O2 -fno-strict-aliasing -pipe -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x2 -mtune=generic -msse -msse2 -msse3 -mfpmath=sse -O2 -fno-strict-aliasing -pipe -Wl,-rpath=/usr/local/lib/gcc45 -fPIC compile options: '-Inumpy/core/include -Ibuild/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/local/include/python2.7 -Ibuild/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/multiarray -Ibuild/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/umath -c' gcc45: build/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/_sortmodule.c cc -shared -pthread -mtune=generic -msse -msse2 -msse3 -mfpmath=sse -O2 -fno-strict-aliasing -pipe -Wl,-rpath=/usr/local/lib/gcc45 build/temp.freebsd-8.2-PRERELEASE-i386-2.7/build/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/_sortmodule.o -Lbuild/temp.freebsd-8.2-PRERELEASE-i386-2.7 -lm -o build/lib.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/_sort.so build/temp.freebsd-8.2-PRERELEASE-i386-2.7/build/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/_sortmodule.o(.text.__i686.get_pc_thunk.bx+0x0): In function `__i686.get_pc_thunk.bx': : multiple definition of `__i686.get_pc_thunk.bx' /usr/lib/crtbeginS.o(.gnu.linkonce.t.__i686.get_pc_thunk.bx+0x0): first defined here build/temp.freebsd-8.2-PRERELEASE-i386-2.7/build/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/_sortmodule.o(.text.__i686.get_pc_thunk.bx+0x0): In function `__i686.get_pc_thunk.bx': : multiple definition of `__i686.get_pc_thunk.bx' /usr/lib/crtbeginS.o(.gnu.linkonce.t.__i686.get_pc_thunk.bx+0x0): first defined here error: Command "cc -shared -pthread -mtune=generic -msse -msse2 -msse3 -mfpmath=sse -O2 -fno-strict-aliasing -pipe -Wl,-rpath=/usr/local/lib/gcc45 build/temp.freebsd-8.2-PRERELEASE-i386-2.7/build/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/_sortmodule.o -Lbuild/temp.freebsd-8.2-PRERELEASE-i386-2.7 -lm -o build/lib.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/_sort.so" failed with exit status 1 *** Error code 1 Can you show the actual invocation of the compiler driver for linking ? Isn't that the line right before the first report of the error? cc -shared -pthread -mtune=generic -msse -msse2 -msse3 -mfpmath=sse -O2 -fno-strict-aliasing -pipe -Wl,-rpath=/usr/local/lib/gcc45 build/temp.freebsd-8.2-PRERELEASE-i386-2.7/build/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/_sortmodule.o -Lbuild/temp.freebsd-8.2-PRERELEASE-i386-2.7 -lm -o build/lib.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/_sort.so FWIW, I tried modifying my make.conf to remove the additional CFLAGS I'd added, like -fno-strict-aliasing. But the build still failed using only the CFLAGS provided by the ports system and py-numpy's configtests. I also checked for environment variables related to the linker and found none. (For this build I'm logged into the console, not a terminal emulator, as root and am not using a custom profile.) My PATH looks like this: /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin I do have gcc45 installed, but only as a result of some other port that required it. I forget which one. Anyway, you can see that it's being used in the excerpt above. ___ freebsd-python@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: py-numpy build failure, multiple definition of `__i686.get_pc_thunk.bx'
On Fri 04 Feb 2011 at 10:55:12 PST Charlie Kester wrote: I do have gcc45 installed, but only as a result of some other port that required it. I forget which one. Anyway, you can see that it's being used in the excerpt above. D'oh. py-numpy itself has a requirement for gcc45, as I discovered just now after deinstalling gcc45 and attempting to build py-numpy using the compiler from base. ___ freebsd-python@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: py-numpy build failure, multiple definition of `__i686.get_pc_thunk.bx'
On Fri 04 Feb 2011 at 11:54:00 PST Kostik Belousov wrote: On Fri, Feb 04, 2011 at 10:55:12AM -0800, Charlie Kester wrote: On Fri 04 Feb 2011 at 02:05:44 PST Kostik Belousov wrote: >Can you show the actual invocation of the compiler driver for linking ? Isn't that the line right before the first report of the error? cc -shared -pthread -mtune=generic -msse -msse2 -msse3 -mfpmath=sse -O2 -fno-strict-aliasing -pipe -Wl,-rpath=/usr/local/lib/gcc45 build/temp.freebsd-8.2-PRERELEASE-i386-2.7/build/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/_sortmodule.o -Lbuild/temp.freebsd-8.2-PRERELEASE-i386-2.7 -lm -o build/lib.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/_sort.so I wanted the confirmation of exact command that failed. If your citation above is right, then port _does not_ use gcc45 to do linkage of the module. Generally, crtbegin/crtend.o come from the compiler installation, so I am suspicious at least to report of use of /usr/lib/crtbegin.So. Can you enter the port build directory and execute the same command manually, substituting "cc" with full path to gcc45 ? Done. Replacing "cc" with "gcc45" built the library without any error. (I didn't need to specify the full path to gcc45.) So the question is, why is cc being invoked in the first place? As far as I know, I'm not doing anything to force using it. Something seems to have gone wrong during py-numpy's configtests... ___ freebsd-python@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: py-numpy build failure, multiple definition of `__i686.get_pc_thunk.bx'
On Fri 04 Feb 2011 at 13:22:19 PST Charlie Kester wrote:
On Fri 04 Feb 2011 at 11:54:00 PST Kostik Belousov wrote:
On Fri, Feb 04, 2011 at 10:55:12AM -0800, Charlie Kester wrote:
On Fri 04 Feb 2011 at 02:05:44 PST Kostik Belousov wrote:
>Can you show the actual invocation of the compiler driver for linking ?
Isn't that the line right before the first report of the error?
cc -shared -pthread -mtune=generic -msse -msse2 -msse3 -mfpmath=sse -O2
-fno-strict-aliasing -pipe -Wl,-rpath=/usr/local/lib/gcc45
build/temp.freebsd-8.2-PRERELEASE-i386-2.7/build/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/_sortmodule.o -Lbuild/temp.freebsd-8.2-PRERELEASE-i386-2.7 -lm -o build/lib.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/_sort.so
I wanted the confirmation of exact command that failed. If your
citation above is right, then port _does not_ use gcc45 to do linkage
of the module. Generally, crtbegin/crtend.o come from the compiler
installation, so I am suspicious at least to report of use of
/usr/lib/crtbegin.So.
Can you enter the port build directory and execute the same command
manually, substituting "cc" with full path to gcc45 ?
Done. Replacing "cc" with "gcc45" built the library without any error.
(I didn't need to specify the full path to gcc45.)
So the question is, why is cc being invoked in the first place? As far
as I know, I'm not doing anything to force using it. Something seems
to have gone wrong during py-numpy's configtests...
After some sleuthing I tried:
# make LDSHARED="gcc45 -shared" install
This seems to have worked. The build and install now succeeds without
complaint. Hooray!
So where did the "cc" come from?
/usr/local/lib/python2.7/distutils/unixccompiler.py has the following line:
'linker_so': ["cc", "-shared"]
The base class defined in ccompiler.py sets linker_so to ${LDSHARED} if
that environment variable is defined, and that assignment seems to be
inherited all the way down into the numpy scripts. Otherwise, we get
the value defined in unixccompiler.py.
___
freebsd-python@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-python
To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
