I am looking options to integrate Python 3 tools / scripts to Plone's buildout.cfg (which targets Python 2.6). How eggs between different buildout recipes are shared? Because namely, running setup.py for Python 3 eggs would cause syntax errors in Python 2 environment.
Can I specify Python 3 interpreter (in portable manner) for a buildout recipe like zc.recipe.egg
Will the rest of the buildout happily eat the eggs coming under this recipe using particular Python interpreter, or would it clash with the host environment
... or do one have to create a virtualenv inside buildout itself to get Python 3 stuff installed
You can specify the executable to be used by many recipes, including zc.recipe.egg:
[python3.3]
executable = /usr/local/bin/python3.3
[py3script]
recipe = zc.recipe.egg:scripts
python = python3.3
eggs = py3script
That should install the py3script scripts with python 3.3. The key here is the python key, which points to a section that should have a executable option, which is a path to the python executable you want to use.
The executable key is then used by the easy_install module internal to zc.buildout to run the setup.py script and install the egg.
Related
Background: I compile bitcoind on one system but run it on another. When I compiled bitcoind 0.19.1 some time back using the following method, I was able to run bitcoind and bitcoin-cli on the target system without issue. I think.
./autogen.sh
./configure --disable-wallet --disable-tests --disable-bench --disable-gui --enable-util-tx=no --prefix=$HOME/bitcoind/x64 --exec-prefix=$HOME/bitcoind/x64
make && make install
Today I compiled v0.20.0 using the same method. If I run ./bitcoind -version on the system I compiled the binary it runs fine, but if I take the binary to my target system I get the following error:
./bitcoind: error while loading shared libraries: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
The binary seemed to be portable last time, and the pre-compiled binary I download from the Bitcoin Core team runs fine.
Note that on the target system libboost-filesystem-dev and libboost-filesystem1.67-dev are not installed, this is likely the source of my error. That said, running the pre-compiled binary from the Core team runs, so why doesn't mine?
Can someone help me understand if I did something wrong or if I need to add ./configure flags to make the binary more portable? Specifically what I likely did differently than the core developers that made my binary fail where theirs worked?
EDIT 1: Running ./configure --enable-static or ./configure LDFLAGS=-static does not result in a portable binary either.
Also note that installing libboost-filesystem library with apt does fix the error.
Thanks to Andrew Chow for his helpful answer to this on the bitcoind StackExchange. I needed to build the depends as per the depends documentation. Since I'm building for the same platform I'll be running on, I can run make in the depends directory with no arguments except -j2 which uses two cores. Change the number to however many cores you want to commit to the compile.
cd depends
make -j2
cd ..
./autogen.sh
./configure --prefix=$PWD/depends/x86_64-pc-linux-gnu
make -j2 && make install
Per the Julia Docs:
The build step is executed the first time a package is installed or when explicitly invoked with build. A package is built by executing the file deps/build.jl.
Why would I want to make a build.jl file and how do I effectively utilize the benefits it allows for?
Typically (historically) the build step and the build.jl file is used for downloading/installing binary dependencies with e.g. BinaryProvider (or its predecessor BinDeps)1. The build step can also be used to install configuration files. For example, IJulia uses build.jl in order to install a Julia kernel for Jupyter.
If your package is pure Julia code you typically don't have a build.jl file since there is no need for it.
1 With Julia 1.3 we have Artifacts which is meant to replace the BinaryProvider workflow and make build.jl obsolete for the purpose of downloading and installing prebuilt binaries.
I'm trying to cross compile MPICH and statically link libraries using the following commands:
export CC="/buildroot-2015.02/output/host/usr/bin/arm-linux-gcc"
export CFLAGS="-march=armv5te -I/buildroot-2015.02/output/host/usr/include/"
export LDFLAGS="--static -L//buildroot-2015.02/output/host/usr/lib/"
./configure --prefix=/mpich-3.1.3/build/ --host=arm-linux --disable-shared --with-pm=hydra --with-device=ch3:nemesis --disable-fortran
After building I tried file mpiexec and I got the following:
mpiexec: symbolic link to `mpiexec.hydra'
$ file mpiexec.hydra
mpiexec.hydra: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
I want know how to link MPICH statically.
On Ubuntu 13.04 VM, which was used to build the sc utility, the dependency looks like the below:
$ ldd sc | grep -i png
libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xb75c2000)
On my Fedora VM, the sc utility is not linking libpng correctly. It has libpng15 but it is trying to link to libpng12:
$ ldd sc | grep -i png
libpng12.so.0 => not found
libpng15.so.15 => /lib/libpng15.so.15 (0xb6f40000)
I am using cmake to build my executables, and I am using the default FindPNG cmake file. My executable is statically linking to ImageMagick, which is configured to use libPNG.
find_package(ImageMagick COMPONENTS MagickWand MagickCore REQUIRED)
find_package(ZLIB)
find_package(Threads)
find_package(JPEG)
find_package(PNG)
find_package(LibLZMA)
find_package(OpenMP)
find_package(Cairo)
include_directories(${ImageMagick_INCLUDE_DIRS})
include_directories(${CAIRO_INCLUDE_DIRS})
target_link_libraries(sc
${LIBCAIRO}
${ImageMagick_LIBRARIES}
${JPEG_LIBRARIES}
${PNG_LIBRARIES}
${LIBLZMA_LIBRARIES}
${ZLIB_LIBRARIES}
${CMAKE_THREAD_LIBS_INIT}
${X11_LIBRARIES}
${OpenMP_LIB}
)
I've tried making my own FindPNG cmake to target libpng.so. I still get the same result...
Is there any way to make that so that my executable will link to whatever libpng is found on user's machine?
It looks like there is nothing that I can do with cmake, and the problem is coming from libraries that I am linking against (Cairo and ImageMagick).
The reason that there are two libpng dependencies on the deployed system is that I am deploying a prebuild ImageMagick (statically) which is built on a machine with libpng12. I assumed that the deploy system will have Cairo and libpng, and it does, but it does not have libpng12. It has libpng15 and Cairo, which is linking against it. Therefore, ldd shows that my executable is dependent on libpng12 and libpng15.
To resolve this, I statically link against libpng12 and any libraries that are linking it.
I have accession to universities server: Red Hat Enterprise Linux release 6.2.
My work is to test various scientific analysis programs.
I have no problem untar'ing and running them in my local directory. But most of them have lots of dependencies (perl libraries, RE2, GNU SL, glibc.i686 ) - whenever I try to install those dependencies I come up with the permission problem.
All of those packages require root to install.
Is there a way how can I install various different packages only in my local directory without asking root to install them system wide?
Yes, but the procedure varies per package. Many modern Unix packages have a configure script that you must run, which takes a --prefix option + argument specifying where the package should be installed. A directory such as $HOME/pkg would be a good options for these. Other configuration/building/installation scripts have similar options.
When building a package with dependencies, make sure you have $HOME/pkg/bin in your PATH, $HOME/pkg/lib in your LD_LIBRARY_PATH and pass -I$HOME/pkg/include and -L$HOME/pkg/lib to the compiler and linker, respectively. E.g., put the following in your shell startup file (.bashrc for Bash):
PATH=$HOME/pkg/bin:$PATH
CFLAGS=-I$HOME/pkg/include
LDFLAGS=-L$HOME/pkg/lib
LD_LIBRARY_PATH=$HOME/pkg/lib
(You shouldn't have to install glibc, ever.)