Could anyone tell me what I'm doing wrong here? I'm still using suse 7.2 and recently I tried installing an application that I think needs a more recent library that comes with the c compiler. So, I got gcc-3.2.tar.gz, putting it into /root/downloads/gcc uncompressing it created: /root/downloads/gcc/gcc-3.2 I made /root/downloads/gcc/objdir and from there did /root/downloads/gcc/gcc-3.2/configure followed by make bootstrap It took almost 12 hours to compile! Then I did make install Now, gcc -v is reporting different versions, depending who I am! If I log on as root, gcc -v reports 3.2 If I log on as an ordinary user and then su to root, gcc -v reports 2.95.3 , reading specs from a different place. Could anyone advise? thanks Richard -- richard@tortoise.demon.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Monday 21 July 2003 20:25, richard@tortoise.demon.co.uk wrote:
I'm still using suse 7.2 and recently I tried installing an application that I think needs a more recent library that comes with the c compiler.
This sounds very unlikely. What library? What error do you get otherwise?
Now, gcc -v is reporting different versions, depending who I am!
If I log on as root, gcc -v reports 3.2
If I log on as an ordinary user and then su to root, gcc -v reports 2.95.3 , reading specs from a different place.
That's simply because you have a different $PATH variable depending on whether you are root or as a normal user. As your normal user, put the directory of the gcc binary as the first value in PATH. As root find out which it is by doing 'which gcc' then do something like this: galadriel:/home/chris # which gcc /usr/bin/gcc galadriel:/home/chris # su chris chris@galadriel:~> export PATH=/usr/bin:$PATH You'll probably want to make changes to /etc/profile to make it permanent. - -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP ID: 33795A2C KDE/Qt/C++/PHP Developer: http://www.kde.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE/HDlJF8Iu1zN5WiwRAprQAJ9TSbTKHnb2GnrDpErJYPobYUZQBACfT7iM GiZh+48FsfrBIvvWiHwBIxI= =P25i -----END PGP SIGNATURE-----
Chris,
This sounds very unlikely. What library? What error do you get otherwise?
The application is the Firebird database server. Here is the type of error I get, when trying to start one of its tools: /usr/local/firebird//bin/isql: /usr/local/lib/libstdc++.so.5: no version information available (required by /usr/lib/libfbembed.so.1) regards Richard -- richard@tortoise.demon.co.uk
Thanks for the replies, I think I've got the path issue understood now. I was unaware that if you su to root, you get a path (compiled into the kernel?) that it seems you cant edit. su - on the other hand executes /root/.profile regards Richard-- richard@tortoise.demon.co.uk
--- richard@tortoise.demon.co.uk wrote:
Thanks for the replies,
:)
I think I've got the path issue understood now.
I was unaware that if you su to root, you get a path (compiled into the kernel?) that it seems you cant edit.
Umm, no. $PATH is an exported shell variable that is in no way related to the kernel whatsoever. Of course one can edit $PATH, i.e. export $PATH:/usr/local/bin/bin
su - on the other hand executes /root/.profile
Yes, and more importantly "su -" creates a login shell which changes your effective UID/GID. "su" on its own like that does not and hence $PATH is not affected. HTH, -- Thomas Adam ===== Thomas Adam "The Linux Weekend Mechanic" -- www.linuxgazette.com ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Wednesday 23 July 2003 00:24, richard@tortoise.demon.co.uk wrote:
I was unaware that if you su to root, you get a path (compiled into the kernel?)
No, it's set in /etc/profile.
that it seems you cant edit.
There's something wrong if you can't edit it. - -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP ID: 33795A2C KDE/Qt/C++/PHP Developer: http://www.kde.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE/Hkz3F8Iu1zN5WiwRAkQAAJ9GF5mrv+WVHZr+heuo0UAyJCfzoQCcDn30 3CLVSo0+aUCw3tAWLtT/G2c= =Dwpf -----END PGP SIGNATURE-----
Hi Chris, I'd read the info on su at for example: http://www.icewalkers.com/Linux/Howto/mini/Path-7.html and other places. Obviously I've not understood it.
On Wednesday 23 July 2003 00:24, richard@tortoise.demon.co.uk wrote:
I was unaware that if you su to root, you get a path (compiled into the kernel?)
No, it's set in /etc/profile.
that it seems you cant edit.
There's something wrong if you can't edit it.
If I log on as root, then echo $PATH shows lots of directorys. /root/.profile has nothing in it to modify roots path, so I assume the path is defined fully in /etc/profile If I log in as user1 and su to root (not su - ) then echo $PATH gives only: /usr/sbin:/bin:/usr/bin:/sbin:/usr/X11R6/bin which is neither the path for user1 nor that had I logged in directly as root. So where does this path come from? I don't think /etc/profile is executed if I su to root. If I put something like echo "here we are in /etc/profile" at the start of it, I never see the echo when I su regards Richard-- richard@tortoise.demon.co.uk
--- richard@tortoise.demon.co.uk wrote:
Hi Chris,
I'd read the info on su at for example: http://www.icewalkers.com/Linux/Howto/mini/Path-7.html and other places.
Obviously I've not understood it.
On Wednesday 23 July 2003 00:24, richard@tortoise.demon.co.uk wrote:
I was unaware that if you su to root, you get a path (compiled into the kernel?)
No, it's set in /etc/profile.
that it seems you cant edit.
There's something wrong if you can't edit it.
If I log on as root, then echo $PATH shows lots of directorys. /root/.profile has nothing in it to modify roots path, so I assume the path is defined fully in /etc/profile
Yes, you're right. If you take a look at the file, you'll probably see something like: [ $(id -u) = "0" ] && { $PATH=/usr/bin:/usr/local/bin } || $PATH=/some/other/location export $PATH
If I log in as user1 and su to root (not su - ) then echo $PATH gives only:
/usr/sbin:/bin:/usr/bin:/sbin:/usr/X11R6/bin
which is neither the path for user1 nor that had I logged in directly as root.
So where does this path come from?
As I have said before "su -" gives a login shell, which means that /etc/profile, /etc/profile.local, ~/.profile are all sourced, should they exist and thus modify certain environment variables. I am telling you that /etc/profile in this instance *is* sourced when "su -" is given.
I don't think /etc/profile is executed if I su to root. If I put something like echo "here we are in /etc/profile" at the start of it, I never see the echo when I su
Of course not. I am taking that last sentence literally when you say "su" and not "su -". If you just "su", then yes, you will get to be user "root", but all that has done is to change your effective $UID and $GID. NO environment variables are modified with a plain "su". You should also notice that if you say "cd /home/some/user" and then "su root", the $(pwd) does not change, whereas if you "su -" then $(pwd) = /root. This is evident of a login shell and all the /etc/bashrc, ~/.bashrc, /etc/profile, etc files being sourced. HTH, -- Thomas Adam ===== Thomas Adam "The Linux Weekend Mechanic" -- www.linuxgazette.com ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
Hi Thomas, could you bear with me on this?
I don't think /etc/profile is executed if I su to root. If I put something like echo "here we are in /etc/profile" at the start of it, I never see the echo when I su
Of course not. I am taking that last sentence literally when you say "su" and not "su -". If you just "su", then yes, you will get to be user "root", but all that has done is to change your effective $UID and $GID. NO environment variables are modified with a plain "su".
Ok, so no environment variables are modified. $PATH is an environmental variable. richard@linux:~ > echo $PATH /usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/lib/java/bin:/var/lib /dosemu:/usr/games/bin:/usr/games:/opt/gnome/bin:/opt/kde2/bin:/opt/kd e/bin:/usr/openwin/bin:.:/opt/gnome/bin:/opt/pilotsdk/bin richard@linux:~ > su Password: root@linux:/home/richard > echo $PATH /usr/sbin:/bin:/usr/bin:/sbin:/usr/X11R6/bin So a plain su HAS modified an environmental variable. PATH wasn't constructed after su within /etc/profile because /etc/profile wasn't run. So the question remains, where does the new path come from? I'm likely being thick here. regards Richard -- richard@tortoise.demon.co.uk
Richard You are definetly not being thick but would be interested in which flavour of unix you are running. Under Solaris if a plain 'su' is used all environment variables are passed EXCEPT PATH, which is set by the shell script /etc/default/su. I haven't generally seen this setup used in linux, but perfectly possible, so a bit of hunting required I'm afraid. Peter. On Thu, 2003-07-24 at 19:43, richard@tortoise.demon.co.uk wrote:
Hi Thomas,
could you bear with me on this?
I don't think /etc/profile is executed if I su to root. If I put something like echo "here we are in /etc/profile" at the start of it, I never see the echo when I su
Of course not. I am taking that last sentence literally when you say "su" and not "su -". If you just "su", then yes, you will get to be user "root", but all that has done is to change your effective $UID and $GID. NO environment variables are modified with a plain "su".
Ok, so no environment variables are modified. $PATH is an environmental variable.
richard@linux:~ > echo $PATH /usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/lib/java/bin:/var/lib /dosemu:/usr/games/bin:/usr/games:/opt/gnome/bin:/opt/kde2/bin:/opt/kd e/bin:/usr/openwin/bin:.:/opt/gnome/bin:/opt/pilotsdk/bin richard@linux:~ > su Password: root@linux:/home/richard > echo $PATH /usr/sbin:/bin:/usr/bin:/sbin:/usr/X11R6/bin
So a plain su HAS modified an environmental variable. PATH wasn't constructed after su within /etc/profile because /etc/profile wasn't run.
So the question remains, where does the new path come from?
I'm likely being thick here.
regards Richard
-- richard@tortoise.demon.co.uk
--- richard@tortoise.demon.co.uk wrote:
Hi Thomas,
Richard,
could you bear with me on this?
Sure, of course. You must forgive me if my tone appears slightly angry, that is *most definitely* not my intent. I find this most interesting.
I don't think /etc/profile is executed if I su to root. If I put something like echo "here we are in /etc/profile" at the start of it, I never see the echo when I su
Of course not. I am taking that last sentence literally when you say "su" and not "su -". If you just "su", then yes, you will get to be user "root", but all that has done is to change your effective $UID and $GID. NO environment variables are modified with a plain "su".
Ok, so no environment variables are modified. $PATH is an environmental variable.
$PATH is indeed an environment variable. If you were to type in "exports", you'd see a huge list of them.
richard@linux:~ > echo $PATH /usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/lib/java/bin:/var/lib /dosemu:/usr/games/bin:/usr/games:/opt/gnome/bin:/opt/kde2/bin:/opt/kd e/bin:/usr/openwin/bin:.:/opt/gnome/bin:/opt/pilotsdk/bin richard@linux:~ > su Password: root@linux:/home/richard > echo $PATH /usr/sbin:/bin:/usr/bin:/sbin:/usr/X11R6/bin
So a plain su HAS modified an environmental variable. PATH wasn't constructed after su within /etc/profile because /etc/profile wasn't run.
So the question remains, where does the new path come from?
I'm likely being thick here.
No, Richard far from it :) I think I should start checking my facts. I use suSE 6.4 on my server and my story stands thus far, yet I am suspecting now that a plain "su" does indeed modify $PATH, perhaps from sourcing "~/.bashrc" and "~/.bash_profile", which *might* contain a new $PATH export. BUT, if that were the case then the second $PATH you listed there would be the exported one when you logged into root's account normally. One thing I am going to suggest is you *try* the following: su -c'bash -norc' That would effectively stop bash from reading ~/.bashrc et al on "su". My only suspicion here is that by doing that command above, you'd be creating a subshell within the su'ed account... I've just ran "strace su" and a plain "su" does read ~/.bashrc :) :) Therefore, if you have export PATH in "~/.bashrc", I would either comment it out, or... su -m would also stop this from happening. I am off now to hit myself repeatedly, after which I am then going to go and read Newbie_Linux_Guide, and then I am going to apologise for dragging this thread out far too long, and giving everybody the creeps. Sorry :) -- Thomas Adam ===== Thomas Adam "The Linux Weekend Mechanic" -- www.linuxgazette.com ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
As far as my understanding of the philosophy of su is concerned, the default action is not to perform a 'login' but to change the effective guid and uid of the shell, this is the function of the '-' or '-l' parameter, therefore it should certainly not source the target users rc or profile files. I'm not sure why some implementations of su on *nix change the path variable (even RedHat doesn't... probably an oversight while wondering how to make it even more difficult to use Wine) , and if they do I would hope that it's documented :-) In regard to newbie manuals, I've been working on unix systems since 1989 (would have thought I would have learnt my lesson by now, or at least something) and I still bash them repeatedly on my head (how can Kernighan and Pike write 'The UNIX programming environment' in about the same space as my UNIX shell quick reference?) Peter. (tired, friday, ten past four and it's raining) On Fri, 2003-07-25 at 13:25, Thomas Adam wrote:
--- richard@tortoise.demon.co.uk wrote:
Hi Thomas,
Richard,
could you bear with me on this?
Sure, of course. You must forgive me if my tone appears slightly angry, that is *most definitely* not my intent. I find this most interesting.
I don't think /etc/profile is executed if I su to root. If I put something like echo "here we are in /etc/profile" at the start of it, I never see the echo when I su
Of course not. I am taking that last sentence literally when you say "su" and not "su -". If you just "su", then yes, you will get to be user "root", but all that has done is to change your effective $UID and $GID. NO environment variables are modified with a plain "su".
Ok, so no environment variables are modified. $PATH is an environmental variable.
$PATH is indeed an environment variable. If you were to type in "exports", you'd see a huge list of them.
richard@linux:~ > echo $PATH /usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/lib/java/bin:/var/lib /dosemu:/usr/games/bin:/usr/games:/opt/gnome/bin:/opt/kde2/bin:/opt/kd e/bin:/usr/openwin/bin:.:/opt/gnome/bin:/opt/pilotsdk/bin richard@linux:~ > su Password: root@linux:/home/richard > echo $PATH /usr/sbin:/bin:/usr/bin:/sbin:/usr/X11R6/bin
So a plain su HAS modified an environmental variable. PATH wasn't constructed after su within /etc/profile because /etc/profile wasn't run.
So the question remains, where does the new path come from?
I'm likely being thick here.
No, Richard far from it :) I think I should start checking my facts. I use suSE 6.4 on my server and my story stands thus far, yet I am suspecting now that a plain "su" does indeed modify $PATH, perhaps from sourcing "~/.bashrc" and "~/.bash_profile", which *might* contain a new $PATH export. BUT, if that were the case then the second $PATH you listed there would be the exported one when you logged into root's account normally.
One thing I am going to suggest is you *try* the following:
su -c'bash -norc'
That would effectively stop bash from reading ~/.bashrc et al on "su". My only suspicion here is that by doing that command above, you'd be creating a subshell within the su'ed account...
I've just ran "strace su" and a plain "su" does read ~/.bashrc :) :) Therefore, if you have export PATH in "~/.bashrc", I would either comment it out, or...
su -m
would also stop this from happening.
I am off now to hit myself repeatedly, after which I am then going to go and read Newbie_Linux_Guide, and then I am going to apologise for dragging this thread out far too long, and giving everybody the creeps.
Sorry :)
-- Thomas Adam
===== Thomas Adam
"The Linux Weekend Mechanic" -- www.linuxgazette.com
________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
--- Peter Wilson <peter.wilson@tuxite.com> wrote:
As far as my understanding of the philosophy of su is concerned, the default action is not to perform a 'login' but to change the effective guid and uid of the shell, this is the function of the '-' or '-l'
Yes, you are right when you say that a normal "su" changes the effective UID **and** GID, but that is only for the $USER, and NOT for the shell as you write above :) the shell does not have U{G}ID's!!! You're slightly in error when you say that "-" or "-l" is all that those options do, apart from changing the UID/GID of the $USER concerned. I have been intrigued by by this thread ever since it started and have ran several degenerative tests, not to mention several "strace"()'s. "su -" (su -l) creates a login shell, i.e. "~/.bashrc" is read upon startup. Furthermore, the environment variables: SHELL TERM PATH HOME are all changed. With a plain "su" however, only $SHELL and $LOGNAME, $HOME should be changed, UNLESS you have them defined in ~/.bashrc!!! Thus, what I am suspecting is that in your "/root/.bashrc" file you have PATH being exported. I'd most likely comment this out, as it is already pre-defined in /etc/profile for root anyhow... The reason why ~/.bashrc is read is because "su" is interactive. That way, when you either "su" or "su -" it will be alright :) To counteract the effects of this, issue: su -m [user] which will leave the environment un-modified.
parameter, therefore it should certainly not source the target users rc or profile files. I'm not sure why some implementations of su on *nix change the path variable (even RedHat doesn't... probably an oversight while wondering how to make it even more difficult to use Wine) , and if they do I would hope that it's documented :-)
The parlance for "su" on UNIX systems kept changing...
In regard to newbie manuals, I've been working on unix systems since 1989 (would have thought I would have learnt my lesson by now, or at least something) and I still bash them repeatedly on my head (how can Kernighan and Pike write 'The UNIX programming environment' in about the same space as my UNIX shell quick reference?)
Yes, but do not forget, peter, that GNU have added a bazillion of options ontop of the standard UNIX ones.... HTH, -- Thomas Adam
Peter. (tired, friday, ten past four and it's raining)
On Fri, 2003-07-25 at 13:25, Thomas Adam wrote:
--- richard@tortoise.demon.co.uk wrote:
Hi Thomas,
Richard,
could you bear with me on this?
Sure, of course. You must forgive me if my tone appears slightly angry, that is *most definitely* not my intent. I find this most interesting.
I don't think /etc/profile is executed if I su to root. If I put
something like echo "here we are in /etc/profile" at the start of it, I never see the echo when I su
Of course not. I am taking that last sentence literally when you say "su" and not "su -". If you just "su", then yes, you will get to be user "root", but all that has done is to change your effective $UID and $GID. NO environment variables are modified with a plain "su".
Ok, so no environment variables are modified. $PATH is an environmental variable.
$PATH is indeed an environment variable. If you were to type in "exports", you'd see a huge list of them.
richard@linux:~ > echo $PATH
/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/lib/java/bin:/var/lib
/dosemu:/usr/games/bin:/usr/games:/opt/gnome/bin:/opt/kde2/bin:/opt/kd
e/bin:/usr/openwin/bin:.:/opt/gnome/bin:/opt/pilotsdk/bin richard@linux:~ > su Password: root@linux:/home/richard > echo $PATH /usr/sbin:/bin:/usr/bin:/sbin:/usr/X11R6/bin
So a plain su HAS modified an environmental variable. PATH wasn't constructed after su within /etc/profile because /etc/profile wasn't run.
So the question remains, where does the new path come from?
I'm likely being thick here.
No, Richard far from it :) I think I should start checking my facts. I use suSE 6.4 on my server and my story stands thus far, yet I am suspecting now that a plain "su" does indeed modify $PATH, perhaps from sourcing "~/.bashrc" and "~/.bash_profile", which *might* contain a new $PATH export. BUT, if that were the case then the second $PATH you listed there would be the exported one when you logged into root's account normally.
One thing I am going to suggest is you *try* the following:
su -c'bash -norc'
That would effectively stop bash from reading ~/.bashrc et al on "su". My only suspicion here is that by doing that command above, you'd be creating a subshell within the su'ed account...
I've just ran "strace su" and a plain "su" does read ~/.bashrc :) :) Therefore, if you have export PATH in "~/.bashrc", I would either comment it out, or...
su -m
would also stop this from happening.
I am off now to hit myself repeatedly, after which I am then going to go and read Newbie_Linux_Guide, and then I am going to apologise for dragging this thread out far too long, and giving everybody the creeps.
Sorry :)
-- Thomas Adam
===== Thomas Adam
"The Linux Weekend Mechanic" -- www.linuxgazette.com
________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
-- To unsubscribe, e-mail: suse-linux-uk-schools-unsubscribe@suse.com For additional commands, e-mail: suse-linux-uk-schools-help@suse.com
===== Thomas Adam "The Linux Weekend Mechanic" -- www.linuxgazette.com ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
Thomas. Yep, this is an interesting thread... and I do apologise for my slight inaccuracies :-(
Yes, but do not forget, peter, that GNU have added a bazillion of > > options ontop of the standard UNIX ones....
'... at it's heart is the idea that the power of a system comes from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial tasks in isolation, but, combined with other programs, become general and useful tools...' (Kernighan and Pike) Sorry, couldn't resist that :-) Peter. On Mon, 2003-07-28 at 10:33, Thomas Adam wrote:
--- Peter Wilson <peter.wilson@tuxite.com> wrote:
As far as my understanding of the philosophy of su is concerned, the default action is not to perform a 'login' but to change the effective guid and uid of the shell, this is the function of the '-' or '-l'
Yes, you are right when you say that a normal "su" changes the effective UID **and** GID, but that is only for the $USER, and NOT for the shell as you write above :) the shell does not have U{G}ID's!!! You're slightly in error when you say that "-" or "-l" is all that those options do, apart from changing the UID/GID of the $USER concerned. I have been intrigued by by this thread ever since it started and have ran several degenerative tests, not to mention several "strace"()'s.
"su -" (su -l) creates a login shell, i.e. "~/.bashrc" is read upon startup. Furthermore, the environment variables:
SHELL TERM PATH HOME
are all changed.
With a plain "su" however, only $SHELL and $LOGNAME, $HOME should be changed, UNLESS you have them defined in ~/.bashrc!!!
Thus, what I am suspecting is that in your "/root/.bashrc" file you have PATH being exported. I'd most likely comment this out, as it is already pre-defined in /etc/profile for root anyhow... The reason why ~/.bashrc is read is because "su" is interactive.
That way, when you either "su" or "su -" it will be alright :)
To counteract the effects of this, issue:
su -m [user]
which will leave the environment un-modified.
parameter, therefore it should certainly not source the target users rc or profile files. I'm not sure why some implementations of su on *nix change the path variable (even RedHat doesn't... probably an oversight while wondering how to make it even more difficult to use Wine) , and if they do I would hope that it's documented :-)
The parlance for "su" on UNIX systems kept changing...
In regard to newbie manuals, I've been working on unix systems since 1989 (would have thought I would have learnt my lesson by now, or at least something) and I still bash them repeatedly on my head (how can Kernighan and Pike write 'The UNIX programming environment' in about the same space as my UNIX shell quick reference?)
Yes, but do not forget, peter, that GNU have added a bazillion of options ontop of the standard UNIX ones....
HTH,
-- Thomas Adam
Peter. (tired, friday, ten past four and it's raining)
On Fri, 2003-07-25 at 13:25, Thomas Adam wrote:
--- richard@tortoise.demon.co.uk wrote:
Hi Thomas,
Richard,
could you bear with me on this?
Sure, of course. You must forgive me if my tone appears slightly angry, that is *most definitely* not my intent. I find this most interesting.
I don't think /etc/profile is executed if I su to root. If I put
something like echo "here we are in /etc/profile" at the start of it, I never see the echo when I su
Of course not. I am taking that last sentence literally when you say "su" and not "su -". If you just "su", then yes, you will get to be user "root", but all that has done is to change your effective $UID and $GID. NO environment variables are modified with a plain "su".
Ok, so no environment variables are modified. $PATH is an environmental variable.
$PATH is indeed an environment variable. If you were to type in "exports", you'd see a huge list of them.
richard@linux:~ > echo $PATH
/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/lib/java/bin:/var/lib
/dosemu:/usr/games/bin:/usr/games:/opt/gnome/bin:/opt/kde2/bin:/opt/kd
e/bin:/usr/openwin/bin:.:/opt/gnome/bin:/opt/pilotsdk/bin richard@linux:~ > su Password: root@linux:/home/richard > echo $PATH /usr/sbin:/bin:/usr/bin:/sbin:/usr/X11R6/bin
So a plain su HAS modified an environmental variable. PATH wasn't constructed after su within /etc/profile because /etc/profile wasn't run.
So the question remains, where does the new path come from?
I'm likely being thick here.
No, Richard far from it :) I think I should start checking my facts. I use suSE 6.4 on my server and my story stands thus far, yet I am suspecting now that a plain "su" does indeed modify $PATH, perhaps from sourcing "~/.bashrc" and "~/.bash_profile", which *might* contain a new $PATH export. BUT, if that were the case then the second $PATH you listed there would be the exported one when you logged into root's account normally.
One thing I am going to suggest is you *try* the following:
su -c'bash -norc'
That would effectively stop bash from reading ~/.bashrc et al on "su". My only suspicion here is that by doing that command above, you'd be creating a subshell within the su'ed account...
I've just ran "strace su" and a plain "su" does read ~/.bashrc :) :) Therefore, if you have export PATH in "~/.bashrc", I would either comment it out, or...
su -m
would also stop this from happening.
I am off now to hit myself repeatedly, after which I am then going to go and read Newbie_Linux_Guide, and then I am going to apologise for dragging this thread out far too long, and giving everybody the creeps.
Sorry :)
-- Thomas Adam
===== Thomas Adam
"The Linux Weekend Mechanic" -- www.linuxgazette.com
________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
-- To unsubscribe, e-mail: suse-linux-uk-schools-unsubscribe@suse.com For additional commands, e-mail: suse-linux-uk-schools-help@suse.com
===== Thomas Adam
"The Linux Weekend Mechanic" -- www.linuxgazette.com
________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
--- Peter Wilson <peter.wilson@tuxite.com> wrote:
Thomas.
Yep, this is an interesting thread... and I do apologise for my slight inaccuracies :-(
LOL, please, Peter, do not take that to heart. I just wanted to clarify it for all concerned. I suppose you could say that I am having a wasted youth, knowing that in too much detail!
Yes, but do not forget, peter, that GNU have added a bazillion of > > options ontop of the standard UNIX ones....
'... at it's heart is the idea that the power of a system comes from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial tasks in isolation, but, combined with other programs, become general and useful tools...' (Kernighan and Pike)
Sorry, couldn't resist that :-)
Heh -- but the quote is VERY true :) -- Thomas Adam
Peter.
--- Peter Wilson <peter.wilson@tuxite.com> wrote:
As far as my understanding of the philosophy of su is concerned, the default action is not to perform a 'login' but to change the effective guid and uid of the shell, this is the function of the '-' or '-l'
Yes, you are right when you say that a normal "su" changes the effective UID **and** GID, but that is only for the $USER, and NOT for the shell as you write above :) the shell does not have U{G}ID's!!! You're slightly in error when you say that "-" or "-l" is all that those options do, apart from changing the UID/GID of the $USER concerned. I have been intrigued by by this thread ever since it started and have ran several degenerative tests, not to mention several "strace"()'s.
"su -" (su -l) creates a login shell, i.e. "~/.bashrc" is read upon startup. Furthermore, the environment variables:
SHELL TERM PATH HOME
are all changed.
With a plain "su" however, only $SHELL and $LOGNAME, $HOME should be changed, UNLESS you have them defined in ~/.bashrc!!!
Thus, what I am suspecting is that in your "/root/.bashrc" file you have PATH being exported. I'd most likely comment this out, as it is already pre-defined in /etc/profile for root anyhow... The reason why ~/.bashrc is read is because "su" is interactive.
That way, when you either "su" or "su -" it will be alright :)
To counteract the effects of this, issue:
su -m [user]
which will leave the environment un-modified.
parameter, therefore it should certainly not source the target users rc or profile files. I'm not sure why some implementations of su on *nix change the path variable (even RedHat doesn't... probably an oversight while wondering how to make it even more difficult to use Wine) , and if they do I would hope that it's documented :-)
The parlance for "su" on UNIX systems kept changing...
In regard to newbie manuals, I've been working on unix systems since 1989 (would have thought I would have learnt my lesson by now, or at least something) and I still bash them repeatedly on my head (how can Kernighan and Pike write 'The UNIX programming environment' in about
same space as my UNIX shell quick reference?)
Yes, but do not forget, peter, that GNU have added a bazillion of
ontop of the standard UNIX ones....
HTH,
-- Thomas Adam
Peter. (tired, friday, ten past four and it's raining)
On Fri, 2003-07-25 at 13:25, Thomas Adam wrote:
--- richard@tortoise.demon.co.uk wrote:
Hi Thomas,
Richard,
could you bear with me on this?
Sure, of course. You must forgive me if my tone appears slightly angry, that is *most definitely* not my intent. I find this most interesting.
> I don't think /etc/profile is executed if I su to root. If I
> something like > echo "here we are in /etc/profile" > at the start of it, I never see the echo when I su
Of course not. I am taking that last sentence literally when
you
say
"su"
and not "su -". If you just "su", then yes, you will get to be user "root", but all that has done is to change your effective $UID and $GID. NO environment variables are modified with a plain "su".
Ok, so no environment variables are modified. $PATH is an environmental variable.
$PATH is indeed an environment variable. If you were to type in "exports", you'd see a huge list of them.
richard@linux:~ > echo $PATH
/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/lib/java/bin:/var/lib
/dosemu:/usr/games/bin:/usr/games:/opt/gnome/bin:/opt/kde2/bin:/opt/kd
e/bin:/usr/openwin/bin:.:/opt/gnome/bin:/opt/pilotsdk/bin richard@linux:~ > su Password: root@linux:/home/richard > echo $PATH /usr/sbin:/bin:/usr/bin:/sbin:/usr/X11R6/bin
So a plain su HAS modified an environmental variable. PATH wasn't constructed after su within /etc/profile because /etc/profile wasn't run.
So the question remains, where does the new path come from?
I'm likely being thick here.
No, Richard far from it :) I think I should start checking my facts. I use suSE 6.4 on my server and my story stands thus far, yet I am suspecting now that a plain "su" does indeed modify $PATH, perhaps from sourcing "~/.bashrc" and "~/.bash_profile", which *might* contain a new $PATH export. BUT, if that were the case then the second $PATH you
On Mon, 2003-07-28 at 10:33, Thomas Adam wrote: the options put listed
there
would be the exported one when you logged into root's account normally.
One thing I am going to suggest is you *try* the following:
su -c'bash -norc'
That would effectively stop bash from reading ~/.bashrc et al on "su". My only suspicion here is that by doing that command above, you'd be creating a subshell within the su'ed account...
I've just ran "strace su" and a plain "su" does read ~/.bashrc :) :) Therefore, if you have export PATH in "~/.bashrc", I would either comment it out, or...
su -m
would also stop this from happening.
I am off now to hit myself repeatedly, after which I am then going to go and read Newbie_Linux_Guide, and then I am going to apologise for dragging this thread out far too long, and giving everybody the creeps.
Sorry :)
-- Thomas Adam
===== Thomas Adam
"The Linux Weekend Mechanic" -- www.linuxgazette.com
Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
-- To unsubscribe, e-mail: suse-linux-uk-schools-unsubscribe@suse.com For additional commands, e-mail: suse-linux-uk-schools-help@suse.com
===== Thomas Adam
"The Linux Weekend Mechanic" -- www.linuxgazette.com
________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
-- To unsubscribe, e-mail: suse-linux-uk-schools-unsubscribe@suse.com For additional commands, e-mail: suse-linux-uk-schools-help@suse.com
===== Thomas Adam "The Linux Weekend Mechanic" -- www.linuxgazette.com ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
Thomas
Heh -- but the quote is VERY true :)
Sorry, that was a (very) little dig at GNU, who do seem to like to 'improve' functionality of programs at times... ... but I'm moving off topic ... Peter. On Mon, 2003-07-28 at 11:04, Thomas Adam wrote:
--- Peter Wilson <peter.wilson@tuxite.com> wrote:
Thomas.
Yep, this is an interesting thread... and I do apologise for my slight inaccuracies :-(
LOL, please, Peter, do not take that to heart. I just wanted to clarify it for all concerned. I suppose you could say that I am having a wasted youth, knowing that in too much detail!
Yes, but do not forget, peter, that GNU have added a bazillion of > > options ontop of the standard UNIX ones....
'... at it's heart is the idea that the power of a system comes from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial tasks in isolation, but, combined with other programs, become general and useful tools...' (Kernighan and Pike)
Sorry, couldn't resist that :-)
Heh -- but the quote is VERY true :)
-- Thomas Adam
Peter.
--- Peter Wilson <peter.wilson@tuxite.com> wrote:
As far as my understanding of the philosophy of su is concerned, the default action is not to perform a 'login' but to change the effective guid and uid of the shell, this is the function of the '-' or '-l'
Yes, you are right when you say that a normal "su" changes the effective UID **and** GID, but that is only for the $USER, and NOT for the shell as you write above :) the shell does not have U{G}ID's!!! You're slightly in error when you say that "-" or "-l" is all that those options do, apart from changing the UID/GID of the $USER concerned. I have been intrigued by by this thread ever since it started and have ran several degenerative tests, not to mention several "strace"()'s.
"su -" (su -l) creates a login shell, i.e. "~/.bashrc" is read upon startup. Furthermore, the environment variables:
SHELL TERM PATH HOME
are all changed.
With a plain "su" however, only $SHELL and $LOGNAME, $HOME should be changed, UNLESS you have them defined in ~/.bashrc!!!
Thus, what I am suspecting is that in your "/root/.bashrc" file you have PATH being exported. I'd most likely comment this out, as it is already pre-defined in /etc/profile for root anyhow... The reason why ~/.bashrc is read is because "su" is interactive.
That way, when you either "su" or "su -" it will be alright :)
To counteract the effects of this, issue:
su -m [user]
which will leave the environment un-modified.
parameter, therefore it should certainly not source the target users rc or profile files. I'm not sure why some implementations of su on *nix change the path variable (even RedHat doesn't... probably an oversight while wondering how to make it even more difficult to use Wine) , and if they do I would hope that it's documented :-)
The parlance for "su" on UNIX systems kept changing...
In regard to newbie manuals, I've been working on unix systems since 1989 (would have thought I would have learnt my lesson by now, or at least something) and I still bash them repeatedly on my head (how can Kernighan and Pike write 'The UNIX programming environment' in about
same space as my UNIX shell quick reference?)
Yes, but do not forget, peter, that GNU have added a bazillion of
ontop of the standard UNIX ones....
HTH,
-- Thomas Adam
Peter. (tired, friday, ten past four and it's raining)
On Fri, 2003-07-25 at 13:25, Thomas Adam wrote:
--- richard@tortoise.demon.co.uk wrote:
Hi Thomas,
Richard,
could you bear with me on this?
Sure, of course. You must forgive me if my tone appears slightly angry, that is *most definitely* not my intent. I find this most interesting.
> > I don't think /etc/profile is executed if I su to root. If I
> > something like > > echo "here we are in /etc/profile" > > at the start of it, I never see the echo when I su > > Of course not. I am taking that last sentence literally when
you
say
"su" > and not "su -". If you just "su", then yes, you will get to be user > "root", but all that has done is to change your effective $UID and $GID. > NO environment variables are modified with a plain "su".
Ok, so no environment variables are modified. $PATH is an environmental variable.
$PATH is indeed an environment variable. If you were to type in "exports", you'd see a huge list of them.
richard@linux:~ > echo $PATH
/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/lib/java/bin:/var/lib
/dosemu:/usr/games/bin:/usr/games:/opt/gnome/bin:/opt/kde2/bin:/opt/kd
e/bin:/usr/openwin/bin:.:/opt/gnome/bin:/opt/pilotsdk/bin richard@linux:~ > su Password: root@linux:/home/richard > echo $PATH /usr/sbin:/bin:/usr/bin:/sbin:/usr/X11R6/bin
So a plain su HAS modified an environmental variable. PATH wasn't constructed after su within /etc/profile because /etc/profile wasn't run.
So the question remains, where does the new path come from?
I'm likely being thick here.
No, Richard far from it :) I think I should start checking my facts. I use suSE 6.4 on my server and my story stands thus far, yet I am suspecting now that a plain "su" does indeed modify $PATH, perhaps from sourcing "~/.bashrc" and "~/.bash_profile", which *might* contain a new $PATH export. BUT, if that were the case then the second $PATH you
On Mon, 2003-07-28 at 10:33, Thomas Adam wrote: the options put listed
there
would be the exported one when you logged into root's account normally.
One thing I am going to suggest is you *try* the following:
su -c'bash -norc'
That would effectively stop bash from reading ~/.bashrc et al on "su". My only suspicion here is that by doing that command above, you'd be creating a subshell within the su'ed account...
I've just ran "strace su" and a plain "su" does read ~/.bashrc :) :) Therefore, if you have export PATH in "~/.bashrc", I would either comment it out, or...
su -m
would also stop this from happening.
I am off now to hit myself repeatedly, after which I am then going to go and read Newbie_Linux_Guide, and then I am going to apologise for dragging this thread out far too long, and giving everybody the creeps.
Sorry :)
-- Thomas Adam
===== Thomas Adam
"The Linux Weekend Mechanic" -- www.linuxgazette.com
Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
-- To unsubscribe, e-mail: suse-linux-uk-schools-unsubscribe@suse.com For additional commands, e-mail: suse-linux-uk-schools-help@suse.com
===== Thomas Adam
"The Linux Weekend Mechanic" -- www.linuxgazette.com
________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
-- To unsubscribe, e-mail: suse-linux-uk-schools-unsubscribe@suse.com For additional commands, e-mail: suse-linux-uk-schools-help@suse.com
===== Thomas Adam
"The Linux Weekend Mechanic" -- www.linuxgazette.com
________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
On Mon, Jul 28, 2003 at 10:33:34AM +0100, Thomas Adam wrote:
--- Peter Wilson <peter.wilson@tuxite.com> wrote:
As far as my understanding of the philosophy of su is concerned, the default action is not to perform a 'login' but to change the effective guid and uid of the shell, this is the function of the '-' or '-l'
Yes, you are right when you say that a normal "su" changes the effective UID **and** GID, but that is only for the $USER, and NOT for the shell as you write above :) the shell does not have U{G}ID's!!!
Of course the shell has UID and GIDs. The shell is a process and every process has real, effective, saved and (on Linux) filesystem UIDs and GIDs which determine which files it can access and how it can interact with other processes. It makes no difference how you call su however - they will all be set to 0. (If you want to see these values, "cat /proc/$PID/status | grep Uid" will give them to you.) -- Martin Orr Linux Administrator, Methodist College Belfast
--- Martin Orr <martin@walnut.methody.org> wrote:
On Mon, Jul 28, 2003 at 10:33:34AM +0100, Thomas Adam wrote:
--- Peter Wilson <peter.wilson@tuxite.com> wrote:
As far as my understanding of the philosophy of su is concerned, the default action is not to perform a 'login' but to change the effective guid and uid of the shell, this is the function of the '-' or '-l'
Yes, you are right when you say that a normal "su" changes the effective UID **and** GID, but that is only for the $USER, and NOT for the shell as you write above :) the shell does not have U{G}ID's!!!
Of course the shell has UID and GIDs. The shell is a process and every process has real, effective, saved and (on Linux) filesystem UIDs and GIDs which determine which files it can access and how it can interact with other processes. It makes no difference how you call su however - they will all be set to 0. (If you want to see these values, "cat /proc/$PID/status | grep Uid" will give them to you.)
:) *cough*, /bin/bash does not have a GID/UID assigned to it per se, which is now I interpreted Peter's initial sentence. /bin/bash (or whatever $SHELL is set to) is not the one that handles the U{G}ID's at all, that is done with the kernel (as you have spotted via "/proc"). Again, you're slightly in error as "su" is specified by "su [user]" will change the GID/UID for the [user] specified, and will NOT get changed to 0. -- Thomas Adam ===== Thomas Adam "The Linux Weekend Mechanic" -- www.linuxgazette.com ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
Martin, That is certainly my understanding. Peter. On Mon, 2003-07-28 at 11:30, Martin Orr wrote:
On Mon, Jul 28, 2003 at 10:33:34AM +0100, Thomas Adam wrote:
--- Peter Wilson <peter.wilson@tuxite.com> wrote:
As far as my understanding of the philosophy of su is concerned, the default action is not to perform a 'login' but to change the effective guid and uid of the shell, this is the function of the '-' or '-l'
Yes, you are right when you say that a normal "su" changes the effective UID **and** GID, but that is only for the $USER, and NOT for the shell as you write above :) the shell does not have U{G}ID's!!!
Of course the shell has UID and GIDs. The shell is a process and every process has real, effective, saved and (on Linux) filesystem UIDs and GIDs which determine which files it can access and how it can interact with other processes. It makes no difference how you call su however - they will all be set to 0. (If you want to see these values, "cat /proc/$PID/status | grep Uid" will give them to you.)
-- Martin Orr Linux Administrator, Methodist College Belfast
Hi Thomas, Maybe this issue will have to remain a mystery to me for now.
One thing I am going to suggest is you *try* the following:
su -c'bash -norc'
That would effectively stop bash from reading ~/.bashrc et al on "su".
sunil@linux:~ > echo $PATH /usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/lib/java/bin:/var/lib /dosemu:/usr/games/bin:/usr/games:/opt/gnome/bin:/opt/kde2/bin:/opt/kd e/bin:/usr/openwin/bin:.:/opt/gnome/bin:/opt/pilotsdk/bin:/home/sunil/ myprogs sunil@linux:~ > su -c'bash -norc' Password: bash-2.05# echo $PATH /usr/sbin:/bin:/usr/bin:/sbin:/usr/X11R6/bin bash-2.05# As you see, $PATH is still changing. I discovered /etc/login.defs earlier. According to man login.defs, the entries there set a default path, but the the values in my /etc/login.defs still don't explain the $PATH I'm getting after su. Thanks for your help, regards Richard -- richard@tortoise.demon.co.uk
--- richard@tortoise.demon.co.uk wrote:
Hi Thomas,
Maybe this issue will have to remain a mystery to me for now.
Hmm, I'd like to get it sorted, if not for my own interest.
One thing I am going to suggest is you *try* the following:
su -c'bash -norc'
That would effectively stop bash from reading ~/.bashrc et al on "su".
sunil@linux:~ > echo $PATH /usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/lib/java/bin:/var/lib /dosemu:/usr/games/bin:/usr/games:/opt/gnome/bin:/opt/kde2/bin:/opt/kd e/bin:/usr/openwin/bin:.:/opt/gnome/bin:/opt/pilotsdk/bin:/home/sunil/ myprogs sunil@linux:~ > su -c'bash -norc' Password: bash-2.05# echo $PATH /usr/sbin:/bin:/usr/bin:/sbin:/usr/X11R6/bin bash-2.05#
As you see, $PATH is still changing.
Yes, it is. This *must* be to do with the way ~/.bashrc is setup.
I discovered /etc/login.defs earlier. According to man login.defs, the entries there set a default path, but the the values in my /etc/login.defs still don't explain the $PATH I'm getting after su.
login.defs, yes does do that. I was reluctant to mention it at first, since actually it also defines who logs in too. This could well be a bug in the way SuSE have managed their initscripts. If only Roger Whittiker kept a closer eye on this list... Richard, if I can help further, let me know. This issue is most interesting. -- Thomas Adam
Thanks for your help,
regards Richard -- richard@tortoise.demon.co.uk
-- To unsubscribe, e-mail: suse-linux-uk-schools-unsubscribe@suse.com For additional commands, e-mail: suse-linux-uk-schools-help@suse.com
===== Thomas Adam "The Linux Weekend Mechanic" -- www.linuxgazette.com ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
--- richard@tortoise.demon.co.uk wrote:
Could anyone tell me what I'm doing wrong here?
I'll try :_
I'm still using suse 7.2 and recently I tried installing an application that I think needs a more recent library that comes with the c compiler.
Well, technically if one is compiling from source then the version of gcc that you're using (and hence glibc) is used in compilation so that is never a problem. BUT, if you had used a binary file that was compiled using a version of GLIBC that was greater than 7.2, then it won't work!
So, I got gcc-3.2.tar.gz, putting it into /root/downloads/gcc uncompressing it created: /root/downloads/gcc/gcc-3.2 I made /root/downloads/gcc/objdir and from there did /root/downloads/gcc/gcc-3.2/configure followed by make bootstrap It took almost 12 hours to compile! Then I did make install
Ouch! This is not going to be good.
Now, gcc -v is reporting different versions, depending who I am!
Of course....
If I log on as root, gcc -v reports 3.2
If I log on as an ordinary user and then su to root, gcc -v reports 2.95.3 , reading specs from a different place.
What is happening here is that your library cache is VERY confused as to which libs are which. I'm hoping that after compilation you ran the following: ldconfig that would have updated "/etc/ld.so" which is VERY important. The fact the you compiled GCC and the installed it meant that many of the libs would have gone into: /usr/local/lib so, before running "ldconfig", ensure that the above path is present in the file "/etc/ld.so.conf" and then run "ldconfig" again. One important feature here is the use of $PATH. The reason, I suspect as to why you're getting a mis-match of GCC versions is to do with how $PATH changes between $USER <> "root" and an su'ed account. When you enter a program name at the CL, Bash (or whatever shell you happen to be using) will look in $PATH for that name, but more importantly it'll look for it in the order that the directories are listed in $PATH. You'll notice that if you log in as a non-root user, type: echo $PATH then "su -" (the "-" is important here, as if root is not created a login shell, then $PATH will not change), you'll see a subtle difference. My guess here is that somewhere along the line "/usr/local/bin" is being listed BEFORE "/usr/bin" and causing you problems. Should that be the case (and you want to use the GCC compiled and stored in /usr/local/bin) then you can either: ln -s /usr/local/bin/gcc /usr/bin (BAD idea) or, you can edit: /etc/profile and change the order of the directory listings for $PATH for root or $USER <> "root". I hope that helps? -- Thomas Adam ===== Thomas Adam "The Linux Weekend Mechanic" -- www.linuxgazette.com ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Tuesday 22 July 2003 11:51, Thomas Adam wrote:
What is happening here is that your library cache is VERY confused as to which libs are which. I'm hoping that after compilation you ran the following:
In my experience, self-compiled gcc's are pretty good at keeping their libs separate from those of distro supplied gcc's. I don't think I've had to mess with ldconfig and friends before. - -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP ID: 33795A2C KDE/Qt/C++/PHP Developer: http://www.kde.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE/HSEkF8Iu1zN5WiwRAj4YAJ0TagfPdPHfkH90+4kWpkHib4/xdQCcDQMo 9Lt/kCDt7fm9Bq1X9VB+A2Y= =+Vlv -----END PGP SIGNATURE-----
participants (6)
-
Chris Howells -
Martin Orr -
Peter Wilson -
Peter Wilson -
richard＠tortoise.demon.co.uk -
Thomas Adam