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
Related
I'm having the following problem installing Titanium Studio. On my Mac (OSX Yosemite), the terminal shows that I have Node, NPM, Titanium, Alloy etc. all installed and 'callable' from any path. Titanium Studio keeps failing to run because it can't find the CLI.
If I go to Titanium's terminal view, absolutely nothing seems to be installed. Even 'ls', 'cd' etc. cannot be run. Anyone know what I'm missing here? It's like .bashrec never gets loaded or something. Would appreciate any pointers in the right direction,
cheers,
Wittner
Ok. Looks like this had nothing much to do with Titanium and everything to do with my system setup, but this might help others who experience the same symptoms.
Turns out that my .bash_profile was incorrectly set up.
.bash_profile is a batch file which holds information about (among other things) the current path. This file, if it exists, gets run every time terminal is started up. One of my path statements in the file ended without :$PATH
:$PATH concatenates the current path when you are putting a path command in the file e.g.:
export PATH=/etc/bin/
export PATH=/Applications:$PATH
The ':$PATH' at the end of the second statement ensures that the path now contains both /etc/bin/ and /Applications. Without :$PATH, the second line would have set the path to /Applications only, overwriting the /etc/bin/ entry.
So in effect all of the PATH commands before the last one had been overwritten. Terminal could not see where ls, cd or an of those command line tools were. My own terminal worked fine because I had it using ksh (Korn shell) which I had set up with some fancy colours and listing options. When Titanium tried to load a fresh copy of terminal, the PATH was effectively being overwritten and so Alloy, Node etc. where not visible to it.
I fixed up the erroneous PATH statements in the .bash_profile, restarted the app and now Titanium works fine.
I am working in a virtual environment, trying to start open vm tools in a chroot environment.
I tested with bash and it seems to work fine.
I used ./configure --options --prefix=/home/chroot_env to install the program, then using ldd on vmtoolsd, i copied the corresponding libraries to the /lib directory.
Now when I start chroot /home/chroot_env /bin/vmtoolsd, nothing happens, the chroot returns directly. Launching the same binary in the normal environment does work.
Does someone have an idea why it isn't working, the correct libraries are there, and it works with bash.
EDIT : strace showed that vmtoolsd is trying to access /dev/console, I added mount --bind /dev/ /home/chroot_env/dev/ but it is still failing.
EDIT2 : another strace showed it was looking for another plugin loaded dynamically, i added it and it worked, conclusion strace is great for debugging such issue!
When you run a program and nothing happens, you can always run it with strace in order to see which syscalls are made. This is an easy way to obtain the list of the files (regular or not) that are opened. In your case, check that your program doesn't try to access a file that is not in the chroot.
I have a a problem sounds pretty wierd. I compiled a program in Qt and it ran successfully.
But when I navigated to the release folder in the konsole and ran the program (even with super user), it reported :
If 'HelloWorld' is not a typo you can use command-not-found to lookup the package that contains it, like this:
cnf HelloWorld
I checked the permissions, all users can read it.The path is right. I'm out of way.
Please help me!
Note: I use Qt 4.74 on OpenSuse 12.1. Just switched from windows few days ago
I think this ain't relate to the source code, since even a simple HelloWorld program can't run either
If the program is in the current directory, make sure you run it with a prefix indicating so:
./HelloWorld
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/ .
I'm using Netbeans on Linux (Ubuntu 9.04) to build a C project.
How do I pass in an environment variable so that's it's visible to the Makefile?
If I do a normal export MYVAR="xyz" and then run make from the command line this works fine of course.
But Netbeans doesn't seems to use the .bashrc environment, so if I click "build" in Netbeans, the make fails.
Interestingly, the problem doesn't seem to occur on MacOSX - I've added the variable to ~/.MacOSX/environment.plist, and that value is visible to Netbeans.
I found this post which suggested modifying ~/netbeans-6.8/etc/netbeans.conf. I've tried this, by adding -J-DMYVAR=xyz to the end of netbeans_default_options, ie:
netbeans_default_options="-J-client -J-Xverify:none -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m -J-Dapple.laf.useScreenMenuBar=true -J-Dsun.java2d.noddraw=true -J-DMYVAR=xyz"
But this didn't seem to work.
Edit:
This answer is possibly not valid for Unity-based flavours of Ubuntu.
The issue is actually nothing to do with NetBeans - it's related to the Ubuntu (ie Gnome) Launcher.
As this blog post explains, you need to add variables to the rather obscure ~/.gnomerc (No Mercy? :) file in order for them to be passed to applications started with Launcher!
So just edit ~/.gnomerc and add the variables as you would to ~/.bashrc, eg:
export MYVAR="xyz"
and logout/login.