I was installing nvidia-drivers on Centos 6.10 which included a --skip-broken flag and may have broken yum. Whenever I ran yum commands this error pops up.
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
/lib64/libc.so.6: version `GLIBC_2.14' not found (required by /lib64/libgcc_s.so.1)
Please install a package which provides this module, or
verify that the module is installed correctly.
It's possible that the above module doesn't match the
current version of Python, which is:
2.6.6 (r266:84292, Jun 20 2019, 14:14:55)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-23)]
If you cannot solve this problem yourself, please go to
the yum faq at:
http://yum.baseurl.org/wiki/Faq
I stumbled upon this thread which talks about installing the missing GLIBC version, but I ran into this error in step 8 ../configure --prefix=/opt/glibc-2.14
checking for forced unwind support... no
configure: error: forced unwind support is required
Which then took me to this forum thread that states I should install libunwind via yum. Which was my original problem, thus leaving me at an impasse. What should I do?
You need to reinstall GCC, or more precisely the libgcc package. Something overwrote /lib64/libgcc_s.so.1 with an incompatible version. You should be able to download the libgcc RPM package from a mirror, and then run:
# rpm --reinstall libgcc-4.4.7-23.el6.x86_64.rpm
This should still work because RPM itself does not depend on libgcc_s.
In general, if you need newer versions of these core system libraries (glibc, libstdc++, libgcc_s), you need to upgrade the entire operating system. Even if you manage to replace them in a consistent fashion, you are running something that isn't very close to the original operating system anymore. At that point, it is more prudent to upgrade, because that will give you a consistent system that has been tested by many others.
Related
I need a C compiler on my s390, which runs RHEL 7.6. When I do "yum list | grep gcc", I have the following:
libgcc.s390x 4.8.5-36.el7
compat-gcc-44.s390x 4.4.7-8.el7
compat-gcc-44-c++.s390x 4.4.7-8.el7
gcc.s390x 4.8.5-16.el7
gcc-c++.s390x 4.8.5-16.el7
gcc-gfortran.s390x 4.8.5-16.el7
gcc-objc.s390x 4.8.5-16.el7
gcc-objc++.s390x 4.8.5-16.el7
libgcc.s390 4.8.5-16.el7
I then do: yum install gcc.s390x and I obtain the following error:
Error: Package: glibc-2.17-196.el7.s390
Requires: glibc-common = 2.17-196.el7
Installed: glibc-common-2.17-260.el7_6.3.s390x (#rhel-7-for-system-z-rpms)
glibc-common = 2.17-260.el7_6.3
Available: glibc-common-2.17-196.el7.s390x
glibc-common = 2.17-196.el7
What I read from this is that s390x package is installed but the one needed is the one that does not have the s390 extension.
How can I get around this ? I pulling gcc directly from git but when I do a configure the message says that a compiler needs to be installed.
Any help would be much appreciated. Thanks - C
This output line
Available: glibc-common-2.17-196.el7.s390x
shows that the configured repositories only contain glibc versions up to RHSA-2017:1916. This means that you have configured repositories for Red Hat Enterprise Linux 7.4 (and not even Extended Update Support). However, someone at one point upgraded glibc to a package version from Red Hat Enterprise Linux 7.6.
Installing GCC needs additional glibc components, and these have to match the already-installed version. Since the 7.6 packages are not available from the configured repositories, installation fails with a dependency error.
If you need assistance with subscription management, you should file a support ticket.
I have been trying to install obspy and have been running into a lot of problems. I want to install obspy which has a dependency on pyproj. But apparently obspy only works with pyproj 1.9.5.1, which I tried installing using pip (pip3 install pyproj==1.9.5.1), but only got the errors like-
_proj.c:7488:13: error: ‘PyThreadState’ {aka ‘struct _ts’} has no member named ‘exc_traceback’; did you mean ‘curexc_traceback’?
Digging deeper I found that it might be a Cython problem, and installing pyproj directly from github might help, because it would apparently make Cython recompile all the necessary files. Something along the lines of -
pip3 install git+https://github.com/jswhit/pyproj.git
However this one gives the error -
ERROR: Minimum supported proj version is 6.2.0, installed version is 5.2.0.
I di try installing a higher version of libproj-dev (sudo apt install libproj-dev=6.2.0) however it shows that there is no candidate for 6.2.0. I tried downloading the deb file and installing from that using -
sudo apt-get install ~/Downloads/libproj-dev_6.2.0-1_amd64.deb
which just leads to the error -
The following packages have unmet dependencies:
libproj-dev : Depends: libproj15 (= 6.2.0-1) but it is not installable
E: Unable to correct problems, you have held broken packages.
But I think this is not the right way to install for me anyway, since I need a specific version. Hence I tried installing directly from the tarball of the release -
pip3 install https://github.com/pyproj4/pyproj/archive/v1.9.5.1rel.tar.gz
Which leads to the first error I had, evidently due to Cython.
With errors on everything I tried to do to fix this, I am not sure what even is relevant to my problem now.
Any help is appreciated, and if this site is not the correct place for this question, please help me migrate it to its proper destination.
I am on Ubuntu 18.10.
The problem is, that Cython-generated c-files don't work for Python-3.7 if generated with Cython versions up to 0.27.3 (at least): The setup.py of pyproj (at least in the version 1.9.5.1) doesn't regenerate the_proj.c, which is generated with Cython 0.23.2 and thus the installation cannot succeed.
You have the following options:
stay on Python3.6 where everything works out of the box.
regenerate _proj.c with a current Cython-version.
For the second option:
download and unzip your prefered version from https://github.com/pyproj4/pyproj/releases/tag/v1.9.5.1rel and switch to the created folder pyproj-1.9.5.1rel.
check, that the cython-version is >=0.27.3. via cython --version.
regenerate the _proj.c file via cython -3 _proj.pyx (_proj.pyx looks like Python3-code, but also language_level=2 (i.e. cython -2 _proj.pyx) will probably work.
install running pip install .
pyproj 1.9.5.1 was release at Jan 7, 2016. At that time, the latest version Python was 3.5. In my tests. pyproj 1.9.5.1 failed to be installed on Python 3.7.4, but succeeded on Python 3.5.7.
You need to create a environment with Python 3.5 by pyenv or conda.
References
pyproj 1.9.5.1 release
Python release history
I am attempting to install the Cairo package in the development version of R on Mac OS X 10.7.4, but I'm running into an issue that I cannot resolve.
I have installed Cairo with homebrew (i.e., brew install cairo) and received the following message:
==> Caveats This formula is keg-only, so it was not symlinked into /usr/local.
Mac OS X already provides this program and installing another version
in parallel can cause all kinds of trouble.
The Cairo provided by Leopard is too old for newer software to link
against.
Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add its lib
& include paths to your build variables:
LDFLAGS -L/usr/local/Cellar/cairo/1.12.2/lib
CPPFLAGS -I/usr/local/Cellar/cairo/1.12.2/include
With the above message in mind, I attempted to install the Cairo package from R-Forge with the following R command:
install.packages("Cairo", repos="http://www.rforge.net/", configure.args = c("CAIRO_LIBS=/usr/local/Cellar/cairo/1.12.2/lib", "CAIRO_CFLAGS=/usr/local/Cellar/cairo/1.12.2/include/cairo"))
I receive the following error:
checking cairo.h usability... no
checking cairo.h presence... no
checking for cairo.h... no
configure: error: Cannot find cairo.h!
Please install cairo (http://www.cairographics.org/) and/or set
CAIRO_CFLAGS/LIBS correspondingly. ERROR: configuration failed for package ‘Cairo’
I repeated the same command without the repos argument (by default, I use the FHCRC mirror) with the same result.
At this point, the problem seems obvious: the file cairo.h is not present. But then I listed the files in the include/cairo directory. Here's the response:
ls /usr/local/Cellar/cairo/1.12.2/include/cairo
cairo-deprecated.h cairo-ft.h
cairo-ps.h
cairo-script-interpreter.h
cairo-svg.h
cairo-xcb.h
cairo-xlib.h
cairo-features.h
cairo-pdf.h
cairo-quartz.h
cairo-script.h
cairo-version.h
cairo-xlib-xrender.h
cairo.h
So, I'm pointing the installation of the Cairo package to the appropriate place, but the error persists. I have tried variations, such as CAIRO_CFLAGS=/usr/local/Cellar/cairo/1.12.2/include, with no luck.
Thoughts? Any help you can provide is greatly appreciated.
In case it's necessary, here is my sessionInfo:
R Under development (unstable) (2012-08-08 r60208) Platform: x86_64-apple-darwin11.4.0 (64-bit)
locale: [1]
en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages: [1] stats graphics grDevices utils
datasets methods base
other attached packages: [1] BiocInstaller_1.5.12
loaded via a namespace (and not attached): [1] tools_2.16.0
I had similar issue with cairo config error, and I already installed cairo with homebrew. Try below
brew install pkg-config
This solved mine problem.
A coworker and I just fixed the problem by ignoring all of what I typed above. Rather, we installed Cairo and all of its dependencies from source manually, thereby bypassing the usage of brew or variants like port. This worked like a charm, so I am not entirely sure what was wrong above.
After trying everything listed here, I found this blog post about installing the "full R package" using brew: https://luispuerto.net/blog/2018/05/11/installing-r-with-homebrew-with-all-the-capabilities/
What finally worked for me was building R explicitly with cairo (brew's default R tap uses --without-cairo and simply editing the tap did not solve the issue for me).
Works like a charm for me with R 4.0.2, cairo 1.16.0_3 under macOS Catalina 10.15.6.
I have installed the latest Haskell Platform for MAC OSX and I get the error "Setup: failed to parse output of 'ghc-pkg dump'" when I do anything with Cabal.
So I looked at my versions:
ralphtq$ ghc-pkg list Cabal
/Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.1/package.conf.d
Cabal-1.8.0.2
ralphtq-mac-mini:cabal-install-0.6.4 ralphtq$ cabal --version
cabal-install version 0.6.2
using version 1.6.0.3 of the Cabal library
This is telling me that even though I have Cabal 1.8 the cabal-instal is at version 0.6.2. I have tried to correct that using darcs to get the latest version of cabal-install, but I cannot get passed the error:
ralphtq$ sh bootstrap.sh
Checking installed packages for ghc-6.12.1...
parsec is already installed and the version is ok.
network is already installed and the version is ok.
Cabal is already installed and the version is ok.
mtl is already installed and the version is ok.
HTTP is already installed and the version is ok.
zlib is already installed and the version is ok.
cleaning...
Linking Setup ...
Configuring cabal-install-0.9.1...
Setup: At least the following dependencies are missing:
Cabal ==1.9.*
It is expecting Cabal to be >= 1.9.
I tried to install a previous version of Cabal but got the following error:
...
...
[50 of 51] Compiling Distribution.Simple ( Distribution/Simple.hs, Distribution/Simple.o )
[51 of 51] Compiling Main ( Setup.hs, Setup.o )
Linking Setup ...
Configuring Cabal-1.6.0.2...
Setup: failed to parse output of 'ghc-pkg dump'
I am back to the same problem.
I have also tried a complete re-install of the platform.
What are my next options? Help appreciated, thx.
Either you have installed an old version of the Haskell Platform, or you have a mixed up environment where you have installed over the top of an existing, older install, and so now have a mixture of ghc-pkg versions from 6.10.x and 6.12.x
Try removing those ghc-pkg and cabal binaries, and then installing the Platform. That way you won't have those old executables lying around.
It seems that I have more trouble getting standard Unix things to run on Snow Leopard than any other platform--including Windows cygwin
For the past couple of days, I've been trying to get ImageMagick to run on Snow Leopard.
The most obvious way, Mac Ports, fails:
tppllc-Mac-Pro:ImageMagick-sl swirsky$ sudo port install imagemagick
---> Computing dependencies for p5-locale-gettext
---> Configuring p5-locale-gettext
Error: Target org.macports.configure returned: configure failure: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_perl_p5-locale-gettext/work/gettext-1.05" && /opt/local/bin/perl Makefile.PL INSTALLDIRS=vendor " returned error 2
Command output: checking for gettext... no
checking for gettext in -I/opt/local/include -arch i386 -L/opt/local/lib -lintl...gettext function not found. Please install libintl at Makefile.PL line 18.
no
Error: Unable to upgrade port: 1
Error: Unable to execute port: upgrade xorg-libXt failed
Before reporting a bug, first run the command again with the -d flag to get complete output.
tppllc-Mac-Pro:ImageMagick-sl swirsky$
Not wanting to spend another two days figuring out why my libintl doesn't have a "gettext" function, I tried a different route: the script mentioned here: http://github.com/masterkain/ImageMagick-sl
This script downloads and installs an ImageMagic independently of MacPorts issues
tppllc-Mac-Pro:ImageMagick-sl swirsky$ /usr/local/bin/convert
dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib
Referenced from: /opt/local/lib/libfontconfig.1.dylib
Reason: Incompatible library version: libfontconfig.1.dylib requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0
Trace/BPT trap
It downloads everything and compiles fine, but fails when I try to run it, with the message above.
So now I'm two steps away from ImageMagick, trying to get a newer libiconv on my machine.
I downloaded the latest libiconv, compiled and built it. I put the resulting library in /opt/local/lib, and I still get the same error message:
tppllc-Mac-Pro:.libs swirsky$ sudo mv libiconv.2.dylib /opt/local/lib/libiconv.2.dylib
tppllc-Mac-Pro:.libs swirsky$ convert
dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib
Referenced from: /opt/local/lib/libfontconfig.1.dylib
Reason: Incompatible library version: libfontconfig.1.dylib requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0
Trace/BPT trap
Now here's something interesting. The error message shows it's looking in /opt/local/lib/libiconv.2.dylib.
otools -L shows that this does implement 8.0.0:
tppllc-Mac-Pro:.libs swirsky$ otool -L /opt/local/lib/libiconv.2.dylib
/opt/local/lib/libiconv.2.dylib:
/usr/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0)
tppllc-Mac-Pro:.libs swirsky$
And, for good measure, I set the DYLD_LIBRARY_PATH to make sure this directory is the one for dynamic libraries.
So even though I do have a library that provides 8.0.0, it's being seen as 7.0.0! Any ideas why this would happen?
So here's my question: Is it possible to get ImageMagick to run on OSX Snow Leopard? Are there any binary distributions that have static libraries baked in so I don't have to worry about these issue/
This worked for me:
sudo brew install imagemagick
You may also try the ImageMagick install script located here:
http://github.com/masterkain/ImageMagick-sl
It helped me a lot. May be needed to change some library versions inside the script.
I've seen this exact error with this exact library in multiple situations. It was, in every case, an instance where either the individual or an script they were using was setting the DYLD_LIBRARY_PATH variable.
Make sure this variable is not being set as it overrides loading the explicitly linked libraries with those at that path.
If the DYLD_* must be set, use the more sane DYLD_FALLBACK_LIBRARY_PATH. Which will attempt to load the explicitly linked libraries first, then fallback to the user declared ones.
I did notice on your initial build that it was not finding the gettext library in macports. So make sure those are installed.
My google showed up a few hits, and the first or second one had a link to the binary.
I was finally able to get my "macports" installation consistent enough to get imagemagick installed and running. I had to manually delete my /opt/local/ directores where the files lived, and clean out some other dependencies.
It seems that the dynamic linker is pulling in the system libiconv.2.dylib (which has compatibility version 7.0.0). Without seeing your entire build process it's hard to know for sure why this is, but I'm suspicious of your libiconv build; note that in the following failure:
tppllc-Mac-Pro:.libs swirsky$ otool -L /opt/local/lib/libiconv.2.dylib
/opt/local/lib/libiconv.2.dylib:
/usr/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0)
your libiconv.2.dylib seems to think that its install path is /usr/local/lib, not /opt/local/lib. This probably why the dynamic linker isn't finding it; it's looking for it in /usr/local/lib, not finding it, and falling back on the system library in /usr/lib. Try setting the install path for your libiconv.2.dylib so that it's load commands tell the linker to look for it in /opt/local/lib, and that may resolve the issue.
I had the same problem, and solved it by uninstalling then reinstalling libiconv using Macports. Then everything works fine (I also have /opt/local/lib/ as the first entry in my DYLD_LIBRARY_PATH variable)
Strange. I'm pretty happy with my macports - and everything is compiled without errors. I can only advice - use macports.
ImageMagick #6.6.9-9_0+graphviz+hdri+jpeg2+mpeg+perl+q16+rsvg+wmf (active)