I've been unable to install Leiningen on macOS 10.15; I've followed the install instructions at leiningen.org.
The error I get is
gw#MacBook-Pro bin % sh lein
Error: -classpath requires class path specification
My classpath is
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/Users/gw/usr/bin
and the lein install script (from leiningen.org) is in /Users/gw/usr/bin
Could the problem be leftover dirs/files from previous installations of lein?
My Macbook Pro is fairly new (< 1 year). Could it be that I don't have some software or package that's needed somewhere?
I've been banging about the Internet and the CLI for several hours and can't find a solution. Thanks in advance for your help.
I presume in your question above, you meant shell path and not classpath, and your PATH environment variable is set to what you showed in your question. If you installed lein as per the instructions, you should not need sh lein. Just lein should work.
I presume you've installed the lein from leiningen.org into /Users/gw/usr/bin and that it is executable.
Make sure that the new lein is in your path. See what which lein says. Does it point to the new lein? If you had a different version of lein installed via brew, it might be in /usr/local/bin which is first in your PATH.
Is java installed on your Macbook? Try java -version and see that it returns what you expect.
Make a new empty directory and cd to it.
Then run lein. It should show you the usage, if all is okay.
I don't know why this worked, but it did. I'm posting this because it may be a clue to someone who reads this.
Solution: I deleted the "empty" directory structure that I had created early (i.e., lein new foo) and recreated it from scratch (lein new foo). Everything worked fine.
My best guess as to why this worked is that I had created the old foo directory structure under an old version of lein (i.e., before I reinstalled lein), and something must have been different after I reinstalled lein. Your explanation may vary ;)
Related
Since I installed according to the guide here on wsl2 ubuntu 20.04, I've been having errors related to libstc++.so.6, specifically GLIBCXX_3.4.26 not found (required by ...) where ... refers to different files within /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/ ending in .so, .so.1, .so.6 and so on (for instance, when running paraFoam the error would appear with respect to about 20 such files). I am able to successfully visualize the cavity tutorial (in paraview installation on windows).
I could get the errors to go away by doing what the user laborg suggested on Jan 4 for a similar problem with julia (see here), specifically copy libstdc++.so.6 from /usr/lib/x86_64-linux-gnu to /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/.
The questions is whether this copy-paste solution is recommended; will it come back and haunt me later? Is the libstdc++.so.6 from system installation going to be an issue if used in the lib64 folder of openfoam?
An additional info concerning openfoam installation, foamInstallationTest shows *not installed* errors against flex, wmake, gcc, g++, icoFoam and *critical error* for gcc, g++, icoFoam; but I as given here, foamInstallationTest is not meant for installation from the tar file. Openfoam installation seems to be alright based on the running of the cavity tutorial.
ok, please don't do copy past operation to solve this problem. The error means that you haven't installed the pre request libraries in your ubuntu. It seems that you have missed the first step in the tutorial.
It is not recommended but it will not hurt as long as the GLIBC versions returned from this command
strings /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6 | grep GLIBC
are a subset of the GLIBC versions from this command.
strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBC
which was no doubt the case for your Ubuntu setup.
A less risky route would be to redirect the soft link /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6 to point to your other libstdc++.so.6 (that way you retain both versions)
ln -sf /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6
Then, if you hit an issue, you can always reset the link back to its original target. Of course /usr/lib/x86_64-linux-gnu/libstdc++.so.6 is itself a soft link, but you can point to it all the same or you can point to its target.
I believe the issue you are hitting is a derivative of the one mentioned here https://www.cfd-online.com/Forums/main/229027-persistence-glibcxx_3-4-26-not-found.html, which would point towards the fact that it is not an installation error on your part but an issue related to the packaging of the OpenFoam binaries. I agree it would screw up the wsl2 setup owing to the way OpenFoam prepends everything to paths. Of course the safest route is to compile from source using the Ubuntu system's gcc and thereby bypass the ThirdParty.
Seeing as you are using Ubuntu in the WSL instance, could also just install the Ubuntu package directly:
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
This problem comes from this line in the tutorial:
echo "source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc" >> ~/.bashrc
This will point to OpenFOAM's libstdc++ everytime you open a terminal (or start a WSL2 session). If your workflow is not related to OpenFOAM, that can be an issue. If you remove or comment that line in your ~/.bashrc things should get back to normal. You can use nano in WSL2.
nano ~/.bashrc
Then comment:
#source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc
However, as OpenFOAM uses that bashrc, you will need to source the OpenFOAM bashrc in each terminal before using openFOAM.
source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc
My personal choice is to keep that line commented and, if I have a long work session using OpenFOAM, I just use nano to uncomment it, so every shell that I open works without sourcing again.
There are more elegant or complex approaches, but I prefer this one.
This answer should be valid with the 2006 version too, the link you shared points to 2012, so I guess they just updated the tutorial. If you installed 2006, just make sure when you source comment/uncomment to use the correct name.
In the same manner, if you followed another tutorial with another tool and sourced another library, you may experience issues.
Just start by taking a look at your bashrc and cleaning it.
I'm running Emacs 24.4 for Windows (installed through Chocolatey) and trying to install CIDER.
When I run M-x package-install [RET] cider [RET], I get [No match]. When I run M-x package-refresh-contents [RET], it hangs on Contacting host: elpa.gnu.org:80.
~/.emacs.d is populated with the GitHub repo recommended by braveclojure.com (here). I've reinstalled Emacs and I'm still getting the same problem.
I had this same problem on emacs ELPA wiki they say to set un ELPA you have to modify the emacs init file located at ~/.emacs or _emacs or ~/.emacs.d/init.el for me it was ~/.emacs-live.el since I have this version.
I just updated that file with the following:
(setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/")
("marmalade" . "http://marmalade-repo.org/packages/")
("melpa" . "http://melpa.org/packages/")))
Seems that I needed the configuration from where ELPA is going to look for packages.
After that i just ran M-x package-refresh-contents [RET] and M-x package-install [RET] cider [RET] that installed cider.
This guide fixed it for me: http://www.lonecpluspluscoder.com/2015/08/adding-tls-support-to-emacs-24-5-on-windows/
Basically go to: http://sourceforge.net/projects/ezwinports/files/, grab the gnutls library and just uncompress the archive at the root of your Emacs directory.
Afterwards, doing list-packages became near-instant for me. Using Emacs 24.5.1.
I had the same problem with Emacs 24 in Ubuntu 16.04 and nothing seemed to solve the problem. Finally, installing Emacs 25 solved the problem.
New Emacs packages are available here
sudo add-apt-repository ppa:kelleyk/emacs
sudo apt-get update
apt-get install emacs27
The problem is that the ELPA package signing key has expired. A new Emacs version will include a new key. Note that currently (2020 Oct) there is Emacs 27 available for Ubuntu 16.04.
Also make sure that you use https urls (and not plain http).
Another possibility may be to install new keys to an older Emacs version.
Windows binaries may also be available somewhere.
Other than setting up your package archives, like a previous answer mentions (FWIW I'm using HTTPS directly)
(setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/")
("marmalade" . "https://marmalade-repo.org/packages/")
("melpa" . "https://melpa.org/packages/")))
one might encounter another problem but with the same symptom of getting stuck at "Contacting host" due to running gpg in batch mode to verify the packages, but needing some input. You can disable that via
(setq package-check-signature nil)
Stack Overflow sometimes deletes chats. Fortunately it seems like I've still got access to a read-only version of the transcript.
From my perspective we didn't get a satisfactory answer. Here are the highlights:
We determined that the variable package-archives contained only GNU ELPA.
After discovering this, the OP wrote
I edited the package.el file. It works!
I suggested that editing a core Emacs Lisp file is not a good solution, but didn't hear anything back from the OP.
Since the referenced init.el file tries to add MELPA, I think there's something else going on. Perhaps the .emacs.d/ directory is in the wrong location, for example.
Editing package.el is certainly not a good solution. Doing more work to determine why the config isn't being properly loaded would be a good approach.
I have faced this issue on Emacs 24.5.1.
I searched here in SO and outside SO, nothing worked for me. I had to circumvent the problem by installing a newer version of Emacs: emacs25.
OS: Ubuntu 12.04
Go version reporting: 1.1.1
Action:
I have configured the .profile to contain the following lines:
export GOPATH="$HOME/workspace"
export PATH=$PATH:$GOPATH/bin
I have ensured that they are set in the go configuration by running "go env". However when I try to run the command, the screen reports as shown in the image below:
Possible constraining issues:
1) The box originally had Go v1.0 on it and I upgraded it to go version1.1.1, not sure that should mean anything...but if there is some twin configuration madness at work that may explain the fact it's not working despite the path being set.
2) I had the export commands in the .profile file but I see some threads indicate to put it in .bashrc, trying in either still gives the same problem.
Do I need to uninstall go 1.0 ? I just assumed version 1.1.1 would over ride it but that could be wrong. Ideally I wanted to uninstall go entirely and then install version 1.1.2 but I couldn't find anything at golang.org on uninstalling assuming that does solve the problem.
Thanks in advance for any assistance.
As the commenter above stated, you should not use sudo with go get. When you do, you have the root user's environment (which doesn't have your GOPATH) and any files or directories it creates won't be editable by your user. In the past, the go get command would not warn about not having a $GOPATH and so it was easier to get tripped up by this.
To fix your permissions, run the following command to change ownership back to your user:
sudo chown -R "$USER:" "$GOPATH"
You should only ever need to run a plain go get because you can (and should) set your $GOPATH to be a directory you can control. Be sure to read the How To Write Go Code and in particular its discusson on GOPATH.
I had install maven3 on another computer without problem few days ago, but I don't understand this problem.
(I have read the http://maven.apache.org/download.cgi to install maven, follow the instructions)
My M2_HOME is : C:\maven\apache-maven-3.0.5
My JAVA_HOME is : C:\Program Files\Java\jdk1.7.0_10
My PATH : C:\Ruby193\bin;C:\devkit;C:\devkit\ansi\x64;C:\Ruby193\include\ruby-1.9.1;%M2_HOME%\bin;%JAVA_HOME%\bin
Each folder contain the program it should include.
But when I launch mvn --version in a new console, nothing happen. I have to kill my console because I can't do anything in it. (I waited for 3 minutes without results, just in case)
And so with all maven command.
Edit : Thanks to baba, a new info :)
The problem is only with Mingw. It works with a classical dos console.
You don't need ruby to have maven. You, however, need java.
On another note, try to go to where the binary of maven is:
as in:
C:\maven\apache-maven-3.0.5\bin
then execute mvn --version. Also, if it doesn't work, try manually calling mvn.bat (which should be there for a Windows installation) with --version argument. If it still doesn't work, something is wrong with your maven installation, and we can go from there.
But if it works, then it is a path issue.
Just upgraded to RC1 of RM 3.2 on MacOS Lion and couldn't run the application anymore. Running with rvm. On startup the mysql2 gem reported it couldn't find libmysqlclient.18.dylib on a dlopen.
Solved it. Posting the solution here so it will help somebody save some time.
Using Apple's Property List Editor create an entry in ~/.MacOS/environment.plist call LD_LIBRARY_PATH and set the value to /usr/local/mysql/lib or whereever your MySQL libraries live.
Logout and log back in and RubyMine and the mysql2 gem are happy again.
I got around this by adding this to the environment variables section of the RubyMine server instance.
1) Open Run/Debug Configurations for your server
2) Click on the "..." next to "Environment Variables"
3) Add "DYLD_LIBRARY_PATH" as the key and "/usr/local/mysql/lib/" as value (path from using .dmg MySQL install)
There have been several solutions suggested, but I think the best solution is the last one I suggest:
1) Editing Environment Variables in the Run/Debug Configuration
This works but you have to keep doing for every single configuration, which is a pain. It also doesn't fix the problem if you are running outside of RubyMine.
2) Editing the .MacOS/environment.plist
This seems to not be supported anymore in later versions of OS X.
3) Setting the DYLD_LIBRARY_PATH environment variable in the .profile/.bashrc
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/usr/local/mysql/lib/
This fixed the problem on the console, but RubyMine doesn't seem to load the environment from .profile/.bashrc.
4) Symlink the libmysqlclient.18.dylib into /usr/local/lib
This is what Homebrew typically does, which is to create a symlink for the dylib that cannot be loaded.
ln -s /usr/local/mysql/lib/libmysqlclient.18.dylib /usr/local/lib/libmysqlclient.18.dylib
You only need to do this once and you're done.. and it works globally, in the console and in RubyMine.
Using Apple's Property List Editor create an entry in ~/.MacOS/environment.plist call LD_LIBRARY_PATH and set the value to /usr/local/mysql/lib or whereever your MySQL libraries live.
Logout and log back in and RubyMine and the mysql2 gem are happy again.
#Aaron Chambers, couldn't add as an answer at that time. Thanks.