I have installed ocaml under cygwin64 (a Windows 10 computer). Ocaml, ocamlc seem to run fine, but I need packages. So I've tried opam, and it complained that ocamlfind was missing. I have tried to install ocamlfind it two ways - using opam and from the findlib repository on gitlab.camlcity.org - and in both cases, it failed on not finding dllunix.so . I noticde that the environment variable OCAMLLIB was C:\Ocaml (ie outside the cygwin directory tree), but that in /usr/lib/ocaml/stublibs there was such a file. Having modified OCAMLLIB to point there, I received the following error.
Cannot load required shared library dllunix. Reason: /usr/lib/ocaml/stublibs/dllunix.so: flexdll error: cannot relocate RELOC_REL32, target is too far: 0xfffffffc02c37112 0x2c37112.
I have a similar message on another library as well:
Error: Error on dynamically loaded library: /usr/lib/ocaml/stublibs/dllcamlstr.so: flexdll error: cannot relocate RELOC_REL32, target is too far: 0xfffffffc02b6a92a 0x2b6a92a
First:
this is not a programming question, it is a support requirement and the right place is the cygwin mailing list. You can follow guidelines on:
https://cygwin.com/problems.html
Second:
you can try the following approach, execute
/usr/bin/rebase-trigger fullrebase
than close all the cygwin programs and services, and run setup-x86_64 again.
Further info on document
/usr/share/doc/Cygwin/_autorebase.README
If number two fails, follow one. Really.
Related
When I run the config file for installing GSL library for Windows 10 I get the following error:
error: Something went wrong bootstrapping makefile fragments for
automatic dependency tracking. If GNU make was not used, consider
re-running the configure script with MAKE="gmake" (or whatever is
necessary). You can also try re-running configure with the
'--disable-dependency-tracking' option to at least be able to build
the package (albeit without support for automatic dependency
tracking).
If I run ./config MAKE="gmake" I still get the error. I have searched in StackOverflow and on the web and still haven't found a solution.
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...
While working on SNMP, I am not able to execute snmpwalk or snmpset. Then I checked snmpd -H.
I see an error as:
dlopen(/lib/libvcpeLiTapMediationTable.so) failed: /lib/libvcpeLiTapMediationTable.so: undefined symbol: memdup
dlopen(/lib/libvcpeLiTapStreamTable.so) failed: /lib/libvcpeLiTapStreamTable.so: undefined symbol: memdup
I think that my library might not be opening dynamically due to this.
When I load my packages in CentOS as rpms, I have no errors.
But for the same code, when I load my packages in Ubuntu as debian packages, I see this error.
Queries:
Is there any problem with SNMP installation (since it works on CentOS but not on Ubuntu)? Or is something missing in my debian packages?
Please explain the impact of this error on my operations.
Any relevant answers will be helpful as I am new to this.
Thank you.
Your libvcpeLiTapMediationTable.so depends on function memdup(). This is defined on your CentOS and wherever it was built, in either Net-SNMP or one of the libraries it or libvcpeLiTapMediationTable.so links to at run time, but is not defined on your Ubuntu. Consequently, it can't be loaded at won't work.
Net-SNMP defined memdup() in snmplib/tools.c, but this was renamed to netsnmp_memdup() to avoid conflicts with other libraries that might define their own version according to change history. Perhaps you are using two different versions of Net-SNMP between your two distros, one with and one without that change.
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 am writing my first Haskell program, a web application based on the Yesod framework.
I compiled the code using cabal configure && cabal build. When I try to run the executable, I get the following error:
-bash: dist/build/MyApp/MyApp: Operation not permitted
I installed the 64-bit Haskell platform (2012.2.0.0) on OS X Mountain Lion. I had originally installed the 32-bit version, but got the same error, so I uninstalled it and tried the 64-bit version.
The application compiles and links with no errors or warnings.
I even tried the fix described in http://reviews.cnet.com/8301-13727_7-57374676-263/workarounds-for-quarantine-bug-in-os-x-lion/, but it made no difference.
UPDATE: The plot thickens. The source tree is actually on an encrypted sparse bundle (all of my source code is). When I copy the tree to my home directory, it compiles and runs.
The mount command does not show the noexec option:
/dev/disk2s9 on /Volumes/Personal (hfs, local, nodev, nosuid, journaled, noowners, quarantine, mounted by grk)
I'm not sure about the quarantine option, but I suspect it comes from Symantec Endpoint Protection (required by my employer). I'll try disabling it for the sparse bundle.
I found the answer at the sister site apple.stackexchange.com: https://apple.stackexchange.com/questions/64456/mount-is-adding-a-quarantine-flag-causing-bin-bash-bad-interpreter-operatio
The sparse bundle is actually marked with the quarantine flag. I unmounted the volume and removed the quarantine with the following command:
xattr -d com.apple.quarantine Personal.sparsebundle
then remounted. Problem solved.