I'm using starkit/starpack with tcl8.5 and expect 5.44.1.15 under linux, after creating the starkit and putting the directory for expect under lib directory of the created vfs directory and wrap it back to starkit file, I could create the starpack file, after checking that everything's working fine on my linux system, I use this standalone file on another linux system but there, it doesn't work and I have this error :
couldn't load file "/tmp/tclJ4M144": /lib/libc.so.6: version `GLIBC_2.7' not found (required by /tmp/tclJ4M144)
so trying to solve this, I've removed expect 5.44.1.15 directory from vfs directory and replaced it with expect 5.43 taken from the target linux system (where my standalone starpack file didn't work), I've also adapted its pkgIndex file before recreating the starkit and then the starpack, but this time I have this error :
segmentation fault
Anyone can help me on this ? What do I need to do to make it work on the target linux system ?
Thank you.
Related
Does anyone know how to delete those past working directories in Octave GUI? They are very annoying and useless.
I see from your image that you are on windows.
I don't know the equivalent directory on windows, but on linux, this information seems to be stored under ~/.config/octave/octave-gui.ini, in a section called current_directory_list which you can edit and clear of all unwanted entries.
See if you can find the equivalent folder where this octave-gui.ini file is stored on windows; it may be in an AppData/Local directory, or in the octave installation folder itself...
PS: In the same directory I also had a qt_settings file which seems to mirror some of this information, but I think this may have been from an older octave installation.
In addition to deleting the file path from octave-gui.ini, try removing the path from .octaverc file as well. This will remove the warning you see at launch if the path no longer exists.
For some time, I've been using some .mex files I created. Now I have a new computer. I copied all the files over and reinstalled Cygwin and Octave. When I try to execute any of the .mex routines I get a message like:
error: testm: /cygdrive/c/A/Cwin/...../quad.mex: failed to load: No such file or directory
The file is definitely there and I'm having no trouble loading .m files from the same directory. It does not say there is anything wrong with the file. I'm guessing this is some sort of configuration problem. I am running Octave 4.2.1. When I start it, I get the following message:
Octave was configured for "x86_64-unknown-cygwin".
Could that have something to do with it? I think I'm developing x64 paranoia, since all my Excel .dll macros no longer work either. Thanks.
I'm new to servers and programming in general, and I have a question regarding remote acces to a server, and how much I can actually do on it.
The thin is I have a working program on a linux server, which I acces with my windows machine using mobaxterm. I can acces the server, I see folders and a cmd line, where I can compile a makefile. Everything runs well, however when I run the makefile it just compiles, and doesn't do anything. No error messages, but also no opening of a program. I don't understand anything. Is it a delimitation of the servers structure, that it can only store files on it?
When you compile under linux using a make, it produces an executable but does not run it. Make builds executable objects, but it does not run them. You should include your makefile in the question (reduced to a minimum if it is large). Inside it, you will see that it generates a executable file with a specific name. To run it, you need to invoke this from the command line.
To find out what it is building, a quick way is to type "make clean" (press enter of course) to clean up any built objects. Then type the "ls" command to see what is in your directory.
Next, build the program with the "make" command, then type "ls" to see what has been added. Ignore any new files that end in .o or .a or .so and look for any new files. These are the files built by make and at least one of them is the program you built.
Assuming you found a new file called "myprogram". To run it, type:
./myprogram
I've installed caffe on a server a while ago, and back then it worked properly.
Now I'm following the LeNet MNIST tutorial again (http://caffe.berkeleyvision.org/gathered/examples/mnist.html), and running
./examples/mnist/create_mnist.sh
returns
build/examples/mnist/convert_mnist_data.bin: error while loading shared libraries: libglog.so.0: cannot open shared object file: No such file or directory
I've noticed that liibglog.so.0 is not in /lib which might be the reason for it, but I'm not allowed to copy that file into /lib directory, since I'm not a root user.
Is there workaround for this?
The easiest way to work around the lack of shared libraries in system directories is to use LD_LIBRARY_PATH with the directory where the shared library lives.
Before running the the command that requires a library, run the following in the following the same shell.
export LD_LIBRARY_PATH=~/local/lib
You can also stick this in your .bashrc for convenience.
An alternate solution is to use the following command line flag while compiling, but that requires mucking with other people's build scripts.
-Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)
I am trying to install RMySQL on my mac (mavericks) and it errors out when I try to build it from source, saying:
Configuration error: could not find the MySQL installation include
and/or library directories. Manually specify the location of the
MySQL libraries and the header files and re-run R CMD INSTALL.
INSTRUCTIONS:
Define and export the 2 shell variables PKG_CPPFLAGS and PKG_LIBS to include the directory for header files (*.h) and
libraries, for example (using Bourne shell syntax):
export PKG_CPPFLAGS="-I"
export PKG_LIBS="-L -lmysqlclient"
Re-run the R INSTALL command:
R CMD INSTALL RMySQL_.tar.gz
I tried to follow the instructions by entering:
export PKG_CPPFLAGS="-I/usr/local/mysql/include" export
PKG_LIBS="-L/usr/local/mysql/lib -lmysqlclient"
but when I re-run RMySQL it still doesn't work. Moreover, if I type
$PKG_LIBS
to see what that variable holds, I get
-bash: -L/usr/local/mysql/lib: No such file or directory'
I know that /usr/local/mysql/lib exists and it does contain a mySQL header. Am I misunderstanding the instructions?
I'm asking here only after a lot of effort to find solutions and/or work arounds. Sucks being a noob sometimes.
I am going to assume you're trying to get RmySQL to run on R 3.1.0 on Mavericks? Rather than worry about exporting variables etc, here is a simple clean solution for you that should avoid the headaches.
The RMySQL install link Pascal provided above really is your solution. You're probably just stumbling on syntax, or getting things to work from the terminal.
Even if you're a "noob", you should be able to get this working. I'll try to offer a "dummy's guide" walk through here, as I bet there are many others who have this problem too, even after trying to read the RMySQL installation readme.
I would bet with very high confidence the problem is just that you aren't specifying correctly the locations of the library and header folders for compiling. Read the errors carefully when you try to compile... the errors will probably tell you a file/header is missing, or some .so file (shared object) is missing.
One simple way compile RMySQL from source on R 3.1.0, mavericks is as follows (this does not require you to set any environmental variables, no editing of the Renviron file, etc):
Does MySQL work by itself? i.e. Can you open/run it no problems? If not, fix that first.
Find the precise location of your mysql installation. For me, on Mavericks, I see mysql installed at /usr/local/mysql-5.6.17-osx10.7-x86_64 (your version number may be different). There is also another folder /usr/local/mysql which is an alias to /usr/local/mysql-5.6.17-osx10.7-x86_64 (/usr/local/mysql finds the current version of mysql you are using, if multiple mysql file folders exist, I think). In this directory, I see two sub directories (among many) called "include" and "lib". Take a look; "include" will contain header files (include as in #include , etc, in simple C++ programs). The "lib" folder contains compiled source code of the mysql library.
An easy way to compile and install RMySQL which doesn't exactly follow the suggested way to do it in the installation guide is this. Note that this is doing the same thing as in the installation guide, just a little easier as it's one command line from the terminal, once you know where your mysql install folder is. Go to the terminal, and type the following exactly, with one space between each chunk (with your mysql folder name adjusted appropriately for the version number):
PKG_CPPFLAGS="-I/usr/local/mysql/include/" PKG_LIBS="-L/usr/local/mysql/lib/ -lmysqlclient" R CMD INSTALL RMySQL_0.9-3.tar.gz
OR (the same thing, just more typing)
PKG_CPPFLAGS="-I/usr/local/mysql-5.6.17-osx10.7-x86_64/include/" PKG_LIBS="-L/usr/local/mysql-5.6.17-osx10.7-x86_64/lib/ -lmysqlclient" R CMD INSTALL RMySQL_0.9-3.tar.gz
Note for dummies: Make sure when you run this command, that you are doing it from the terminal in the directory that contains the RMySQL_0.9-3.tar.gz file (or whatever the name of your folder is that contains the RMySQL source code)
and RMySQL compiles!
Don't be afraid about trying to compile source code -- it's not just for 'compiled language programmers' or 'computer science graduates'. Most of the time when compiling fails it's just because files are "missing" (there is no corruption on the source code) -- the user hasn't properly specified the locations of the header and libraries (shared objects). Now pull your big boy/girl panties up and just do it .... it's easy.
Notes for people clueless about compiling source code for packages in R:
a) pay special attention to the spacing in the above, otherwise it may not work. Do not have any spaces between the = and the variable/file names (e.g. don't try and have in the above PKG_CPPFLAGS ="-I/usr/local/mysql/include/" as it won't work)
b) When compiling, you want to specify the locations of the header files and the library files and this is what the "-I/ .... " and "-L/ ...." are doing. The -I directory specifies the location of the header files, and the -L the location of the library files. The library files also require the -l[name of library] extension (the -l is short for -lib in the library object names).
c) Note that in the directory /usr/local/mysql-5.6.17-osx10.7-x86_64/lib/ I do not see a file called "lmysqlclient", or even "libmysqlclient", but I do see files named (among others) "libmysqlclient.a" and "libmysqlclient.18.dylib". So don't worry about your MySQL installation not being correct if you don't see a file just called "libmysqlclient" in the lib folder.