I have both mpich and openmpi in my Ubuntu 20.04.
$ dpkg -l | grep mpi | grep lib
...
ii libmpich-dev:amd64 3.3.2-2build1 amd64 Development files for MPICH
ii libmpich12:amd64 3.3.2-2build1 amd64 Shared libraries for MPICH
...
ii libopenmpi-dev:amd64 4.0.3-0ubuntu1 amd64 high performance message passing library -- header files
ii libopenmpi3:amd64 4.0.3-0ubuntu1 amd64 high performance message passing library -- shared library
...
ii openmpi-bin 4.0.3-0ubuntu1 amd64 high performance message passing library -- binaries
ii openmpi-common 4.0.3-0ubuntu1 all high performance message passing library -- common files
..
$ dpkg -l | grep mpich
...
ii mpich 3.3.2-2build1 amd64 Implementation of the MPI Message Passing Interface standard
The default (probably because it was installed later) appears to be mpich.
How would I change to openmpi?
I want to make sure that everything that needs to be changed actually is.
So far, I am thinking about headers, executable, libraries.
I do not know which are all directories, links, etc., that have to change.
For instance, here it is suggested cmake -DMPI_CC_COMPILER=/.../mpicc.
And it was mentioned in comments that it worked. But:
I am not sure it actually fixes all headers, etc.
I need a method that:
2.1. Works for all users in the system
2.2. Does not require those macros
2.3. Works also for other compilation methods other than cmake
As for 2.3, I tried now to configure petsc
$ ./configure --with-cc=mpicc --with-fc=mpif90 -with-cxx=mpicxx --with- make-np=10 --with-shared-libraries --download-f2cblaslapack --download-mumps --download-scalapack --with-debugging=0 COPTFLAGS="-O -O3 -march=native -mtune=native" FOPTF LAGS="-O -O3 -march=native -mtune=native" CXXOPTFLAGS="-O -O3 -march=native -mtune=native"
and I got
Your libraries are from MPICH but it appears your mpiexec is from OpenMPI
Can this be fixed with update-alternatives?
I found this, which makes me think it can, but in my system it is not correctly configured:
$ type mpiexec
mpiexec is hashed (/usr/bin/mpiexec)
$ ll /usr/bin/mpiexec
lrwxrwxrwx 1 root root 25 Jan 21 11:11 /usr/bin/mpiexec -> /etc/alternatives/mpiexec
$ ll /etc/alternatives/mpiexec
lrwxrwxrwx 1 root root 24 Jan 21 11:11 /etc/alternatives/mpiexec -> /usr/bin/mpiexec.openmpi
$ ll /usr/bin/mpiexec.openmpi
lrwxrwxrwx 1 root root 7 Apr 15 2020 /usr/bin/mpiexec.openmpi -> orterun
$ type mpirun
mpirun is /usr/bin/mpirun
$ ll /usr/bin/mpirun
lrwxrwxrwx 1 root root 24 Jan 21 11:11 /usr/bin/mpirun -> /etc/alternatives/mpirun
$ ll /etc/alternatives/mpirun
lrwxrwxrwx 1 root root 23 Jan 21 11:11 /etc/alternatives/mpirun -> /usr/bin/mpirun.openmpi
$ ll /usr/bin/mpirun.openmpi
lrwxrwxrwx 1 root root 7 Apr 15 2020 /usr/bin/mpirun.openmpi -> orterun
$ type mpicc
mpicc is hashed (/usr/bin/mpicc)
$ ll /usr/bin/mpicc
lrwxrwxrwx 1 root root 21 Feb 25 18:54 /usr/bin/mpicc -> /etc/alternatives/mpi
$ ll /etc/alternatives/mpi
lrwxrwxrwx 1 root root 20 Feb 25 18:54 /etc/alternatives/mpi -> /usr/bin/mpicc.mpich
Related
Replace MPICH Installation by OpenMPI
CMake : Selecting mpich over openmpi
https://unix.stackexchange.com/questions/413099/flip-between-openmpi-and-mpich-as-default-using-linux-terminal
Difference between mpi and mpich2 folder?
CMake : Selecting mpich over openmpi
Switch from MPICH to OpenMPI
This? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896189
This? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912437
https://unix.stackexchange.com/questions/81992/better-way-to-add-alternative-using-update-alternatives
https://askubuntu.com/questions/964600/how-to-add-slave-to-existing-update-alternatives-link-group
It seems all alternatives, except for one (link group mpi), were already set for openmpi
$ update-alternatives --get-selections | grep mpi
h5pcc auto /usr/bin/h5pcc.openmpi
mpi auto /usr/bin/mpicc.mpich
mpi-x86_64-linux-gnu auto /usr/lib/x86_64-linux-gnu/openmpi/include
mpirun auto /usr/bin/mpirun.openmpi
To set link group mpi properly (and avoiding error-prone individual link operations)
sudo apt-get install --reinstall openmpi-bin
(the package owning mpicc.openmpi).
This apparently fixed everything.
So far it is working fine.
"Historical" note:
I had found that (strangely) mpicc.openmpi was not in update-alternatives, as opposed to the other 3 link groups
$ update-alternatives --list mpirun
/usr/bin/mpirun.mpich
/usr/bin/mpirun.openmpi
$ update-alternatives --list h5pcc
/usr/bin/h5pcc.mpich
/usr/bin/h5pcc.openmpi
$ update-alternatives --list mpi-x86_64-linux-gnu
/usr/include/x86_64-linux-gnu/mpich
/usr/lib/x86_64-linux-gnu/openmpi/include
$ update-alternatives --list mpi
/usr/bin/mpicc.mpich
even if it was installed in my system
$ ll /usr/bin/mpicc*
lrwxrwxrwx 1 root root 21 Feb 25 18:54 /usr/bin/mpicc -> /etc/alternatives/mpi
-rwxr-xr-x 1 root root 11K Mar 22 2020 /usr/bin/mpicc.mpich
lrwxrwxrwx 1 root root 12 Apr 15 2020 /usr/bin/mpicc.openmpi -> opal_wrapper
Why would it not be in the first place? I still don't know.
I decided to go with the reinstall, since handling the link group manually might have been a mess
$ update-alternatives --query mpi
Name: mpi
Link: /usr/bin/mpicc
Slaves:
mpiCC /usr/bin/mpiCC
mpiCC.1.gz /usr/share/man/man1/mpiCC.1.gz
mpic++ /usr/bin/mpic++
mpic++.1.gz /usr/share/man/man1/mpic++.1.gz
mpicc.1.gz /usr/share/man/man1/mpicc.1.gz
mpicxx /usr/bin/mpicxx
mpicxx.1.gz /usr/share/man/man1/mpicxx.1.gz
mpif77 /usr/bin/mpif77
mpif77.1.gz /usr/share/man/man1/mpif77.1.gz
mpif90 /usr/bin/mpif90
mpif90.1.gz /usr/share/man/man1/mpif90.1.gz
mpifort /usr/bin/mpifort
mpifort.1.gz /usr/share/man/man1/mpifort.1.gz
Status: auto
Best: /usr/bin/mpicc.mpich
Value: /usr/bin/mpicc.mpich
Alternative: /usr/bin/mpicc.mpich
Priority: 40
Slaves:
mpiCC /usr/bin/mpicxx.mpich
mpiCC.1.gz /usr/share/man/man1/mpicxx.mpich.1.gz
mpic++ /usr/bin/mpicxx.mpich
mpic++.1.gz /usr/share/man/man1/mpicxx.mpich.1.gz
mpicc.1.gz /usr/share/man/man1/mpicc.mpich.1.gz
mpicxx /usr/bin/mpicxx.mpich
mpicxx.1.gz /usr/share/man/man1/mpicxx.mpich.1.gz
mpif77 /usr/bin/mpifort.mpich
mpif77.1.gz /usr/share/man/man1/mpif77.mpich.1.gz
mpif90 /usr/bin/mpifort.mpich
mpif90.1.gz /usr/share/man/man1/mpif90.mpich.1.gz
mpifort /usr/bin/mpifort.mpich
mpifort.1.gz /usr/share/man/man1/mpifort.mpich.1.gz
Related
The main problem is that I wrote a security sensitive statement on MariaDB (among many other statements), so I would like to remove the prompt history (like the command history -c on Linux):
jordiba90#lts:~$ sudo mariadb -u root -p
[sudo] contraseña para jordiba90:
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 36
Server version: 10.3.25-MariaDB-0ubuntu0.20.04.1 Ubuntu 20.04
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> USE mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [mysql]> UPDATE user SET password=PASSWORD("PASSWORD") WHERE user="root";
Query OK, 0 rows affected (0.001 sec)
Rows matched: 1 Changed: 0 Warnings: 0
MariaDB [mysql]> FLUSH privileges;
Query OK, 0 rows affected (0.001 sec)
So, when I click the up&down buttons on my keyboard I see all the prompt history.
When I try to remove the prompt history on MariaDB, it does not work:
MariaDB [(none)]> clear
MariaDB [(none)]> \c
MariaDB [(none)]> quit
Bye
So, I have checked on the internet this script (that does not work either):
jordiba90#lts:~$ rm ~/.mysql_history
jordiba90#lts:~$ export MYSQL_HISTFILE=/dev/null
jordiba90#lts:~$ set | grep MYSQ
MYSQL_HISTFILE=/dev/null
_=MYSQL_HISTFILE=/dev/null
REFERENCE > https://www.thegeekstuff.com/2010/01/disable-mysql-history-clear-mysql_history-and-mysql_histfile/
After that, I have also checked on the internet another script (that does not work either, again):
jordiba90#lts:~$ ~/.mysql_history
bash: /home/jordiba90/.mysql_history: No existe el archivo o el directorio
jordiba90#lts:~$ rm $HOME/.mysql_history
rm: no se puede borrar '/home/jordiba90/.mysql_history': No existe el archivo o el directorio
jordiba90#lts:~$ ln -s /dev/null $HOME/.mysql_history
REFERENCE > https://www.cyberciti.biz/faq/howto-clear-mysql-command-history/
One the one hand, there are too many files on my OS related to "mysql" but none related to mysql history, so I have checked one by one all the files related to mysql configuration and I did not find the one I should remove:
jordiba90#lts:~$ locate mysql | wc
421 421 25918
jordiba90#lts:~$ locate mysql | grep history
jordiba90#lts:~$ locate mysql | grep conf
/etc/mysql/conf.d
/etc/mysql/conf.d/mysql.cnf
/etc/mysql/conf.d/mysqldump.cnf
/etc/mysql/mariadb.conf.d
/etc/mysql/mariadb.conf.d/50-client.cnf
/etc/mysql/mariadb.conf.d/50-mysql-clients.cnf
/etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf
/etc/mysql/mariadb.conf.d/50-server.cnf
/usr/share/mysql-common/configure-symlinks
/usr/share/mysql/systemd/use_galera_new_cluster.conf
/var/lib/dpkg/info/mysql-common.conffiles
One the other hand, the same happens with the mariadb files:
jordiba90#lts:~$ locate mariadb | wc
101 101 5042
jordiba90#lts:~$ locate mariadb | grep history
jordiba90#lts:~$ locate mariadb | grep conf
/etc/insserv.conf.d/mariadb
/etc/mysql/mariadb.conf.d
/etc/mysql/mariadb.conf.d/50-client.cnf
/etc/mysql/mariadb.conf.d/50-mysql-clients.cnf
/etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf
/etc/mysql/mariadb.conf.d/50-server.cnf
/usr/lib/systemd/system/mariadb#bootstrap.service.d/use_galera_new_cluster.conf
/var/lib/dpkg/info/mariadb-client-10.3.conffiles
/var/lib/dpkg/info/mariadb-common.conffiles
/var/lib/dpkg/info/mariadb-server-10.3.conffiles
/var/lib/dpkg/info/mariadb-server-10.3.config
Could you please give me a hint? You can check that I have tried it. Thanks in advance.
PS_1: if there is any other entry about this topic on Stack* (I have checked it and I did not see one) or if my entry breaks any rule on Stack* (I have checked the rules and I think I do not break any), please send me a PM and I will delete this entry. I am trying to learn without losing reputation points for asking a question.
PS_2: I have restarted mysql and right now the status is active (running):
jordiba90#lts:~$ sudo /etc/init.d/mysql restart
Restarting mysql (via systemctl): mysql.service.
jordiba90#lts:~$ sudo /etc/init.d/mysql status
● mariadb.service - MariaDB 10.3.25 database server
Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2020-11-14 13:24:47 CET; 8h ago
Docs: man:mysqld(8)
https://mariadb.com/kb/en/library/systemd/
Process: 826 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
Process: 861 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 876 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
Process: 1026 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 1028 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
Main PID: 957 (mysqld)
Status: "Taking your SQL requests now..."
Tasks: 31 (limit: 9423)
Memory: 93.1M
CGroup: /system.slice/mariadb.service
└─957 /usr/sbin/mysqld
nov 14 13:24:46 lts systemd[1]: Starting MariaDB 10.3.25 database server...
nov 14 13:24:47 lts mysqld[957]: 2020-11-14 13:24:47 0 [Note] /usr/sbin/mysqld (mysqld 10.3.25-MariaDB-0ubuntu0.20.04.1) starting as…ess 957 ...
nov 14 13:24:47 lts mysqld[957]: 2020-11-14 13:24:47 0 [Warning] Could not increase number of max_open_files to more than 16384 (request: 32186)
nov 14 13:24:47 lts systemd[1]: Started MariaDB 10.3.25 database server.
nov 14 13:24:47 lts /etc/mysql/debian-start[1030]: Upgrading MySQL tables if necessary.
nov 14 13:24:47 lts /etc/mysql/debian-start[1033]: Looking for 'mysql' as: /usr/bin/mysql
nov 14 13:24:47 lts /etc/mysql/debian-start[1033]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
nov 14 13:24:47 lts /etc/mysql/debian-start[1033]: This installation of MySQL is already upgraded to 10.3.25-MariaDB, use --force if y…l_upgrade
Hint: Some lines were ellipsized, use -l to show in full.
REFERENCE > https://superuser.com/questions/282115/how-to-restart-mysql
PS_3: I have tried the command stat ~/.mysql_history; rm ~/.mysql_history; stat ~/.mysql_history and the output that I have is that the file or the directory /home/jordiba90/.mysql_history does not exist
PS_4: I have tried the command strace mysql and I can not share here the output because there is a message body limit to 30.000 characters (and if I do that, I should have entered 44.321, aprox)
PS_5: Having checked the specific output openat(AT_FDCWD..., there is none related to mysql_history. It does not appear that specific sentence
PS_6: I have used 'sudo' to try the command 'strace mysql'and I have got the following output related to mysql history:
openat(AT_FDCWD, "/root/.mysql_history", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0600, st_size=4585, ...}) = 0
read(4, "misql -u root -p\nDatascience2005"..., 4585) = 4585
close(4) = 0
write(1, "\33(B\33[m\33(B\33[0;1mType 'help;' or '"..., 94Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
) = 94
write(1, "\n", 1
)
PS_7: I have removed the last directory related to mysql history named /root/.mysql_history but I still see the history on the mariadb prompt
Editing the history file (for example with vim, and deleting the problematic lines) worked in my case:
vim ~/.mysql_history
(mysql Ver 15.1 Distrib 10.4.14-MariaDB)
Depending on how you are set up, you'll probably find it is located at root. I had the same on a new secured install of MariaDB on Ubuntu 22.04. Mine was located at /root/.mysql_history
I found it the usual way by using the excellent locate command (remember to use the updatedb command to update the database of any new files that have been added) and searching for mysql_history:
locate -i mysql_history
Do this search at the bash (or whatever you are using) command prompt as you are searching for a file in the file system, not in the MariaDB or MySQL shell itself.
On this search, there is no actual need for the -i option as mysql_history is lowercase, but you never know!
Searching for history will also work but you'll get a few more hits.
Once you have found the file, you can use the editor of your choice to remove any sensitive command lines that may have found their way in there.
I'm attempting to build a package and install R packages that use Rccp. These are failing because files in /tmp are not executable.
These problems arose after switching to a new Dell xps 13 pre-installed with Ubuntu 18.04. For the build, I've been using pkgbuild::compile_dll to compile some C code with Rccp. I only found out about the problem installing new packages while troubleshooting the problem with compile_dll. This confirmed that its not a problem with pkgbuild.
Here is the error message from compile_dll:
> pkgbuild::compile_dll()
Registered S3 methods overwritten by 'ggplot2':
method from
[.quosures rlang
c.quosures rlang
print.quosures rlang
Re-compiling spstan
─ installing *source* package ‘spstan’ ...
** using staged installation
ERROR: 'configure' exists but is not executable -- see the 'R
Installation and Administration Manual'
─ removing
‘/home/connor/tmp/RtmpC0EMxX/devtools_install_570e38f2a7e3/spstan’
Error in (function (command = NULL, args = character(),
error_on_status = TRUE, :
System command error
There's plenty of help out there for this it seems, except that none of the solutions are working for me. Here is what I've tried.
Remount /tmp as in
https://github.com/r-lib/devtools/issues/32
Remount /tmp and enable executable files be entering the following in the terminal:
sudo mount -o remount,exec /tmp
Which gives the following error message: mount point not mounted or bad option. Since /tmp isn't mounted separately on my computer, its part of the root filesystem, the above solution fails because /tmp can't be remounted.
Following the instructions from the R Installation and Administration Manual, make sure TMPDIR points to some temporary file system in which scripts are allowed to be executed. So I made a new tmp folder called ~/Rtmp and mounted it:
mkdir ~/Rtmp
mount -t tmpfs -o exec ~/Rtmp
Also adding the following line to my ~/.Renviron file:
TMPDIR=/home/connor/Rtmp
and adding the following line to /etc/fstab:
tmpfs /home/connor/Rtmp tmpfs exec 0 0
and then rebooting the computer before running pkgbuild::compile_dll() again. I get the same error message but I could confirm that R was using /Rtmp folder I directed it to.
Following some advice here https://ubuntuforums.org/showthread.php?t=2421441 change permissions on the /tmp folder recursively with
sudo chmod -R 777 ~/tmp
This also fails. The problem seems to be that compile_dll is creating a new script that it wants to run and the permissions on the folder aren't the default for new files that get added to it.
When I print out the permissions for /tmp, the script that is failing with compile_dll is listed without the same permissions as all the older files:
drwx------ 3 connor connor 4096 Jun 23 15:20 RtmpC0EMxX
drwxrwxrwx 9 root root 4096 Jun 23 09:53 RtmpGb3QiA
drwxrwxrwx 3 connor connor 4096 Jun 23 10:44 RtmpI9hu1U
drwxrwxrwx 2 connor connor 4096 Jun 23 10:41 RtmpIgi5su
drwxrwxrwx 2 connor connor 4096 Jun 23 10:07 RtmpK4p4Od
drwxrwxrwx 4 root root 4096 Jun 23 09:17 RtmppdbqeT
drwxrwxrwx 10 root root 4096 Jun 23 09:54 RtmpR4Cc9c
drwxrwxrwx 14 root root 4096 Jun 23 10:13 Rtmpuweyxz
drwxrwxrwx 2 connor connor 4096 Jun 23 10:07 RtmpwN9SbT
drwxrwxrwx 2 connor connor 4096 Jun 23 10:04 RtmpY7g0NK
So I'm still stuck. Am I doing something wrong here? Or do I need to start looking somewhere else for the source of the problem?
Is it possible to have multiple gcc versions installed on a unix system? If yes, how to find which all versions are installed? Also, is it possible to specify at runtime which gcc version to use?
Here's a step by step that works on Linux, and will probably work on unix.
First verify you have a gcc available:
greg#greg-mint ~ $ gcc
gcc: fatal error: no input files
compilation terminated.
Yep. Didn't like the fact I didn't supply anything to compile.
If you get something like no command gcc found or command or file not recognised: gcc then you might have a problem.
Now, find where that gcc is:
greg#greg-mint ~ $ which gcc
/usr/bin/gcc
Great. It's in /usr/bin/gcc but that's not telling us about alternative versions.
Let's find out a bit about that:
greg#greg-mint ~ $ ls -l /usr/bin/gcc
lrwxrwxrwx 1 root root 7 Mar 28 2013 /usr/bin/gcc -> gcc-4.7
On my machine (Linux Mint) that' show it shows a symbolic link. What it means is that when I run the gcc command it's running /usr/bin/gcc-4.7
Ok. I'm guessing it's usually in /usr/bin, so, lets see if there are any others:
greg#greg-mint ~ $ ls -l /usr/bin/gcc*
lrwxrwxrwx 1 root root 7 Mar 28 2013 /usr/bin/gcc -> gcc-4.7
-rwxr-xr-x 1 root root 275952 Jul 3 2012 /usr/bin/gcc-4.5
-rwxr-xr-x 1 root root 578808 Sep 22 2012 /usr/bin/gcc-4.7
-rwxr-xr-x 1 root root 22832 Sep 22 2012 /usr/bin/gcc-ar-4.7
-rwxr-xr-x 1 root root 22832 Sep 22 2012 /usr/bin/gcc-nm-4.7
-rwxr-xr-x 1 root root 22832 Sep 22 2012 /usr/bin/gcc-ranlib-4.7
-rwxr-xr-x 1 root root 220968 Oct 9 2012 /usr/bin/gccxml
-rwxr-xr-x 1 root root 8606464 Oct 9 2012 /usr/bin/gccxml_cc1plus
So it turns out I have gcc version 4.7 and 4.5 on my machine. I don't know what the other ones are.
You can specify the version number by sending the full path:
greg#greg-mint ~ $ gcc --version
gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
Copyright (C) 2012 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.
greg#greg-mint ~ $ /usr/bin/gcc-4.5 --version
gcc-4.5 (Ubuntu/Linaro 4.5.4-1ubuntu2) 4.5.4
Copyright (C) 2010 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.
greg#greg-mint ~ $ /usr/bin/gcc-4.7 --version
gcc-4.7 (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
Copyright (C) 2012 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.
An alternative, and I recommend that you DO NOT do this, is to use find. (be warned: on a shared machine it's not necessarily good manners).
find / -name "gcc*"
This will look for all files that start with gcc on your machine. It's going to scan the entire disk, so it will take a while, and you'll be affecting performance for all the other users on your system (which given you've said 'unix' and 'University Server' may come with an impact).
Yes, it is fairly common to have multiple versions of gcc installed, usually named gcc-version. For example, on my machine, I have gcc-4.4, gcc-4.5, and gcc-4.6. You can usually see what versions you have installed by typing gcc-tab -- using the shell's autocomplete to tell you which versions are available.
my os is debian6,there is a libR.pc after i compile to install R
root#debian:/home/tiger# cat /home/tiger/R-2.15.1/lib/pkgconfig/libR.pc
rhome=/home/tiger/R-2.15.1/lib/R
rlibdir=${rhome}/lib
rincludedir=/home/tiger/R-2.15.1/lib/R/include
Name: libR
Description: R as a library
Version: 2.15.1
Libs: -L${rlibdir} -lR
Cflags: -I${rincludedir} -I${rincludedir}
Libs.private:
when set R environment in /etc/profile:
R_HOME= /home/tiger/R-2.15.1
or
R_HOME= /home/tiger/R-2.15.1/lib/R
which line will i choose to write in /etc/profile?
On a Debian (or derivative such as Ubuntu system) you have /etc/R/ to set variable which R uses:
edd#max:~$ ls -l /etc/R/
total 28
-rw-r--r-- 1 root root 602 Jun 17 20:29 ldpaths
-rw-r--r-- 1 root root 5461 Jun 17 20:29 Makeconf
-rw-r--r-- 1 root root 1868 Mar 31 13:50 Renviron
-rw-r--r-- 1 root root 608 Sep 25 2009 Renviron.site
-rw-r--r-- 1 root root 1159 Mar 31 08:03 repositories
-rw-r--r-- 1 root root 792 Oct 28 2009 Rprofile.site
edd#max:~$
and the files in R_HOME/etc/ should be softlinks --- at least if you use the prebuilt binaries. If you build you own binaries, it's your problem.
The file you quote is installed as /usr/lib/pkgconfig/libR.pc on a Debian / Ubuntu system. Setting R_HOME is not needed as R finds its own values (see #flodel's answer).
On my system:
cat $R_HOME
gives nothing, but inside an R session, I get:
> Sys.getenv("R_HOME")
[1] "/usr/lib/R"
This should tell you two things:
that R_HOME is set at R's startup, so unless you know exactly what you are doing, maybe you don't need to set it up in your /etc/profile.
you can use Sys.getenv to find out the exact path to your R_HOME.
Does any operating system provide a mechanism (system call — not command line program) to change the pathname referenced by a symbolic link (symlink) — other than by unlinking the old one and creating a new one?
The POSIX standard does not. Solaris 10 does not. MacOS X 10.5 (Leopard) does not. (I'm tolerably certain neither AIX nor HP-UX does either. Judging from this list of Linux system calls, Linux does not have such a system call either.)
Is there anything that does?
(I'm expecting that the answer is "No".)
Since proving a negative is hard, let's reorganize the question.
If you know that some (Unix-like) operating system not already listed has no system call for rewriting the value of a symlink (the string returned by readlink()) without removing the old symlink and creating a new one, please add it — or them — in an answer.
Yes, you can!
$ ln -sfn source_file_or_directory_name softlink_name
AFAIK, no, you can't. You have to remove it and recreate it. Actually, you can overwrite a symlink and thus update the pathname referenced by it:
$ ln -s .bashrc test
$ ls -al test
lrwxrwxrwx 1 pascal pascal 7 2009-09-23 17:12 test -> .bashrc
$ ln -s .profile test
ln: creating symbolic link `test': File exists
$ ln -s -f .profile test
$ ls -al test
lrwxrwxrwx 1 pascal pascal 8 2009-09-23 17:12 test -> .profile
EDIT: As the OP pointed out in a comment, using the --force option will make ln perform a system call to unlink() before symlink(). Below, the output of strace on my linux box proving it:
$ strace -o /tmp/output.txt ln -s -f .bash_aliases test
$ grep -C3 ^unlink /tmp/output.txt
lstat64("test", {st_mode=S_IFLNK|0777, st_size=7, ...}) = 0
stat64(".bash_aliases", {st_mode=S_IFREG|0644, st_size=2043, ...}) = 0
symlink(".bash_aliases", "test") = -1 EEXIST (File exists)
unlink("test") = 0
symlink(".bash_aliases", "test") = 0
close(0) = 0
close(1) = 0
So I guess the final answer is "no".
EDIT: The following is copied from Arto Bendiken's answer over on unix.stackexchange.com, circa 2016.
This can indeed be done atomically with rename(2), by first creating the new symlink under a temporary name and then cleanly overwriting the old symlink in one go. As the man page states:
If newpath refers to a symbolic link the link will be overwritten.
In the shell, you would do this with mv -T as follows:
$ mkdir a b
$ ln -s a z
$ ln -s b z.new
$ mv -T z.new z
You can strace that last command to make sure it is indeed using rename(2) under the hood:
$ strace mv -T z.new z
lstat64("z.new", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
lstat64("z", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
rename("z.new", "z") = 0
Note that in the above, both mv -T and strace are Linux-specific.
On FreeBSD, use mv -h alternately.
Editor's note: This is how Capistrano has done it for years now, ever since ~2.15. See this pull request.
It is not necessary to explicitly unlink the old symlink. You can do this:
ln -s newtarget temp
mv temp mylink
(or use the equivalent symlink and rename calls). This is better than explicitly unlinking because rename is atomic, so you can be assured that the link will always point to either the old or new target. However this will not reuse the original inode.
On some filesystems, the target of the symlink is stored in the inode itself (in place of the block list) if it is short enough; this is determined at the time it is created.
Regarding the assertion that the actual owner and group are immaterial, symlink(7) on Linux says that there is a case where it is significant:
The owner and group of an existing symbolic link can be changed using
lchown(2). The only time that the ownership of a symbolic link matters is
when the link is being removed or renamed in a directory that has the sticky
bit set (see stat(2)).
The last access and last modification timestamps of a symbolic link can be
changed using utimensat(2) or lutimes(3).
On Linux, the permissions of a symbolic link are not used in any operations;
the permissions are always 0777 (read, write, and execute for all user
categories), and can't be changed.
Just a warning to the correct answers above:
Using the -f / --force Method provides a risk to lose the file if you mix up source and target:
mbucher#server2:~/test$ ls -la
total 11448
drwxr-xr-x 2 mbucher www-data 4096 May 25 15:27 .
drwxr-xr-x 18 mbucher www-data 4096 May 25 15:13 ..
-rw-r--r-- 1 mbucher www-data 4109466 May 25 15:26 data.tar.gz
-rw-r--r-- 1 mbucher www-data 7582480 May 25 15:27 otherdata.tar.gz
lrwxrwxrwx 1 mbucher www-data 11 May 25 15:26 thesymlink -> data.tar.gz
mbucher#server2:~/test$
mbucher#server2:~/test$ ln -s -f thesymlink otherdata.tar.gz
mbucher#server2:~/test$
mbucher#server2:~/test$ ls -la
total 4028
drwxr-xr-x 2 mbucher www-data 4096 May 25 15:28 .
drwxr-xr-x 18 mbucher www-data 4096 May 25 15:13 ..
-rw-r--r-- 1 mbucher www-data 4109466 May 25 15:26 data.tar.gz
lrwxrwxrwx 1 mbucher www-data 10 May 25 15:28 otherdata.tar.gz -> thesymlink
lrwxrwxrwx 1 mbucher www-data 11 May 25 15:26 thesymlink -> data.tar.gz
Of course this is intended, but usually mistakes occur. So, deleting and rebuilding the symlink is a bit more work but also a bit saver:
mbucher#server2:~/test$ rm thesymlink && ln -s thesymlink otherdata.tar.gz
ln: creating symbolic link `otherdata.tar.gz': File exists
which at least keeps my file.
Wouldn't unlinking it and creating the new one do the same thing in the end anyway?
Just in case it helps: there is a way to edit a symlink with midnight commander (mc).
The menu command is (in French on my mc interface):
Fichier / Éditer le lien symbolique
which may be translated to:
File / Edit symbolic link
The shortcut is C-x C-s
Maybe it internally uses the ln --force command, I don't know.
Now, I'm trying to find a way to edit a whole lot of symlinks at once (that's how I arrived here).
Technically, there's no built-in command to edit an existing symbolic link. It can be easily achieved with a few short commands.
Here's a little bash/zsh function I wrote to update an existing symbolic link:
# -----------------------------------------
# Edit an existing symbolic link
#
# #1 = Name of symbolic link to edit
# #2 = Full destination path to update existing symlink with
# -----------------------------------------
function edit-symlink () {
if [ -z "$1" ]; then
echo "Name of symbolic link you would like to edit:"
read LINK
else
LINK="$1"
fi
LINKTMP="$LINK-tmp"
if [ -z "$2" ]; then
echo "Full destination path to update existing symlink with:"
read DEST
else
DEST="$2"
fi
ln -s $DEST $LINKTMP
rm $LINK
mv $LINKTMP $LINK
printf "Updated $LINK to point to new destination -> $DEST"
}
You can modify the softlink created once in one of the two ways as below in Linux
one is where you can remove existing softlink with rm and again create new softlink with ln -s command .
However this can be done in one step , you can replace existing softlink with updated path with "ln -vfns Source_path Destination_path" command.
Listing initial all files in directory
$ ls -lrt
drwxrwxr-x. 3 root root 110 Feb 27 18:58 test_script
$
Create softlink test for test_script with ln -s command.
$ ln -s test_script test
$ ls -lrt
drwxrwxr-x. 3 root root 110 Feb 27 18:58 test_script
lrwxrwxrwx. 1 root root 11 Feb 27 18:58 test -> test_script
$
Update softlink test with new directory test_script/softlink with single command
$ ln -vfns test_script/softlink/ test
'test' -> 'test_script/softlink/'
$
List new softlink location
$ ls -lrt
lrwxrwxrwx. 1 root root 21 Feb 27 18:59 test -> test_script/softlink/
$
ln --help
-v, --verbose print name of each linked file
-f, --force remove existing destination files
-n, --no-dereference treat LINK_NAME as a normal file if it is a symbol
-s, --symbolic make symbolic links instead of hard links