I have been banging on this for hours now.
I am trying to push my repo changes to kiln but I get this error:
certificate checking requires Python 2.6
I have already installed a parallel install of Python 2.6 by following the instructions from this link, but the error still persists. The system is ClearOS 5.2 by the way.
My first question is, will installing/upgrading mercurial break my existing install?
I tried to re-install following these intstructions link1 and [i lost the other link], but encountered another error.
Then I found this command debuginstall and here's the result:
[root#system mercurial-1.7.5]# hg debuginstall
Checking encoding (UTF-8)...
Checking installed modules (/usr/lib/python2.4/site-packages/mercurial)...
Checking templates...
Checking patch...
Checking commit editor...
Checking username...
no username supplied (see "hg help config")
(specify a username in your configuration file)
1 problems detected, please check your install!
My another question is, can I just change the existing hg's settings to just use the python26 which is already installed?
Thanks in advance!
Install your own python (of whatever version you need) to a separate directory (e.g.: /usr/local/python-2.7.2/) and then change the invocation of hg from #!/usr/bin/python to #!/usr/local/python-2.7.2/bin/python This way you don't disturb the existing/system installation, but you can use the version you want only where you need it. The only annoying part about this is dealing with two sets of libraries, since this is really maintaining two parallel installations. So if the 'extra' python needs libraries, you must install them manually using the invocation and paths of the extra installation. Sounds complicated, but if you only need it for one program, then you set it up once and it's good to go.
Related
I am trying to install pysam.
After excecuting:
python path/to/pysam-master/setup.py build
This error is produced:
unable to execute 'x86_64-conda_cos6-linux-gnu-gcc': No such file or directory
error: command 'x86_64-conda_cos6-linux-gnu-gcc' failed with exit status 1
There are similar threads, but they all seem to address the problem assumig administriator rights, which I do not have. Is there a way around to install the needed files?
DISCLAIMER: This question derived from a previous post of mine.
manually installing pysam error: "ImportError: No module named version"
But since it might require a different approach, I made it a question of its own.
You can also receive the same error while installing some R packages if R was installed using conda (as I had).
Then just install the package by executing: conda install gxx_linux-64 to have that command available.
Source:
https://github.com/RcppCore/Rcpp/issues/770#issuecomment-346716808
It looks like Anaconda had a new release (4.3.27) that sets the C compiler path to a non-existing executable (quite an embarrassing bug; I'm sure they'll fix it soon). I had a similar issue with pip installing using the latest Miniconda, which I fixed by using the 4.3.21 version and ensuring I was not doing something like conda update conda.
See https://repo.continuum.io/miniconda/ which has release dates and versions.
It should now be safe to update conda. This is fixed in the following python packages for linux-64:
python-3.6.2-h0b30769_14.tar.bz2
python-2.7.14-h931c8b0_15.tar.bz2
python-2.7.13-hac47a24_15.tar.bz2
python-3.5.4-hc053d89_14.tar.bz2
The issue was as Jon Riehl described - we (Anaconda, formerly Continuum) build all of our packages with a new GCC package that we created using crosstool-ng. This package does not have gcc, it has a prefixed gcc - the missing command you're seeing, x86_64-conda_cos6-linux-gnu-gcc. This gets baked into python, and any extension built with that python goes looking for that compiler. We have fixed the issue using the _PYTHON_SYSCONFIGDATA_NAME variable that was added to python 3.6. We have backported that to python 2.7 and 3.5. You'll now only ever see python using default compilers (gcc), and you must set the _PYTHON_SYSCONFIGDATA_NAME to the appropriate filename to have the new compilers used. Setting this variable is something that we'll put into the activate scripts for the compiler package, so you'll never need to worry about it. It may take us a day or two to get new compiler packages out, though, so post issues on the conda-build issue tracker if you'd like to use the new compilers and need help getting started.
Relevant code changes are at:
py27: https://github.com/anacondarecipes/python-feedstock/tree/master-2.7.14
py35: https://github.com/anacondarecipes/python-feedstock/tree/master-3.5
py36: https://github.com/anacondarecipes/python-feedstock
The solution that worked for me was to use the conda to install the r packages:
conda install -c r r-tidyverse
or r-gggplot2, r-readr
Also ensure that the installation is not failing because of admin privileges.
It will save you a great deal of pain
After upgrading Golang to 1.19.1, I started to get:
# runtime/cgo
cgo: C compiler "x86_64-conda-linux-gnu-cc" not found: exec: "x86_64-conda-linux-gnu-cc": executable file not found in $PATH
Installing gcc_linux-64 from the same channel, has resolved it:
conda install -c anaconda gcc_linux-64
Somewhere in your $PATH (e.g., ~/bin), do
ln -sf $(which gcc) x86_64-conda_cos6-linux-gnu-gcc
Don't put this in a system directory or conda's bin directory, and remember to remove the link when the problem is resolved upstream. gcc --version should be version 6.
EDIT: I understand the sentiment in the comments against manipulating system paths, but maybe we can use a little critical thinking for the actual case in hand before reciting doctrine. What actually have we done with the command above? Nothing more than putting an executable (symlink) called x86_64-conda_cos6-linux-gnu-gcc in one's personal ~/bin directory.
If putting something in one's personal ~/bin directory broke future conda (after it fixes the C compiler path to point to gcc it embeds), then that would be a bug with conda. Would the existence of this verbosely named compiler mess with anything else? Unlikely either. Even if something did pick it up, it's just your system gcc after all...
This post summarize my painful but finally successful (just by chance) way to build own conda package for the
netgen meshing tool with Python interface. I found the recipe for the netgen build due to tpaviot.
After cloning the repository into 'netgen-conda' folder I ran:
conda build netgen-conda/netgen-6.2-dev
Which reports "Unsatisfiable dependencies": 'oce', 'gcc-5', 'binutils'.
So I tried to install these packages myself. Unfortunately the documentation do not emphasize the important fact that 'conda build' use its own temporary environment so it doesn't matter what you have installed (see). Nevertheless even installing 'gcc-5' together with 'binutils' manually turns out to be nearly impossible.
Hint for other newbies: Lot of my problems disappear after I learned details about channels.
First try was installing 'gcc-5' with 'binutils' from the 'salford_systems' channel suggested by anaconda:
conda install -c salford_systems binutils gcc-5
But it results in:
ERROR conda.core.link:_execute_actions(337): An error occurred while installing package 'salford_systems::gcc-5-5.3.0-0'.
LinkError: post-link script failed for package salford_systems::gcc-5-5.3.0-0
running your command again with-vwill provide additional information
location of failed script: /home/jb/miniconda3/envs/test/bin/.gcc-5-post-link.sh
Using verbose output ('-v') provides no more info. I was also confused by the fact that the script does not exist on the given path (probably automatically deleted).
With current experience I admit that the reason of problem can be dug out from the '-vv' output (reported issue). After some trying I found that only way to
install both is to first install 'gcc-5' into a clean environment and then install 'binutils'. Since 'conda build' installs everything
from scratch and there is no way to specify order of installed packages I was stuck.
Another issue that puzzled me is the 'conda build' long prefix hack. For unknown reason they use extremely long prefix for an auxiliary folder
which result in various kind of issues. I have faced to three such problems:
As is usual today, I have encrypted HOME causing a known issue.
Using a workaround '--croot /tmp' prevents creating the hard links from '/tmp' into 'HOME/miniconda3' since they are on different filesystems.
There is a fallback to use the copy. I even thought that the fallback doesn't work for a while, but it worked, just making the build running longer.
Trying to install 'gcc' (4.x) from 'default' channel complained about too short prefix. So ultimate workaroud was to set the length of the prefix manually
'--prefix-length 70'.
Finally, I found that the dependency on 'binutils' is not necessary and successfully build the package with:
conda build --prefix-length 70 -c salford_systems -c conda-forge -c dlr-sc netgen-conda/netgen-6.2-dev
Summary (of open questions):
Conda channels introduce a new kind of dependency hell already forgotten when using 'apt-get'. Is there a way to figure out what is a canonical channel for a package.
Does anyone succeed to build with combination 'gcc-5' and 'binutils'?
There is still lack of documentation about internal conda mechanisms and error messages do not provide clue to the problem.
Conda-build use a problematic prefix hack and lack ability to control order of installed packages. Does anybody know the reason for this hack?
I have Python3 installed via brew install python3. However, cmake cannot find PythonLibs 3. Here's the header of my CMakeLists.txt.
cmake_minimum_required(VERSION 3.0)
find_package(PythonLibs 3 REQUIRED)
When I ran cmake, I got this error message
Could NOT find PythonLibs: Found unsuitable version "2.7.6", but required is at least "3" (found /usr/lib/libpython2.7.dylib)
Not sure what I did wrong.
In my experience, this happened because I was using an older version of cmake (2.8 instead of 3+) that didn't know about Python 3.4 (it gave up after 3.3.)
The solution was to go into the CMakeLists.txt file and add an "additional versions" directive ABOVE the find_package:
set(Python_ADDITIONAL_VERSIONS 3.4)
find_package(PythonLibs 3 REQUIRED)
You could probably also fix it by upgrading your version of cmake. But the above worked for me with cmake 2.8
Because you are using CMake >= 3.0, you can you find_package(Python COMPONENTS Interpreter Development) see: https://cmake.org/cmake/help/v3.12/module/FindPython.html
That would for instance give you for:
find_package(Python COMPONENTS Interpreter Development)
message("Python_FOUND:${Python_FOUND}")
message("Python_VERSION:${Python_VERSION}")
message("Python_Development_FOUND:${Python_Development_FOUND}")
message("Python_LIBRARIES:${Python_LIBRARIES}")
Results:
Python_FOUND:TRUE
Python_VERSION:3.8.0
Python_Development_FOUND:TRUE
Python_LIBRARIES:/usr/lib/x86_64-linux-gnu/libpython3.8.so
Another reason for this is that CMake can't ever find Python 3 when it is installed from brew on OSX. It looks like the CMake devs know that FindPythonLibs sucks and have a ticket to revamp it but it doesn't look like it will happen any time soon.
I believe the Python interpreter itself knows where its libraries and headers are so I think the best thing to do would be to run it to find out. To get the path to the Python interpreter I would force the user to specify it manually. One of the big issues with Python is that lots of software includes its own copy so you'll end up with 5 copies of it on your system. The chance of picking up the wrong one is just too high. Get the user to specify the correct one.
Nowdays I'm just trying to build libsamperate from source using MSYS on Windows, but i meet a configure checking problem I've installed FFTW & libsndfile before, their include files lib files and pkg-config files are all in the right place, but when I use sh ./configure to generate makefile for libsamprate the output always mentions
checking for pkg-config... no
checking for SNDFILE... no
I also set the PKG_CONFIG_PATH(usr/local/lib/pkgconfig) and tried many times but the result seems the same
Does anyone knows anything about this?
As mentioned in comments, your environment is not set up to run the pkg-config executable. There are many problems associated with pkg-config, and it has become increasingly popular to suggest that the correct solution is to stop using it completely. Unfortunately, if you are trying to install a package that does use pkg-config, you are not in a position to use that solution. The closest you can get is to set PKG_CONFIG to 'true' or ':' in your environment. This causes pkg-config to emit no output but always return true when it is run, so you need to specify locations of libraries and headers via the standard mechanisms (LDFLAGS, etc.).
pkg-config is great in that it allows a user (someone installing the package) to be ignorant of the standard flags. The problem with pkg-config is that it allows the users to be ignorant.
As a package maintainer, you should stop using pkg-config. As a user, you should either set PKG_CONFIG=: in your environment or in a config.site, or get in the habit of invoking configure with PKG_CONFIG=: as an argument. (If you are using packages that rely on ancient autoconf in which you cannot pass such flags as an argument, I'm not sure what the appropriate action is, but suggesting that the package maintainer upgrade is probably not a bad idea.)
when trying to install cygwin, I keep getting this error message:
the entry point
rl_filename_rewrite_hook could not be
located in the dynamic link library
cygreadline7.dll
Has anyone seen this before ?
Thanks
I had the same error with cygwin1.dll. I checked in c:\cygwin\bin and noticed there were two files, cygwin1.dll and cygwin1.dll.new (possibly from a failed or aborted setup run?). The ".new" version was in fact newer (and slightly larger) than the existing cygwin1.dll, so I replaced cygwin1.dll with cygwin1.dll.new, and ran setup again. It completed with no errors.
First idea is to try reinstalling libreadline7 (or similarly named package) using the cygwin installer. Use the search field to enter readline to make it easier to find the right package.
Another option is that in the cygwin installer, change form Curr to Prev in order to switch to the previous-stable release. This means lots and lots of downloading and reinstalling. I anctually did manage to provoke my error into becoming a libreadline7 error, and switching to Prev at least got rid of the error messages. (Yay! Now bash, ssh server and git is working again! Back to work here then...)
Please check your path in WINDOWS (advanced system properties) environment. I found that C:\WinAVR\bin was coming before my cygwin path, so I moved that to the end, fixed my issue.
If you have multiple CYGWIN1.DLL files in your system, it definitely causes headaches if you're not careful.