The diff utility on my Cygwin always returns exit code of 57, no matter if files match, missmatch or do not exist.
I have installed diffutils successfully:
$ cygcheck -c diffutils
Cygwin Package Information
Package Version Status
diffutils 3.2-1 OK
$ which diff
/usr/bin/diff
Something must be broken in your Cygwin installation, because the Cygwin version of diff doesn't even have code in it to return exit code 57. It only uses 0, 1, and 2. That means some other piece of code is doing the exiting, which is highly suspicious.
I would first try a forced reinstall of diffutils and its dependencies, libintl8 and libiconv2. You will find both libraries in the Libs category in Cygwin's setup.exe. Click the value in the third column on the "Select Packages" screen until it says "Reinstall". (It should be "Keep" when you first enter this screen. If it's something else, that might be a clue as to what went wrong.)
If that doesn't fix it, I would suspect BLODA.
Related
enter image description here
I have basically tried every tutorial out there and still cant run valgrind.
So far....
I installed valgrind from their website to directory 'memcheck'
tar xvf valgrind-3.18.1.tar.bz2
the picture is the outcome of "./configure" ,I cant tell if it was successful or not.
then the command "make" gives: make: *** No targets specified and no makefile found. Stop.
and the same for "make install"
this is what i tried to do. How to install valgrind properly?
If the output from configure contains "configure: error:" then it failed.
Installing with your package manager will be easiest.
Otherwise, you will need
A C compiler (e.g., gcc or clang), always.
GNU make, always.
Perl, probably always.
Sed and awk, always.
Autotools, m4, if regenerating the configure script.
Lots of packages if you want to generate the docs.
A C++ compiler (g++ or clang++) if you want to build and run the regression tests.
I work on CentOS 5.5 and my computer used gcc-4.1.2 until now, and under /usr/lib/gcc/x86_64-redhat-linux/ there were 2 indexes: 4.1.1 and 4.1.2. For using some softwares I must update the gcc.
But after I installed gcc-4.7.0 from the downloaded gcc-4.7.0.tar.gz (I did not use yum because when I tried it all servers told me that I had the latest version which was certainly not true, and perhaps this was also caused by the problem I now face with), the /usr/lib/gcc/x86_64-redhat-linux/4.7.0/ was created just like the 4.1.1 and 4.1.2 index, so under /usr/lib/gcc/x86_64-redhat-linux/ there were 3 indexes: 4.1.1, 4.1.2 and 4.7.0. And under /usr/lib/gcc/x86_64-redhat-linux/4.7.0/ there were 6 indexes:
bin include lib lib64 libexex share
It looked like that 4.7.0 was successfully installed but when I ran
gcc --version
the result was still
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I also ran
update-alternatives --install /usr/bin/gcc gcc /usr/lib/gcc/x86_64-redhat-linux/4.7.0 40
to raise the priority of 4.7.0, and when I ran
update-alternatives --config gcc
it said
There is 1 program that provides 'gcc'.
Selection Command
-----------------------------------------------
*+ 1 /usr/lib/gcc/x86_64-redhat-linux/4.7.0
Enter to keep the current selection[+], or type selection number:
And I printed 1, all it looked like that 4.7.0 was selected as the default gcc, but when I ran gcc --version, the result was not changed! Still 4.1.2.
After that I even removed all 4.1.2 gcc and its related programs by rpm -e and deleted the index, but the result of gcc --version became
-bash: gcc: command not found.
It didn’t change when I reinstalled the 4.7.0.
After all, when I looked for the links of /usr/bin/gcc/ I found
/usr/bin/gcc -> /etc/alternatives/gcc
and link of /etc/alternatives/gcc was
/etc/alternatives/gcc -> /usr/lib/gcc/x86_64-redhat-linux/4.7.0
this should be the result of my running the update-alternatives line, so it has worked. It did make the link to 4.7.0. So why didn’t this link call 4.7.0 in the end? I can’t find out.
I even made the direct link to 4.7.0 then:
ln -s /usr/lib/gcc/x86_64-redhat-linux/4.7.0 /usr/bin/gcc
however this still didn’t work.
I am very confused with it. I will be grateful for your help. Thank you very much!
p.s. Thank Basile Starynkevitch very much for noticing me to make these explanations:
I have /usr/bin/ in my PATH, so this should be OK.
I am teached that /usr/bin/gcc/ should be linked to an executable but not index, so the link to 4.7.0 is wrong. But could anyone tell me which executable to link to, or which executable is /usr/bin/ linked to in a common computer? This may very likely lead to the solution to the problem.
I cannot run configure one more time because configure itself requires gcc but now it is not found. So I'm afraid the problem cannot be fixed by that.
Be aware of the PATH variable. You could have some $HOME/bin/ in it.
Restore your system's gcc (so undo all the mess you have done). Then run which gcc and gcc -v to understand what is it exactly.
If you compile GCC from its source code (as distributed by the FSF), choose a recent version, e.g. GCC 8 in fall 2018.
Read carefully about installing GCC. Compile it outside of its source code. Be aware of the many configure options. I suggest to consider configuring it with some --program-suffix option (such as --program-suffix=-8) and then adding symlinks (e.g. $HOME/bin/gcc -> /usr/local/bin/gcc-8) appropriately.
ln -s /usr/lib/gcc/x86_64-redhat-linux/4.7.0 /usr/bin/gcc
it is wrong. Since /usr/lib/gcc/x86_64-redhat-linux/4.7.0/ is some internal directory, and /usr/bin/gcc has to be an executable.
You probably don't need to run update-alternatives, but you do need to add (cleverly) something in a directory mentioned in your PATH
See also this answer to a similar question.
after edits in the question
You need first to clean up the mess you did under /usr/ (in particular in /usr/bin/ which you should never change without your package system). Remove all the things you added under /usr/bin/ and /usr/lib/. Then re-install forcibly and explicitly appropriate system gcc packages (using yum or some other package manager).
I have /usr/bin/ in my PATH, so this should be OK.
Probably not. My recommendation is to have $HOME/bin/ and /usr/local/bin/ early in your PATH (so before /usr/bin/; you might need to edit ~/.bashrc to change your PATH setting) and to add your new gcc, as something like gcc-8 (if you compile GCC 8 from its source code), there. If you want a system wide installation, have some /usr/local/bin/gcc-8 program. If you want a personal installation, have some $HOME/bin/gcc-8 program (both could be absolute symlinks to somewhere else).
I am trying to use Clang.
First, I downloaded the first two source files (LLVM source code + Clang source code) from here, under section "download llvm 3.8.1".
Then, I extracted them, and renamed the obtained extracted directories to llvm and clang (respectively). Then, I put the clang directory inside llvm/tools.
Finally, I followed the instuctions here, under the section "building Clang and working with the code", in the subsection "on Unix-like systems".
BTW, the reason why I renamed the directories to clang and llvm as in these insturctions these are the names of the directories, so I guess I should rename them.
And in step 9 ("try it out"), when I typed "clang --help", I got the message:
"The program 'clang' can be found in the following packages:
clang 3.3
clang 3.4
clang 3.5
Try sudo apt-get install < selected package >"
This means that the installation failed.
Why? What else should I do?
Thanks in advance!
The newly built clang will be in the bin directory of the build directory and this build directory is the location where you executed the command:
$ cmake -G "Unix Makefiles" <path_to_the_sources>
To run this clang, you will need to add the path to it:
$ <path_to>/bin/clang
Or you can -- as the instructions you referred to suggest -- add the full path to the clang to your PATH variable.
If your current directory is where clang is located, then you still need to add the current directory to it by using ./:
$ ./clang
This is not specific to clang by the way. If you type the name of any executable without a path:
$ <name_of_executable>
then the command-line interpreter will look for that executable in all the directories in the $PATH variable.
You can look at the list of these directories by entering
$ echo $PATH
And you will see something like
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
The command line interpreter will iterate through the list and will start the executable only if it's found in one of these directories.
(On Windows, the command line interpreter will also look in the current directory; this is why entering the name of the program by itself works if it is located in the current directory)
You can see where a program that can be executed without specifying the path is located by using the which command:
$ which gcc
/usr/bin/gcc
and to pay our dues to the recursive tradition of Unix:
$ which which
/usr/bin/which
This is a question on run time linking in make, in general.
I am trying to install tmux from source, on a linux system. It has dependency on "libevent" which I have installed in home dir. I am not the root on this system so I can't install it in system wide area.
DIR=$HOME/libevent
./configure --prefix=$HOME/site/tmux/ CFLAGS="-I$DIR/include" LDFLAGS="-L$DIR/lib/"
Though above command works but I need to have $HOME/libevent included in the LD_LIBRARY_PATH all the time for tmux to work. I think there should be a better way.
I need a run time linking so that I don't have to mess with LD_LIBRARY_PATH. I read here http://www.ilkda.com/compile/Environment_Variables.htm that, this can be achieved using "-R" option.
./configure --prefix=$HOME/site/tmux/ CFLAGS="-I$DIR/include" LDFLAGS="-L$DIR/lib/" LDFLAGS="-R$DIR/lib/"
But this is not working and produces the following error:
configure: error: "libevent not found"
Can someone let me know how to do run time linking in make while running configure script.
LDFLAGS="-L$DIR/lib/" LDFLAGS="-R$DIR/lib/"
The sets LDFLAGS to -L$DIR/lib/, and then immediately overrides it with -R$DIR/lib/, not unlike x = 1; x = 2; results in x == 2.
What you want is: LDFLAGS="-L$DIR/lib/ -R$DIR/lib/"
"libevent not found"
I trusted you to read the man page, but you didn't. The -R flag means RUNPATH to linker on Solaris, but it means something else to Linux linker.
What you want then is:
LDFLAGS="-L$DIR/lib/ -Wl,--rpath=$DIR/lib/"
I have been trying to install Haskell Platform and cabal-install installed on Linux in user-space on a system that doesn't have the GNU Multi-Precision package (GMP) installed.
I managed to get GHC-6.12.1 installed and GHCi working by setting up LB_LIBRARY_PATH to point at the lib directory where I installed GMP, but then ran into problems in the next step, getting cabal-install to work. It kept trying to (statically) link to GMP.
This fails because the GMP is not installed in the system and ld hasn't a clue where to find the libraries, and there is no environment variable (that I am aware of) that can tell ld where to find the user-installed GMP, and (apparently) no way of telling configuring Cabal to supply the relevant -L flag.
After much fruitless searching and hacking attempts I hit on the absurdly simple idea of installing my own ld shell script that invokes the system ld with the appropriate -L flag.
This is shell scripting 101, of course:
#!/bin/sh
/usr/bin/ld -L$HOME/gnu/lib "$#"
With this script installed in a directory on my PATH ahead of /usr/bin all the problems seem to have gone away.
Basically, your ghc is not working yet. Yes, it can compile things, but it cannot link programs because it needs to link them to gmp.
What we can do is to edit some core package, e.g. the rts package, so that ghc will always use the right -L flag:
ghc-pkg describe rts > rts.pkg
vi rts.pkg # add the gmp dir to the `library-dirs` field
sudo ghc-pkg update rts.pkg