This is a follow up to this previous question of mine.
Here is the (simplified) location in that qmake script that causes problems (I'm currently testing only this particular library but I've also checked and the same issue is present with the others too):
VTK_API = ""
CONFIG(debug, debug|release) {
message(Application will be built in DEBUG mode)
VTK_API = $$(VTK_DBG_DIR)
}
else {
message(Application will be built in RELEASE mode)
VTK_API = $$(VTK_DIR)
}
I've moved my qmake project file to Linux to check how it's working there. And for my surprise the environment variables are not read properly that is when I output the value from the given variable it's empty. I've adjusted the paths for both versions of the library since I have a different naming of the respective environment variables (in .bashrc) that point at the location of its debug and release builds.
user#debian:~$ echo $VTK_DBG_DIR
/opt/vtk-dbg/lib
user#debian:~$ echo $VTK_DIR
/opt/vtk/lib
As you can see the variables are properly echoed in my terminal. I also have to add that I start my Qt Creator from my bash terminal due to some other things that I want loaded along with the IDE so the case "Your variables are not read since Qt Creator doesn't read what's in your .bashrc" is not present here.
Any idea what's going on here? Is there a difference in the way the loading of environment variables works in qmake based on the operating system or am I missing something else here (an error in my script perhaps)?
Related
I have a strange behavior on an embedded linux system. It is created from an image file and has been used on many system for about a year without any issues. But a new system that I installed just now fail to work.
I have an app that is started by one of the boot scripts, and is dependent on a library foo.so in a special path.
So the script sets LD_LIBRARY_PATH to foopath.
LD_LIBRARY_PATH=foopath \
foo.app
But after boot I can see that the app was never started and if I try to start it manually it complains that it can't find the library.
The strange thing is that I can get it to work by setting the same path again by just copying the path using the clipboard, like this:
$ echo $LD_LIBRARY_PATH
foopath
$ export LD_LIBRARY_PATH=foopath
After this my app will find the library and executes correct.
But if I reboot the system the problem is of course back again.
What could be wrong, and what can I do to solve the issue?
As seen in the comments I got it to work by changing my script like this, but I still can't understand why it works on some systems, but not all.
export LD_LIBRARY_PATH=foopath
foo.app
I'm using CLion IDE, Cmake and trying to write Hello world using CERN ROOT library.
CMakeLists.txt:
message(STATUS $ENV{ROOTSYS})
~/.bashrc:
export ROOTSYS="$HOME/tools/root-build/"
During build in CLion $ENV{ROOTSYS} is empty by some reason. But $ENV{PATH} returns correct $PATH.
What I did wrong?
Variables from .bashrc aren't passed.
Go to File -> Settings -> Build,Execution,Deployment
For Clion 2017.2+
For old Clion
Click Pass system and...
If you want to read environment variable in C++ runtime e.g. using std::getenv then
it won't work as we added environment variable for CMAKE not for runtime.
You can add such variable:
And then in your code:
std::filesystem::path getRootConfigPath()
{
// std::getenv can return nullptr and this is why we CAN'T assign it directly to std::string
const char* path = std::getenv("TEST_CONFIG_DIR");
gcpp::exception::fail_if_true(
path == nullptr, WHERE_IN_FILE, "No such environment variable: ${TEST_CONFIG_DIR}");
gcpp::exception::fail_if_true(std::string_view{path}.empty(),
WHERE_IN_FILE,
"Missing ${TEST_CONFIG_DIR} environment variable");
const std::filesystem::path testConfigDir{path};
gcpp::exception::fail_if_false(std::filesystem::exists(testConfigDir) &&
std::filesystem::is_directory(testConfigDir),
WHERE_IN_FILE,
"Invalid ${TEST_CONFIG_DIR} dir:" + testConfigDir.string());
return testConfigDir;
}
Source of gcpp::exception::fail_if_true
Other way to do this in more friendly way when running unit tests is add this variable to template.
So whenever you click:
Such variable will be there already.
From CLion developers FAQ:
Q: How to pass environment variables and parameters to CMake in CLion?
A: The best way is to use Preferences/Settings | Build, Execution, Deployment | CMake dialog.
As for .bashrc file, it is only used by bash. CLion doesn't need to use bash for run configuration process.
On Ubuntu 17.04, you can set a permanent environment variable by modifying
/etc/enviornment
[I assume you can do this in other versions of Linux, but I provide the version of the system that I am using.]
For example, I am compiling test cases that assume that ${GOOGLE_MOCK} has been set. I added the following to my /etc/environment file, and now I don't have to rewrite all of my CMakeLists.txt files:
GOOGLE_MOCK=/usr/local/src/googletest/googlemock
GOOGLE_TEST_HOME=/usr/local/src/googletest/googletest
Clion just became much more useable.
One thing you can check is the .gdbinit. Clion on Linux will invoke the gdb, which will read in the .gdbinit. I happen to have set environment LD_LIBRARY_PATH xxx in my .gdbinit file, which will override whatever you set LD_LIBRARY_PATH from shell, whether through direct export or through .bashrc, or from CLion environment variable panel.
Hope this helps.
Source your variables in .profile not .bashrc
I use swig from my within Android.mk. I reference it directly relying on the $PATH variable to contain the path to it's executable.
The issue is that the $PATH variable is different depending on where the android-ndk tool is run from.
Background
In my Android.mk file:
# some stuff ...
#echo "$(PATH)"
swig # swig parameters here...
# more stuff ...
From the terminal, we see the system path includes the path to swig:
which swig
/usr/local/bin/swig
echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:
Issue
When the android-ndk is run from within Android Studio I get the following for PATH (note: it's missing the swig path):
/usr/bin:/bin:/usr/sbin:/sbin
This causes my build to fail because "swig" isn't recognised:
make: swig: Command not found
However, if I run the android-ndk directly from the terminal, then the PATH used is the same as my system path and the build works fine:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:
Bad solution
Yes, I could add the path manually to my Android.mk file:
export PATH:=/usr/local/bin/:$(PATH)
However, I'd prefer not to define specific paths for my machine knowing that the whole team uses this file.
Question
I'd prefer the Android.mk file to use my systems PATH instead.
Any ideas how to do this?
Thanks!
The thing in my opinion is that environment variables may be different whether the process is launched from terminal or from the GUI (launchpad, spotlight, ...).
The former would use PATH as set in bashrc (or other shell related startup files) while the other will not.
I think you might find interesting information on how to change the environment variables for the launch deamon in the following question:
Setting environment variables in OS X?
I have a Perl program that someone else created and I am calling on with CruiseControl. The program calls on Unix Commands using Cygwin. However, everytime that the Perl program calls on a Unix like command with a DOS like address, I get the well known error:
cygwin warning:
MS-DOS style path detected: E:\regression
Preferred POSIX equivalent is: /cygdrive/e/regression
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
I have set both the User Variable AND System Variable CYGWIN to nodosfilewarning. This removes the error when I run the program from the command line, but the error still occurs in CruiseControl when called as an automated process from a batch file. I have called on both the batch file from the Desktop AND Command Line and ran as an administrator. Nothing changes.
Other Notes
For purposes of this problem, I don't have access to the Perl Program
I am trying to go back to Cygwin 1.5.*, but since I am using Server 2008, I am encountering compatibility issues
This is occurring on one of the distributed servers, not the main server running the Webdashboard.
I have read somewhere that this issue may stem from a different user calling on CruiseControl, but the issue should have been solved by setting this as an ENV System variable
Is it possible to modify the registery to set the ENV variables?
Thank you in advance
The way I do it is like this
printf 'export CYGWIN=nodosfilewarning' >> ~/.bash_profile
If CruiseControl is connecting to the server via ssh, reinstall sshd and explicitly include nodosfilewarning when prompted for the CYGWIN environment variable during the install.
Re-installing with modified environment will work but if you don't want to or cannot re-install, an alternative is to change the registry instead of re-installing the service.
See: CYGWIN windows cygrunsrv sshd server and MS-DOS style path detected
I am building a Linux system with cross-compiler using ptxdist. It allows me to configure Qt4 for installation and it builds and installs qt-everywhere-opensource-src-4.6.3 Ok. However, the qmake internal settings are screwed up and I don't know how to fix them.
When I run qmake -query I get:
me#ubuntu:~$ qmake -query
QT_INSTALL_PREFIX:/
QT_INSTALL_DATA:/
QT_INSTALL_DOCS://doc
QT_INSTALL_HEADERS://include
QT_INSTALL_LIBS://lib
QT_INSTALL_BINS://bin
QT_INSTALL_PLUGINS://plugins
QT_INSTALL_TRANSLATIONS://translations
QT_INSTALL_CONFIGURATION:/etc/xdg
QT_INSTALL_EXAMPLES://examples
QT_INSTALL_DEMOS://demos
QMAKE_MKSPECS://mkspecs
QMAKE_VERSION:2.01a
QT_VERSION:4.6.3
Through some research, it looks like this can be fixed by simply rebuilding Qt, but it's not fixing this problem. I dug into the build output a bit and it looks like the ./configure command for the Qt build has "-prefix /usr" so I don't know why this isn't being fixed.
I would like to fix these internal values manually if possible because the Qt build takes hours. Does anyone know how to do this?
At configure time these paths are hardcoded in 'src/corelib/global/qconfig.cpp', and end up hardcoded into qmake when it is built. They are also hardcoded into many other files, like all the .la and .pc files, not to mention the Makefile install rules.
The only way to fix this is to figure out why configure keeps screwing up the prefix. configure is a big shell script, so it's easy to see where $QT_INSTALL_PREFIX is assigned from the '-prefix' argument, and then the different checks that are done on it (like running it through 'config.tests/unix/makeabs'). Try putting print statements before/after $QT_INSTALL_PREFIX is changed, and you should be able to find out where the path gets screwed up.
Also, you don't have to wait for the full build to complete to tell if the prefix was set
correctly. After configure runs, take a look in 'src/corelib/global/qconfig.cpp' and see what 'qt_configure_prefix_path_str' is set to.
You can manually set these properties using
qmake -set VARIABLE VALUE
They are stored using QSettings, the Qt built-in persistent applications settings.
see Configuring qmake's Environment
Configure scripts can be fuzzy about slashes. Are you sure that the build prefix is /usr and not /usr/ .