Running gcc from prefix folder

up vote
1
down vote

favorite

I have a user account on RHEL 6.7. The built-in gcc does not support c++11, so I am trying to install my a more recent gcc. I have run configure with --prefix=$HOME/dependencies/gcc , make, make install, and updated my environment variables:

declare -x LIBRARY_PATH="~/dependencies/gcc/lib64:$LIBRARY_PATH"
declare -x PATH="~/dependencies/gcc/bin/:$PATH"

gcc -v now shows the updated version (either 4.9.4 or 5.5.0, I have tried both), and which gcc shows the expected output:

[user@host ~]$ which gcc
~/dependencies/gcc/bin/gcc

The problem is the following:

[user@host ~]$ g++ -std=c++11 -o test test.cpp
g++: error trying to exec 'cc1plus': execvp: No such file or directory
[user@host ~]$ ~/dependencies/gcc/bin/g++ -std=c++11 -o test test.cpp
[user@host ~]$

I wonder why I have to give the full path to g++ to make this work. I could not debug this with strace, since strace g++ runs the version from /usr/bin. Any ideas?

Update after adding a symlink as suggested by Knud Larsen, I ran strace strace g++55 and noticed this line:

stat("~/dependencies/gcc/bin/g++55", 0x7ffcf17f9530) = -1 ENOENT (No such file or directory)

After replacing ~ in PATH and LIBRARY_PATH with /home/user, everything works well.

edited May 8 at 17:27

asked May 8 at 14:11

LinAlg

1084

Welcome to U&L. Try to switch between the gcc versions through /usr/sbin/alternatives --config gcc
â€“Â GAD3R
May 8 at 14:28

1

@GAD3R I do not have superuser access.
â€“Â LinAlg
May 8 at 14:41

2

Suggest : symlink gcc, g++ to a new name : ln -s gcc gcc55 and ln -s g++ g++55 ... And : only use the new names in commands. Then hopefully g++55 will use the right cc1plus ... ( The symlinks can have any locatation, e.g. /home/[name]/bin/ gcc55, g++55 .) The ideal configuration for gcc would have been option --program-suffix=55. I.e. an extra gcc shoudn't be named gcc.
â€“Â Knud Larsen
May 8 at 16:53

1

@KnudLarsen I have added the symlink, but using g++55 instead of g++ gives the same error as above about cc1plus.
â€“Â LinAlg
May 8 at 17:24

2

@ajeh that would not explain why the commands work using the full path. Apparently using ~ in paths is not fully supported, see the update. I yet have to understand why, using ~ worked for me before.
â€“Â LinAlg
May 8 at 17:28

Â |Â
show 5 more comments

up vote
1
down vote

favorite

declare -x LIBRARY_PATH="~/dependencies/gcc/lib64:$LIBRARY_PATH"
declare -x PATH="~/dependencies/gcc/bin/:$PATH"

gcc -v now shows the updated version (either 4.9.4 or 5.5.0, I have tried both), and which gcc shows the expected output:

[user@host ~]$ which gcc
~/dependencies/gcc/bin/gcc

The problem is the following:

[user@host ~]$ g++ -std=c++11 -o test test.cpp
g++: error trying to exec 'cc1plus': execvp: No such file or directory
[user@host ~]$ ~/dependencies/gcc/bin/g++ -std=c++11 -o test test.cpp
[user@host ~]$

I wonder why I have to give the full path to g++ to make this work. I could not debug this with strace, since strace g++ runs the version from /usr/bin. Any ideas?

Update after adding a symlink as suggested by Knud Larsen, I ran strace strace g++55 and noticed this line:

stat("~/dependencies/gcc/bin/g++55", 0x7ffcf17f9530) = -1 ENOENT (No such file or directory)

After replacing ~ in PATH and LIBRARY_PATH with /home/user, everything works well.

edited May 8 at 17:27

asked May 8 at 14:11

LinAlg

1084

Welcome to U&L. Try to switch between the gcc versions through /usr/sbin/alternatives --config gcc
â€“Â GAD3R
May 8 at 14:28

1

@GAD3R I do not have superuser access.
â€“Â LinAlg
May 8 at 14:41

2

Suggest : symlink gcc, g++ to a new name : ln -s gcc gcc55 and ln -s g++ g++55 ... And : only use the new names in commands. Then hopefully g++55 will use the right cc1plus ... ( The symlinks can have any locatation, e.g. /home/[name]/bin/ gcc55, g++55 .) The ideal configuration for gcc would have been option --program-suffix=55. I.e. an extra gcc shoudn't be named gcc.
â€“Â Knud Larsen
May 8 at 16:53

1

@KnudLarsen I have added the symlink, but using g++55 instead of g++ gives the same error as above about cc1plus.
â€“Â LinAlg
May 8 at 17:24

2

@ajeh that would not explain why the commands work using the full path. Apparently using ~ in paths is not fully supported, see the update. I yet have to understand why, using ~ worked for me before.
â€“Â LinAlg
May 8 at 17:28

Â |Â
show 5 more comments

up vote
1
down vote

favorite

declare -x LIBRARY_PATH="~/dependencies/gcc/lib64:$LIBRARY_PATH"
declare -x PATH="~/dependencies/gcc/bin/:$PATH"

gcc -v now shows the updated version (either 4.9.4 or 5.5.0, I have tried both), and which gcc shows the expected output:

[user@host ~]$ which gcc
~/dependencies/gcc/bin/gcc

The problem is the following:

[user@host ~]$ g++ -std=c++11 -o test test.cpp
g++: error trying to exec 'cc1plus': execvp: No such file or directory
[user@host ~]$ ~/dependencies/gcc/bin/g++ -std=c++11 -o test test.cpp
[user@host ~]$

I wonder why I have to give the full path to g++ to make this work. I could not debug this with strace, since strace g++ runs the version from /usr/bin. Any ideas?

Update after adding a symlink as suggested by Knud Larsen, I ran strace strace g++55 and noticed this line:

stat("~/dependencies/gcc/bin/g++55", 0x7ffcf17f9530) = -1 ENOENT (No such file or directory)

After replacing ~ in PATH and LIBRARY_PATH with /home/user, everything works well.

edited May 8 at 17:27

asked May 8 at 14:11

LinAlg

1084

declare -x LIBRARY_PATH="~/dependencies/gcc/lib64:$LIBRARY_PATH"
declare -x PATH="~/dependencies/gcc/bin/:$PATH"

gcc -v now shows the updated version (either 4.9.4 or 5.5.0, I have tried both), and which gcc shows the expected output:

[user@host ~]$ which gcc
~/dependencies/gcc/bin/gcc

The problem is the following:

[user@host ~]$ g++ -std=c++11 -o test test.cpp
g++: error trying to exec 'cc1plus': execvp: No such file or directory
[user@host ~]$ ~/dependencies/gcc/bin/g++ -std=c++11 -o test test.cpp
[user@host ~]$

I wonder why I have to give the full path to g++ to make this work. I could not debug this with strace, since strace g++ runs the version from /usr/bin. Any ideas?

Update after adding a symlink as suggested by Knud Larsen, I ran strace strace g++55 and noticed this line:

stat("~/dependencies/gcc/bin/g++55", 0x7ffcf17f9530) = -1 ENOENT (No such file or directory)

After replacing ~ in PATH and LIBRARY_PATH with /home/user, everything works well.

edited May 8 at 17:27

asked May 8 at 14:11

LinAlg

1084

edited May 8 at 17:27

asked May 8 at 14:11

LinAlg

1084

asked May 8 at 14:11

LinAlg

1084

asked May 8 at 14:11

LinAlg

1084

Welcome to U&L. Try to switch between the gcc versions through /usr/sbin/alternatives --config gcc
â€“Â GAD3R
May 8 at 14:28

1

@GAD3R I do not have superuser access.
â€“Â LinAlg
May 8 at 14:41

2

Suggest : symlink gcc, g++ to a new name : ln -s gcc gcc55 and ln -s g++ g++55 ... And : only use the new names in commands. Then hopefully g++55 will use the right cc1plus ... ( The symlinks can have any locatation, e.g. /home/[name]/bin/ gcc55, g++55 .) The ideal configuration for gcc would have been option --program-suffix=55. I.e. an extra gcc shoudn't be named gcc.
â€“Â Knud Larsen
May 8 at 16:53

1

@KnudLarsen I have added the symlink, but using g++55 instead of g++ gives the same error as above about cc1plus.
â€“Â LinAlg
May 8 at 17:24

2

@ajeh that would not explain why the commands work using the full path. Apparently using ~ in paths is not fully supported, see the update. I yet have to understand why, using ~ worked for me before.
â€“Â LinAlg
May 8 at 17:28

Â |Â
show 5 more comments

Welcome to U&L. Try to switch between the gcc versions through /usr/sbin/alternatives --config gcc
â€“Â GAD3R
May 8 at 14:28

1

@GAD3R I do not have superuser access.
â€“Â LinAlg
May 8 at 14:41

2

Suggest : symlink gcc, g++ to a new name : ln -s gcc gcc55 and ln -s g++ g++55 ... And : only use the new names in commands. Then hopefully g++55 will use the right cc1plus ... ( The symlinks can have any locatation, e.g. /home/[name]/bin/ gcc55, g++55 .) The ideal configuration for gcc would have been option --program-suffix=55. I.e. an extra gcc shoudn't be named gcc.
â€“Â Knud Larsen
May 8 at 16:53

1

@KnudLarsen I have added the symlink, but using g++55 instead of g++ gives the same error as above about cc1plus.
â€“Â LinAlg
May 8 at 17:24

2

@ajeh that would not explain why the commands work using the full path. Apparently using ~ in paths is not fully supported, see the update. I yet have to understand why, using ~ worked for me before.
â€“Â LinAlg
May 8 at 17:28

Welcome to U&L. Try to switch between the gcc versions through /usr/sbin/alternatives --config gcc
â€“Â GAD3R
May 8 at 14:28

@GAD3R I do not have superuser access.
â€“Â LinAlg
May 8 at 14:41

Suggest : symlink gcc, g++ to a new name : ln -s gcc gcc55 and ln -s g++ g++55 ... And : only use the new names in commands. Then hopefully g++55 will use the right cc1plus ... ( The symlinks can have any locatation, e.g. /home/[name]/bin/ gcc55, g++55 .) The ideal configuration for gcc would have been option --program-suffix=55. I.e. an extra gcc shoudn't be named gcc.
â€“Â Knud Larsen
May 8 at 16:53

@KnudLarsen I have added the symlink, but using g++55 instead of g++ gives the same error as above about cc1plus.
â€“Â LinAlg
May 8 at 17:24

@ajeh that would not explain why the commands work using the full path. Apparently using ~ in paths is not fully supported, see the update. I yet have to understand why, using ~ worked for me before.
â€“Â LinAlg
May 8 at 17:28

Â |Â
show 5 more comments

1 Answer
1

active

oldest

votes

up vote
2
down vote

accepted

Tilde is not expanded when quoted. Use a real variable like $HOME instead.

See Why doesn't the tilde (~) expand inside double quotes?

Personal opinion: Use tilde freely on the command line (with the caveat that it does not expand in quotes), but use $HOME is scripts.

answered May 8 at 17:34

Kusalananda

102k13199315

Thanks, this has to be the explanation. Oddly enough, bash expands the tilde when it uses the path variable. If Bash didn't do that, the error would have been easier to spot.
â€“Â LinAlg
May 8 at 17:39

@LinAlg From the bash manual: [...] one may use filenames with tildes in assignments to PATH, MAILPATH, and CDPATH, and the shell assigns the expanded value. It expands the tilde when it finds it in those three variables, but it retains the actual tilde in their values. The manual is a bit hazy on that point.
â€“Â Kusalananda
May 8 at 17:45

add a commentÂ |Â

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f442553%2frunning-gcc-from-prefix-folder%23new-answer', 'question_page');

);

Post as a guest

Name

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

up vote
2
down vote

accepted

Tilde is not expanded when quoted. Use a real variable like $HOME instead.

See Why doesn't the tilde (~) expand inside double quotes?

Personal opinion: Use tilde freely on the command line (with the caveat that it does not expand in quotes), but use $HOME is scripts.

answered May 8 at 17:34

Kusalananda

102k13199315

Thanks, this has to be the explanation. Oddly enough, bash expands the tilde when it uses the path variable. If Bash didn't do that, the error would have been easier to spot.
â€“Â LinAlg
May 8 at 17:39

@LinAlg From the bash manual: [...] one may use filenames with tildes in assignments to PATH, MAILPATH, and CDPATH, and the shell assigns the expanded value. It expands the tilde when it finds it in those three variables, but it retains the actual tilde in their values. The manual is a bit hazy on that point.
â€“Â Kusalananda
May 8 at 17:45

add a commentÂ |Â

up vote
2
down vote

accepted

Tilde is not expanded when quoted. Use a real variable like $HOME instead.

See Why doesn't the tilde (~) expand inside double quotes?

Personal opinion: Use tilde freely on the command line (with the caveat that it does not expand in quotes), but use $HOME is scripts.

answered May 8 at 17:34

Kusalananda

102k13199315

Thanks, this has to be the explanation. Oddly enough, bash expands the tilde when it uses the path variable. If Bash didn't do that, the error would have been easier to spot.
â€“Â LinAlg
May 8 at 17:39

@LinAlg From the bash manual: [...] one may use filenames with tildes in assignments to PATH, MAILPATH, and CDPATH, and the shell assigns the expanded value. It expands the tilde when it finds it in those three variables, but it retains the actual tilde in their values. The manual is a bit hazy on that point.
â€“Â Kusalananda
May 8 at 17:45

add a commentÂ |Â

up vote
2
down vote

accepted

Tilde is not expanded when quoted. Use a real variable like $HOME instead.

See Why doesn't the tilde (~) expand inside double quotes?

Personal opinion: Use tilde freely on the command line (with the caveat that it does not expand in quotes), but use $HOME is scripts.

answered May 8 at 17:34

Kusalananda

102k13199315

Tilde is not expanded when quoted. Use a real variable like $HOME instead.

See Why doesn't the tilde (~) expand inside double quotes?

Personal opinion: Use tilde freely on the command line (with the caveat that it does not expand in quotes), but use $HOME is scripts.

answered May 8 at 17:34

Kusalananda

102k13199315

answered May 8 at 17:34

Kusalananda

102k13199315

answered May 8 at 17:34

Kusalananda

102k13199315

answered May 8 at 17:34

Kusalananda

102k13199315

Thanks, this has to be the explanation. Oddly enough, bash expands the tilde when it uses the path variable. If Bash didn't do that, the error would have been easier to spot.
â€“Â LinAlg
May 8 at 17:39

@LinAlg From the bash manual: [...] one may use filenames with tildes in assignments to PATH, MAILPATH, and CDPATH, and the shell assigns the expanded value. It expands the tilde when it finds it in those three variables, but it retains the actual tilde in their values. The manual is a bit hazy on that point.
â€“Â Kusalananda
May 8 at 17:45

add a commentÂ |Â

Thanks, this has to be the explanation. Oddly enough, bash expands the tilde when it uses the path variable. If Bash didn't do that, the error would have been easier to spot.
â€“Â LinAlg
May 8 at 17:39

@LinAlg From the bash manual: [...] one may use filenames with tildes in assignments to PATH, MAILPATH, and CDPATH, and the shell assigns the expanded value. It expands the tilde when it finds it in those three variables, but it retains the actual tilde in their values. The manual is a bit hazy on that point.
â€“Â Kusalananda
May 8 at 17:45

Thanks, this has to be the explanation. Oddly enough, bash expands the tilde when it uses the path variable. If Bash didn't do that, the error would have been easier to spot.
â€“Â LinAlg
May 8 at 17:39

@LinAlg From the bash manual: [...] one may use filenames with tildes in assignments to PATH, MAILPATH, and CDPATH, and the shell assigns the expanded value. It expands the tilde when it finds it in those three variables, but it retains the actual tilde in their values. The manual is a bit hazy on that point.
â€“Â Kusalananda
May 8 at 17:45

add a commentÂ |Â

draft saved

draft discarded

draft saved

draft discarded

Post as a guest

Name

搜尋此網誌

mjhjmtu