Dear all,
Just a quick question : when running the Debugger in GUI mode, my environment variables are reset to somewhat basic values - e.g., LD_LIBRARY_PATH is reset to PGHPF lib path.
Question : how do I tell the debugger to load my user’s environment variables rather than its own values?
Sorry if this question is either basic or already answered -didn’t find it on the forums.
Many thanks to all in advance.
Pierre-François
Hi Pierre-François,
PGDBG will inherit the user’s environment. So setting LD_LIBRARY_PATH before launching the debugger should include the correct shared library directories.
If setting LD_LIBRARY_PATH in the environment is not possible, the user can use the “setenv” command in the command window. For example “setenv LD_LIBRARY_PATH /path/to/lib1:/path/to/lib2:/path/to/lib3”. “setenv LD_LIBRARY_PATH” will display the value of LD_LIBRARY_PATH.
Hope this helps,
Mat
Mat,
Well, thank you for your answer.
However - and I guess that’s an issue, PGDBG won’t inherit my environment at all. Actually it seems to inherit every single variable environment (I checked PATH as an example) except for LD_LIBRARY_PATH.
How come?
Best regards,
Pierre-François
How are you launching PGDBG? (From the command line, a script, or from the OS start menu).
Which OS? (I’ve been assuming you’re running Linux).
Dear Mat,
I’m running PGDBG from the command line on a Linux RedHat 5, 64 bits box using the command “pgdbg”.
Pierre-François
Hi Pierre-François,
My only guess at this point is that there’s an odd character in your LD_LIBRARY_PATH (maybe a space?) that’s causing the problem.
What I’d like you to do is
Please post the output of #2 and #4 and let me know which shell you’re using.
Thanks,
Mat
Matt,
Sorry for the late answer. Here are the outputs you required:
LD_LIBRARY_PATH=/cea/home/ldg/pr604419/lib/:/cea/home/ldg/pr604419/lib/mtspec/libraries/:/cea/home/ldg/pr604419/PROFON/lib:/cea/dase/produitsdase/lib/RHEL_5__x86_64:/usr/lib:/cea/home/ldg/pr604419/lib/fftw/lib:/usr/local/qt4/4.4.1-gcc/lib:/usr/lib/xorg:/usr/lib64/xorg:/usr/local/libre/lib:/usr/local/libre/lib64:/usr/lib64:/usr/local/gmt-4.1.3/lib:/usr/local/jre-1.6.0_12/lib:/usr/local/oracle-client-admin-10g/RHEL_5__x86_64/lib:/usr/local/oracle-client-admin-10g/RHEL_5__x86_64/lib32
Then, from within pgbdg, setenv LD_LIBRARY_PATH returns :
/cea/produits1/pghpf-8.0/linux86-64/8.0-1/bin/…/lib
It appears that this path doesn’t exist in LD_LIBRARY_PATH.
Thank you for your help.
Pierre-François
Hi Pierre-François,
I sent this on to one of our tool engineers. Unfortunately, he’s not able to reproduce the problem either and is as puzzled as I am.
His questions for you are:
Is there is a “.pgdbgrc” file in your home dir or the working directory that is overwriting LD_LIBRARY_PATH?
The pgdbg “driver” is just a /bin/sh shell script. Do you use some bash configuration or environment variable to specify a shell initialization file that might be overwriting the LD_LIBRARY_PATH?
Thanks,
Mat
I have not been able to reproduce it like this, but there may be a way.
[/quote]
Hi Matt,
Well, I do happen to have a .bashrc in my home dir that adds relevant paths to my LD_LIBRARY_PATH. However, I could not find a .pgdbgrc in either my home directory or my working directory.
Do you think the pgdbg shell scripts doesn’t see my own environment variables?
Thanks for your help.
Pierre-François
Hi Pierre-François,
This just reminded me of a time several years ago when I wrote script to launch an application. It worked fine when I ran it from the command line but failed when I put it into a crontab. Like you, it failed because my LD_LIBRARY_PATH wasn’t being set.
It turned out that I had added my “setenv LD_LIBRARY_PATH …” (I use csh) after the following code in my .cshrc file:
##
## Exit if not interactive
##
if (! $?prompt) then
exit $status
endif
In other words, since my cron job was not interactive, everything after this point in the script was not being set. Could the same thing be happening here?
Hello Mat,
Well, thanks for the hard work.
There is no such thing in my .bashrc. I also checked in the /etc/bashrc but it doesn’t seem like there is an exit on non-interactiveness nor a different LD_LIBRARY_PATH set in that case.
Sorry - it could have been a solution!
Pierre-François
Hi Pierre-François,
Can you please send your “.bashrc” to PGI Customer Service (trs@pgroup.com) and ask them to send it to me? Maybe we can then recreate the problem here.
Thanks,
Mat
Mat,
Alright, I’ll do that, although I doubt you can recreate the exact same environment configuration.
Thank you very much for your help anyway!
Cheers,
Pierre-François
Hi Pierre-François,
As a workaround you could try setting LD_LIBRARY_PATH in a .pgdbgrc file.
In the .pgdbgrc file you would use the setenv command, for example:
setenv LD_LIBRARY_PATH /lib:/usr/lib:/home/me/lib:/foo/bar/lib
The .pgdbgrc file can go in your home directory, in which case it will affect all PGDBG sessions for that user, or in the ‘current directory’ where you invoke pgdbg, in which case it will only affect sessions invoked in that directory.
Obviously this is not a final solution but perhaps it can help you make progress.
–Don
Hi Don,
Well, thanks for the workaround. It works fine.
Could you keep me posted with a possible explanation on why the debbuger won’t take into account my LD_LIBRARY_PATH?
Thanks!
Cheers,
Pierre-François
Pierre-François
One possible cause of what you are seeing is if you are running the debugger with elevated privileges. This might occur if you are running the debugger using sudo or su, or if the file permissions for the debugger executable(s) have been changed so that they have the setuid or setgid bit set.
You could check the setuid/setgid issue by running
ls -l /opt/pgi/linux86-64/10.2/bin/pgd*
and checking for the letter ‘s’ in the file permissions. There should only be rwx permissions for these files on Linux.
On Mac OSX the executable “pgdebug” is run using setgid “procmod” permissions, but this is not required, nor desirable, on Linux.
–Don