"Alternatively, you may set the environment variables SDL_CFLAGS
and SDL_LIBS to avoid the need to call pkg-config."
Does anyone now how to set these environment variables in GNUStep for Windows.
I'm not familiar with GNUStep, but in Unix-like platforms environmental variables can be set in the shell (using your terminal), as:
For a single run of mycommand:
SDL_CFLAGS=foo SDL_LIBS=bar mycommand
To make it last for all commands until the terminal is closed:
export SDL_CFLAGS=foo
export SDL_LIBS=bar
Related
On my computer when starting a shell in GDB it would give a very standard shell (looks like "bash-4.4$")- ignoring most of my environment variables. The real problem for me is I cannot adjust the LD_LIBRARY_PATH variable because of this reason.
More posts on SO suggest to check .bashrc and .profile, I did that. I even created a new user and the problem persist. So some script is loaded by GDB changing my PS1 and unsetting LD_LIBRARY_PATH. However, I have no idea which process. For some reason Root does not have this problem.
This works:
delruej#delxps:~$ export LD_LIBRARY_PATH=Hello
delruej#delxps:~$ bash
delruej#delxps:~$ echo $LD_LIBRARY_PATH
Hello
However this does not:
delruej#delxps:~$ export LD_LIBRARY_PATH=Hello
delruej#delxps:~$ gdb
(gdb) shell
bash-4.4$ echo $LD_LIBRARY_PATH
It should be some script loaded by every user, but not by root.
So some script is loaded by GDB changing my PS1 and unsetting LD_LIBRARY_PATH
No. GDB just loads your $SHELL, and your $SHELL unsets these environment variables for some reason.
You should look at values of $SHELL and possibly $ENV.
Note that:
Using LD_LIBRARY_PATH is generally a mistake; you should strive to build your programs such that they don't require it.
You can set any environment variable inside GDB (you don't have to inherit them from parent shell) with (gdb) set env FOO bar.
I purged GDB, removed /usr/share/gdb/, reinstalled and the problem was fixed.
When i tried to run following python code:
setlocale(locale.LC_ALL,"")
print getlocale()
The result is that it works fine if i run the script from Terminal.
But in eclipse/pydev with the same python compiler(python 2.7),it always return (none,none), any idea?
As you have already guessed from our conversation in the comments, this behavior is related to the environment. If you run Eclipse from the Terminal, you will get the same results you get when running Python directly from the Terminal.
So, your program is actually working fine. Depending on what you want to do, you don't need to worry about anything.
However, if you want to reconfigure your environment (system-wide or for all programs launched from the GUI, for example), you can do that in the appropriate files, using this answer as a guide.
For example, you may want to set the variables LANG and LC_ALL in one of those files, mimicking the configuration that is shown when you run the command locale from the Terminal. Assuming you want en_US with UTF-8, that added lines would look like:
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
I'm trying to debug a CUDA program, but when I'm launching gdb like so:
$ gdb -i=mi <program name>
$ r <program arguments>
I'm getting:
/home/wvxvw/Projects/cuda/exercise-1-udacity/cs344/HW2/hw:
error while loading shared libraries: libcudart.so.5.0:
cannot open shared object file: No such file or directory
Process gdb-inferior killed
(formatted for readability)
(I'm running gdb using M-xgdb) If that matters, then CUDA libraries are in the .bashrc
export PATH="/usr/local/cuda/bin:$PATH"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"
error while loading shared libraries: libcudart.so.5.0
This error has nothing to do with GDB: your executable, when run from inside GDB, can't find the library it needs.
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"
GDB runs your program in a new $SHELL, so that should have worked. I wonder if there is some interaction with emacs.
In any case, this:
(gdb) set env LD_LIBRARY_PATH /usr/local/cuda/lib64
(gdb) run
should fix this problem.
Update:
as I've mentioned it before, ld path is set properly
No, it isn't. If it was, you wouldn't have the problem.
Now, I don't know why it isn't set properly. If you really want to find out, start by running GDB outside emacs (to exclude possible emacs interactions).
If the problem is still present, gdb show env, shell env, adding echo "Here" to your ~/.basrc, etc. should help you find where things are not working as you expect them.
I've had this problem as well. One way to look at it is that even if the LD_LIBRARY_PATH variable is correct when you enter show env into gdb, it may not be correct when you actually execute the program because gdb executes $SHELL -c <program> to run the program. Try this as a test, run $SHELL from the command line and then echo $LD_LIBRARY_PATH. Is it correct? If not, then you probably need to add it to your rc (.tcshrc in my case).
I had a similar problem when trying to run gdb on windows 7. I use MobaXterm to access a Linux toolbox. I installed gdb separately from http://www.gnu.org/software/gdb/ . I got it to work by making sure gdb could find the correct .dll files as mentioned by Employed Russian. If you have MobaXterm installed the .dll files should appear in your home directory in MobaXterm/slash/bin.
gdb however did not recognize the LD_LIBRARY_PATH variable. For me, it worked when I used the PATH variable instead:
(gdb) set env PATH C:\Users\Joshua\Documents\MobaXterm\slash\bin
(gdb) run
I would think using PATH instead of LD_LIBRARY_PATH might work for you provided you put the correct path to your library.
gdb is looking for a library, so why are you concerned with the include path? You may want to try to set the gdb option "solib-search-path" to point to the location of the libcudart.so.5.0 library.
I am running a Windows 7 system where i want to be able to set a system environment variable and be able to see it in subsequent command prompts that i launch.
When i set the system environment variable using "setx" thins work fine, But given that i want to use the same script code for XP and Windows 7 I cannot do this on XP because XP does not come by default with setx.
So i have to resort to using WMI to set the environment variables:
I use this following code to set the variable :
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set objVariable = objWMIService.Get("Win32_Environment").SpawnInstance_
objVariable.Name = "TestKey"
objVariable.UserName = "<System>"
objVariable.VariableValue = "TestValue"
objVariable.Put_
But now, when i launch a new command prompt, the environment variable does not take effect;
However if i restart the system it takes effect; And when i go to MyComputer>Properties>Advanced System Settings> Environment Variables, then i see the "TestKey" value present there; And when i hit "OK" button there and then launch a new command prompt, the "TestKey" value seems to magically appear;
Is there someway I can make the system environment variable to appear on the subsequent command prompts without resorting to clicking on OK at the environment Variables Window (in System Properties) or restarting the machine?
You can install the Windows XP Service Pack 2 Support Tools, which does include setx. We've been using it for a couple years to easily switch on development environments between different levels of Java, Weblogic, JBoss, etc because we support many different version.
Hope this helps!
I'm using the Win32 function GetEnvironmentVariable to retrieve the value of a variable that I just created. I'm running Windows XP and VC++ 2005. If I run the program from within Visual Studio, it can't find the new variable. If I run it from a command-prompt, it does. I restarted VC++ but same result. I even restarted all instances of Visual Studio but still the same problem. It might get resolved if I reboot the PC but I'm curious why this is so. Here's the code that I'm using:
#define BUFSIZE 4096
#define VARNAME TEXT("MY_ENV_NAME")
int _tmain(int argc, _TCHAR* argv[])
{
TCHAR chNewEnv[BUFSIZE];
DWORD dwEnv = ::GetEnvironmentVariable(VARNAME, chNewEnv, BUFSIZE);
if (dwEnv == 0)
{
DWORD dwErr = GetLastError();
if(dwErr == ERROR_ENVVAR_NOT_FOUND)
{
printf("Environment variable does not exist.\n");
return -1;
}
}
else
{
printf(chNewEnv);
}
return 0;
}
If I replace MY_ENV_NAME with something that must exist, such as TEMP, it works as expected. Any ideas? Thanks.
Expanding on what Anders and Martin said, environment variables are one thing that is inherited when starting an application. The new program basically gets a copy of the environment at the time it was started. When debugging, your exe is generally started by Visual Studio, so your application will have the same environment as Visual Studio. Visual Studio, is generally started by explorer. If you change the environment variables by going to System Properties->Advanced->Envronment Variables then you will have to restart Visual Studio to see the changes.
If you need to see the envronment variables that Visual Studio is seeing you can (at least for VS2005/2008) go to Tools...->options...->Projects and Solutions->VC++ Project Settings and set Show Environment in Log to 'Yes.' This will print out all the environment variables to the build log (ctrl+click on the link in your build output). You have to build to get this info, but this is the best way I know of seeing the VS environment.
If you really need to change environment variables then run and are having a hard time debugging, you can build your debug exe and have a call to DebugBreak() somewhere near where you want to start debugging from. Then you can set your environment how you want, start the exe from explorer or the command prompt. Then (assuming you have JIT debugging enabled) you will get a popup when your code gets to the DebugBreak() call and you can attach to it with VS and debug normally from there.
Make sure you restart the application before you can read the environment variable. The same happens if you have a console window open and change the environment variables on My Computer, these are not noted in any existing console windows. You need to restart them to get a copy of the new environment variables.
It all depends on how you set the environment variable:
If you ran set MY_ENV_NAME=val in a command prompt, then you have set MY_ENV_NAME for that instance of cmd.exe and any child processes it executes in the future. The environment of existing child processes is not modified.
In this case, exiting the Visual Studio IDE and starting it from the command line (not Explorer) should cause it and its child processes to see the new environment variable.
If you used the System or Users control panel or the setx command to set MY_ENV_NAME, then you have set MY_ENV_NAME persistently, and it will be set for all processes after you reboot your computer. In addition, you may find that some processes, such as Explorer, pick up the environment variable change immediately.
This works by storing the new environment variable in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment or HKEY_CURRENT_USER\Environment, depending on whether you chose to set a system environment variable or a per-user environment variable. Existing processes are notified that there was an environment variable change by broadcasting the WM_SETTINGCHANGE message with lParam=="Environment". This message causes them to re-read the persistent environment variables from the registry if they know how. KB104011 has more details.
As a result, if you use the System or Users control panel to set a new environment variable, exiting the Visual Studio IDE and starting it again from Explorer (not a command prompt) should cause it and its child processes to see the new environment variable.
Thanks for all the responses. As I mentioned in my question, I tried restarting everything, short of rebooting the PC. It turns out that because my environment variable was a SYSTEM variable, VS doesn't recognize it without rebooting the PC. When I moved the env variable from SYSTEM to USER and restarted VS, it worked fine.