I'm using OS X 10.8.2 with Haskell Platform 2012.4.0.0. When updating packages with cabal install, the binary symlinks don't get updated to point to the new binary versions. I must delete the symlink manually and reinstall the package. cabal install says:
Warning: could not create a symlink in
/Users/thsoft/Library/Haskell/bin for elm because the file exists
there already but is not managed by cabal. You can create a symlink
for this executable manually if you wish. The executable file has been
installed at
/Users/thsoft/Library/Haskell/ghc-7.4.1/lib/Elm-0.7/bin/elm
I tried using sudo and specifying --symlink-bindir=/Users/thsoft/Library/Haskell/bin explicitly, but none of them helped. How could I fix this?
Just remove the existing links that are present in the specified directory.
Tener's answer is correct: before 'cabal install'ing remove the links that would cause problems. I've had the same problem and this solved it.
(I couldn't make this a comment to Tener's answer since that would require more reputation than I have. :-( )
Related
Currently I am trying to install a rpm secured_soft_2.0.0.rpm and i am
unable to install it as we already have secured_soft_1.3.0 installed.
Requirement is that we need to have both the versions installed.
Complexities :
These package inturn have dependent rpm's (lot of them ) and all these
interdependent rpm's also have versions
ex: secured_soft_1.3.0 works only with packages which are of version 1.3,
and secured_soft_2.0.0.rpm work only with dependecies of version 2.0 only.
So all these dependencies also need to be reinstalled and even these
dependenies should be parallely installed, without deleting old.
Finally , both these versions contain shared libraries and these shared
lib's do not have version numbers in their name.
#rpm -ivh secured_soft_2.0.0.rpm
error: Failed dependencies:
init-class >= 1.4.17.1-1 is needed by secured_soft_2.0.0.rpm
init-connection-interface >= 2.0.11.0 is needed by secured_soft_2.0.0.rpm
init-logger >= 2.0.11.0 is needed by secured_soft_2.0.0.rpm
init-security >= 2.0.11.0 is needed by secured_soft_2.0.0.rpm
As i have specified we already have secured_soft_1.3.0.rpm installed and
above dependencies are also available but of different version.
So we need the to install above dependencies and also need the old version's
of dependencies for the old rpm's to work
ex : secured_soft_2.0.0.rpm has libArt.so libSec.so and so on
which are copied to /usr/lib
Similarly secured_soft_1.3.0.rpm also has libArt.so libSec.so and so on
which are already available in /usr/lib
I tried to rename the so's but still iam not able to install.
Is it possible to change the location for these so's and get the things done
Is there any way we can do it.
At the moment, iam stuck here and would need advice on this
Appreciate any help on this.
Since the programs use the same filenames, and you need to put them on the same machine, you might be able to move the older version to another directory tree and make it work there.
You can do this with many applications which do not have compiled-in pathnames.
For instance,
install the older version (this sounds like where you are starting from)
use rpm -ql for each of the packages containing unversioned executables, libraries and associated files.
use tar to capture an archive of those files, relative to /usr (but omitting directories not owned by the packages).
create a new directory, e.g., /usr/local/myapp and untar the older version there.
update configuration files in the new location as needed
For applications such as this, I would run in a script that updates PATH (and perhaps sets LD_LIBRARY_PATH) to force the program to run from the new location. You can verify if this works using tools such as strace and lsof, i.e., by looking for the files that the program opens.
Once you have the older version working properly in the new location, you can uninstall its rpms and install the new version of the application.
Caveat: If the newer package is copied from a newer version of the operating system, however, the task is likely to be beyond your ability, whether or not you choose the alternative approach of recompiling the newer packages to fit on the existing system.
Building new/custom packages is one route to recompiling the newer version. If you have the source-RPMs for each part, that is a starting point:
extract the files from the source-RPM, e.g., using a script such as unrpm (see for example HowTo: Extract an RPM Package Files Without Installing It), and
copy those extracted files to their as-expected locations in your build-tree, e.g., $HOME/rpmbuild/SOURCES and $HOME/rpmbuild/SPECS
modify the spec-file to use the alternative location
build the new/modified package using the modified spec-file.
No, out of the box, you cannot.
I'd highly recommend looking into Docker, where you can throw each one into their own container and let them take care of all their dependency problems.
I often have this issue when configuring a software on linux. When I install some library (for instance libsodium) by cloning the repository then doing the usual
./autoconf.sh
./configure
make
make install
I get everything install in /usr/local/ which is absolutely good for me.
Unfortunately, when I try to install something that depends on this library (for example libzmq, I get the issue
configure: error: Package requirements (libsodium) were not met:
No package 'libsodium' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables sodium_CFLAGS
and sodium_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
I guess the problem is because configure is looking on usr/ and not /usr/local. The ugly workaround is to install everything in usr/ instead of /usr/local. A more brutal approach would be to copy all what is installed in /usr/local into /usr/.
What is the correct solution when facing this kind of issues?
How should I adjust the PKG_CONFIG_PATH or the sodium_LIBS?
Set the PKG_CONFIG_PATH to /usr/local by means of your shell.
Some work with export, some with other means.
E. G.
export PKG_CONFIG_PATH=/usr/locall
run:
$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/
prior to ./autogen.sh && ./configure.
I have the 3.0.1 version of Alex installed on my /usr/bin. I think the Haskell Platform originally put it there (although I'm not 100% sure...).
Unfortunately, version 3.0.1 is bugged so I need to upgrade it to 3.0.5. I tried using cabal to install the latest version of Alex but cabal install alex-3.0.5 it installed the executable on .cabal/bin over on my home folder instead of on /usr/bin
Do I just manually copy the executable to /usr/bin? (that sound like a lot of trouble to do all the time)
Do I change my PATH environment variable so that .cabal/bin comes before /usr/bin? (I'm afraid that an "ls" executable or similar over on the cabal folder might end up messing up my system)
Or is there a simpler way to go at it in general?
I want to first point out the layout that works well for me, and then suggest how you might proceed in your particular situation.
What works well for me
In general, I think that a better layout is to have the following search path:
directories with important non-Haskell related binaries
directory that cabal install installs to
directory that binaries from the Haskell platform are in
This way, you can use cabal install to update binaries from the Haskell platform, but they cannot accidently shadow some non-Haskell related binary.
(On my Windows machine, this layout is easy to achieve, because the binaries from the Haskell platform are installed in a separate directory by default. So I just manually adapt the search path and that's it. I don't know how to achieve it on other platforms).
Suggestion for your particular situation
In your specific situation with the Haskell platform binaries already installed together with the non-Haskell related binaries, maybe you can use the following layout for the search path:
directory containing links to some of the binaries in 3
directory with important non-Haskell related binaries and Haskell platform binaries
directory that cabal install installs to.
This way, binaries from cabal install cannot accidently shadow the important stuff in 2. But if you decide you want to shadow something form the Haskell platform, you can manually add a link to 1. If it's a soft link, I think you only have to do that once per program name, and then you can call cabal install for that program to update it. You could even look up what executables are bundled with the Haskell platform and do that once and for all.
On second though, putting /.cabal/bin in front of /usr/bin in the PATH is simpler and is what most people do already.
Its also not a big deal since only cabal will put files in .cabal/bin so it should be predictable and with little risk of overwriting stuff.
Over here is the only reason I can find that packages I'm installing using cabal are not being found by GHC:
This happens when you install a package globally, and the previous packages were installed locally. Note that cabal-install install locally by default [...]
Presumably, "local installation" means putting packages in ~/.cabal/. First question: where are global installs?
I've been running cabal using sudo, so I guess that's a global install? The reason I've been doing this is that it complains about permissions when run without sudo, so this contradicts the statement "cabal-install install locally by default". Second question: how do I install locally and how do I install globally?
Trying to fix this mess, I've been randomly using sudo ghc-pkg unregister and randomly removing stuff from ~/.cabal/. Consequently my package tree is broken, probably locally and globally. Third question: How do I start again?
Edit: I'm running Ubuntu 10.10. I installed the Haskell Platform 2011.
Are you using Windows, OS X or some version of Linux? Are you using the Haskell Platform? Have you had a version of ghc or cabal before? For a Linux distribution, subtleties about your package manager may come in, of course. (Traces of an old ghc in particular, and an old ~/.ghc/ directory can be a source of trouble.)
Here are a few elementary thoughts of the type one goes through on #haskell with such problems. (My comprehension is not completely adequate, of course):
The chief question seems to be, Why you were being invited to do what should be local installs with sudo? A global install (cabal install pony --global) would of course require privileges if ghc and its libraries are in /usr/... or some other protected place, but otherwise sudo vs non-sudo is independent of the place of installation. What you do with cabal install pony --user (--user is the default, in theory) should not require superuser authority. (I have sometimes found on OS X that privileges are requested where the gcc needs to be called, but this has usually been due to curiosities about my setup.) But in any case sudo doesn't affect where cabal is putting them: the implicit --user and explicit --global, and more specific incantations for development, do that.
If you do ghc-pkg list, for example, it will divide the packages into the different places they are registered in according to two or more package.conf.d directories it is summarizing. On my laptop at the moment these are
/Users/applicative/.ghc/x86_64-darwin-7.0.3/package.conf.d/...
for the local things in ~/.cabal/lib/... and the protected
/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/package.conf.d
for things that were installed globally with the Haskell Platform installer (this location involves some OS X peculiarities, ghc, ghci and so on are in the woods somewhere, but symlinked to /usr/bin). The conf files for different packages tell you exactly where the libraries were installed. So, for example about the sacred base library,
$ cat base-4.3.1.0-f5c465200a37a65ca26c5c6c600f6c76.conf
tells me:
import-dirs:
/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/base-4.3.1.0
library-dirs:
/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/base-4.3.1.0
In any case, where does ghc-pkg list say your cabal install-ed packages are going? In the ~/.cabal folder, look at the file config. If you haven't edited it, I think the commented and uncommented lines, if they state a preference, are stating the defaults for installation with --global and --user. In the ~.ghc/ directory check out the subdirectory myghcversion/package.conf.d and see if anything is there, which should be the same as what ghc-pkg tells you. (You might study the options for ghc-pkg in general, eg. ghc-pkg check and ghc-pkg recache, if you haven't. You may have installed something in some odd way.)
If you installed ghc and cabal and co. by installing the Haskell Platform with a binary installer or your package manager, which seems like a good idea, it is also a good idea, I think, to keep the Platform libraries as something sacred, and make sure you never install anything globally from Hackage; among other things this is likely to have you overwriting Platform libraries -- though this doesn't seem the difficulty here: it would be more obvious if it were.
I installed a custom Haskell toolchain with the prefix $HOME/usr, so the compiler lives in $HOME/usr/bin/ghc and the documentation in $HOME/usr/share/doc/ghc/.... The toolchain consists of a ghc installation, a cabal installation and all the libs you need. I set up $PATH in a way, that all these programs are in it. There is no other installation of these tools on my system.
Now I tried to install some other libraries. But I always got the same error when cabal tried to install the documentation:
~$ cabal install --global binary
Resolving dependencies...
Configuring binary-0.5.0.2...
Preprocessing library binary-0.5.0.2...
Building binary-0.5.0.2...
... snip ...
Registering binary-0.5.0.2...
cabal: /usr/local/share/doc: permission denied
How can I tell cabal where the documentation should live? I don't want to give this information again and again in the shell, so the best would be a config file. I want to have all the haskell related stuff in my home tree, to avoid destroying my system with a wrong command.
Why are you installing with "--global"? By default this would put everything in /usr/local/. If you do a standard per-user install the docs will be installed into your home directory and it should work fine.
That being said, this is configurable via a file. The cabal config file is typically located at ~/.cabal/config/. Here's the relevant section of mine:
install-dirs global
-- prefix: /usr/local
-- bindir: $prefix/bin
-- libdir: $prefix/lib
-- libsubdir: $pkgid/$compiler
-- libexecdir: $prefix/libexec
-- datadir: $prefix/share
-- datasubdir: $pkgid
-- docdir: $datadir/doc/$pkgid
-- htmldir: $docdir/html
-- haddockdir: $htmldir
You can make whatever changes you like, just be sure to uncomment the lines. There is also an "install-dirs user" section, which is used in per-user installs.
I agree with the poster. Why is there no clear documentation for how to do
cabal install package --global
that prompts for sudo when permission is needed?
Doing
sudo cabal install package
is a bad idea because then you're building packages as root. And you have to allow an internet connection to write to a file owned by root (you will have to populate /root/.cabal or something like that).
Here is a good reason why one would want to do this:
If I install ghc and the haskell platform through my linux package manager (there are good reasons for this ;), then if I do cabal install package
it will not recognize the packages that globally recognized.
Well, someone actually posted a(n almost annoyingly) detailed description of how to do global installations (with either --global or install-dirs global) without running into permission errors. The trick is to use root-cmd sudo in the cabal config file.
See,
http://jdgallag.wordpress.com/2011/05/14/cabal-install-to-global-using-sudo-but-do-not-build-as-root/