First Method (export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH):
Based on this method, I can compile h5_crtdat.f90 through "gfortran h5_crtdat.f90 -fintrinsic-modules-path /usr/local/include -lhdf5_fortran" successfully. And I can run it as well.
Second Method (-Wl,-rpath):
Based on this method, I can compile h5_crtdat.f90 through "gfortran h5_crtdat.f90 -fintrinsic-modules-path /usr/local/include -lhdf5_fortran -Wl,-rpath,/usr/local/lib" successfully. However, after type in "./a.out" I got the following error
"./a.out: error while loading shared libraries: libhdf5.so.200: cannot open shared object file: No such file or directory".
Questions:
I have searched the google that these two methods can produce the same effect when linking shared library in gfortran compiler. Thus, I do not know why I will get the errors when the second method is used.
These two serve a different purpose.
LD_LIBRARY_PATH says where to search for shared libraries when executing some executable that has already been compiled and linked. It is possible, but not guaranteed, that some linker will alsonconsider this path for the actual linking, but there are other variables, like LIBRARY_PATH for that.
-Wl,-rpath says where to link shared libraries when building the executable. It has no effect when running the executable.
You must set LD_LIBRARY_PATH or some equivalent when running the executable so that the necessary libraries for the run can be located.
Related
Lua's ffi.load("library") results in a cannot open shared object file: No such file or directory error.
As a temporary solution I can provide the absolute or relative path to the library.
Eg. ffi.load("./liblibrary.so").
I've read that LUA_PATH and LUA_CPATH need to be set.
Eg:
export LUA_PATH="$PWD/src/?.lua"
export LUA_CPATH="$PWD/lib/?.so"
Setting LUA_PATH enables me to "require" lua files from other directories, but LUA_CPATH doesn't seem to help with loading shared objects.
ffi.load uses the normal dlopen mechanism of your operating system.
On Linux, this means that you need to add your libraries path to the LD_LIBRARY_PATH variable.
Once LD_LIBRARY_PATH is set, Lua is able to find the library.
I found this answer helped me debug my situation by printing any matching libraries on LD_LIBRARY_PATH.
Relevant FFI documentation
I have a working version of my project in eclipse.
I exported the project as a runnable jar.
Extracted (after converting to .zip)and tried to compile a particular java file from the command prompt
(Doing it this way since I have a project requirement, where input parameter inside that particular file can be modified and recompiled/run by users who wont have Eclipse)
I have used some external libraries( for Eg:json-simple,gson etc).They arent getting recognized , during compilation.
But if I run the class file(from the Eclipse compiled version), it gets executed properly
a)Tried to compile from root folder(using package name)
javac packageName.javaFileName.java
b) and went inside the package and compiled directly.
javac javaFileName.java
The a)part didnt compile at all saying classNotFound. The b)part started compiling but threw an error where none of the external libraries got recognized.(Getting --> error: cannot find symbol for places wherever the code/import of the external lib is used)
a)Tried to compile from root folder(using package name) javac
packageName.javaFileName.java b) and went inside the package and
compiled directly. javac javaFileName.java
The a)part didnt compile at all saying classNotFound.
Yes. javac requires you to specify a filesystem path to the (first) source(s) to compile. You appear instead to have tacked .java onto the end of the desired fully-qualified class name. Probably you want to compile from the root of the unpacked jar, specifying a correct path:
javac [options] package/name/className.java
for class package.name.className. (You can also compile from a different working directory if you specify an appropriate option, as discussed below.)
The b)part
started compiling but threw an error where none of the external
libraries got recognized.(Getting --> error: cannot find symbol for
places wherever the code/import of the external lib is used)
If the class you're compiling depends on others that also need to be compiled then javac would likely make a similar complaint about them. Either compile from the root (as in (a)), or specify the path to the source root via the -sourcepath option. Either way, there's no reason to descend into the source tree to compile.
But the external libs are actually a separate, albeit related, question. You don't need to compile these, but you do need to tell javac to use them as sources of classes. You would do that via the -classpath option, which you can abbreviate to -cp. If those were packaged in the jar itself (i.e. a "fat jar") then that should be fairly easy, something along these lines:
javac -cp .:lib/dependency1.jar:lib/dependency2.jar package/name/className.java
The "lib" part may vary, and the separator definitely differs depending on OS (on Windows it is ;, whereas on Mac / Linux / Solaris is is :, as shown).
If the external libs were not packaged into the main jar then the procedure is the same, but you might have a bigger challenge finding the needed jars. Also, such a jar is probably not runnable if you move it to a different machine. Nevertheless, you should probably look in META_INF/MANIFEST.MF, as it should contain the needed information.
I have checked out the current tip-of-tree from the various Clang 'git' mirrors as described in the getting started page here:
http://llvm.org/docs/GettingStarted.html
I then follow the instruction to generate the make files using CMake, like so:
cmake -G 'Unix Makefiles' /Path/To/LLVM-Repository
This fails to configure with the following error - what is going wrong?
CMake Error at tools/clang/CMakeLists.txt:480 (add_custom_target):
add_custom_target cannot create target "install-libclang-headers" because
another target with the same name already exists. The existing target is a
custom target created in source directory
"/Users/alisdairm/Repositories/llvm/projects/clang/tools/libclang". See
documentation for policy CMP0002 for more details.
This is most likely a double-checkout of the Clang repository, once into the llvm/tools directory (correct) and a second into the llvm/projects directory (error).
The solution is to delete the copy of the Clang repository in the llvm/projects directory, and then everything should configure and build correctly.
I want to compile the GTK+ test program for the Vala programming language. I saved the code as main.vala and call the compiler with the command line
valac --pkg gtk+-3.0 main.vala
But this does not work. I get the error:
Package gobject-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gobject-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gobject-2.0' found
error: pkg-config exited with status 1
Why can't pkg-config find that package? When I call
pkg-config --list-all | grep gobject-2.0
I do not get an error, but
gobject-2.0 GObject - GLib type, Object, Parameter and Signal library
So my question is, why doesn't the program compile?
It's hard to figure out what is going on based on the information you've provided—you're probably going to have to figure it out yourself. I'll try to include some pointers here. A good place to start would be to set the PKG_CONFIG_DEBUG_SPEW environment variable…
The most likely cause is that some environment variables and/or the pkg-config being invoked are different. It's hard to say exactly how they might be different, but all valac is doing is invoking pkg-config.
In order to determine which pkg-config to execute, valac first looks for the --pkg-config command line option or, if that isn't present, the PKG_CONFIG environment variable (see compiler/valacompiler.vala for the logic). If that isn't present, it will just invoke pkg-config (that part is in codegen/valaccodecompiler.vala, the Vala.CCodeCompier.compile method).
From there, pkg-config takes over. The pkg-config man page explains how it searches for files; basically the PKG_CONFIG_PATH. Again, enabling debug spew would probably be the best place to start.
I'm using cmake and make to compile a project using an external library (speex).
This library is found by the find_library command in my CMakeLists.txt.
The only problem is: the default include path of cmake does not include /usr/local/include/, that is the location of speex's headers.
I do not want to add /usr/local/include/ to the search path in the CMakeLists.txt because it would (I suppose) generate an error on windows where such path doesn't exist.
Moreover, that would be a dirty trick, I'm not quite fond of this solution.
Do you know a solution to this problem which would be portable and clean ?
Thank you for your time.
Try using a full-blown speex find module, either created from scratch, or based on something found with http://www.google.com/search?q=findspeex.cmake
Punt the configuration to the user via the command line, e.g.
cmake -DSPEEX_PATH=/usr/local/include
Use the PATH argument of find_library to specify other places to search. If the path doesn't exist it shouldn't produce an error.