In my project directory, i have:
./external/glew, which has glew compiled from source (ran make)
./external/glfw, which has glfw also compiled from source (ran make x11)
in my .c source code:
#include <stdio.h>
#include <stdlib.h>
#include "external/glew/include/GL/glew.h"
#include "external/glfw/include/GL/glfw.h"
i tried to compile using GCC:
gcc test1.c -o test1 -DGLEW_STATIC -L./external/glew/lib -lGLEW -lGLU -lGL \
-L./external/glfw/lib/x11 -lglfw
./external/glew/lib is where the libGLEW.a is and ./external/glfw/lib/x11 is where the libglfw.a is.
and it compiles without error. but then i try to run ./test1 it gives me:
./test1: error while loading shared libraries: libGLEW.so.1.6: cannot
open shared object file: No such file or directory
how do i compile glew & glfw statically?
EDIT 1 Thanks for the help guys. After some help from people in stackoverflow and old nabble I manage to write it down what needs to be done to statically linked GLFW and GLEW and put it on http://www.phacks.net/static-compile-glfw-and-glew/
Static libraries are not linked with -l… but just added to the linker source files. However please double check you really want to link those statically. The problem you have here is that the dynamic linker on *nix systems will by default only look into the system library directories and the path specified in the LD_LIBARY_PATH environment variable.
However it is possible to add relative linker paths to the executable, where libraries are located, too (--rpath linker option). That way you can ship the libraries in a directory relative to your executable, independently from the system libraries. If you do this, you also should look into binreloc
Related
Hi team,
I have three files which I need to compile for testing, btw im using CentOS linux.
source_code.c
library.h
library.c
how do I put the library.h in the gcc library, so I can use it?
how do I compile the source_code.c to use that library?
Thank you very much.
This is basic knowledge of your tools, but you can do this:
#include "library.h" in the include section of the library.c code (at top of the file).
gcc source_code.c library.c in the linux terminal will link and compile both source_code.c and library.c. This will generate an executable named "a.out" (if there were no compilation problems). You can change its name, by adding the option -o name to the gcc command (gcc source_code.c library.c -o mycode will generate an executable named "mycode").
If you really need a library that will be used by a lot of other programs, you can look for "shared libraries", but I think that you are asking for a basic thing.
You dont need this library.h while building and executable (with gcc) as you should have specified the exact location of the library in the source file. All you need to do is gcc sourcefile1.c sourcefile2.c -o exename
Normally I can google my way around and find solutions, but not this time.
I'm using 64 bit Linux Ubuntu 11.04 to compile a 32 bit windows application. I'm using i586-mingw32msvc-gcc to compile my C++ files.
test.cpp:
#include <boost/asio.hpp>
makefile:
i586-mingw32msvc-gcc -c -m32 -mthreads -o test.o test.cpp
Error:
boost/asio/detail/socket_types.hpp:
# include <sys/ioctl.h>
doesn't exist.
Added to makefile: -DBOOST_WINDOWS
Error:
# warning Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately
Ok, added to makefile: -D_WIN32_WINNT=0x0501
Error:
# error "Compiler threading support is not turned on. Please set the correct command line options for threading: -pthread (Linux), -pthreads (Solaris) or -mthreads (Mingw32)"
Yet I did specify -mthreads.
Adding -DBOOST_HAS_THREADS might be sufficient (see # elif defined __GNUC__ from the offending header). But it's likely/possible that your boost installation has been crafted to support your build environment and not your target. Try building it yourself with your cross-compiling toolchain.
It turned out that I had a set of #undef and #defines to force the GLIBC version to something that allowed me to compile for Linux (not cross compile) RHEL5, which otherwise would give me all kinds of other errors. Turns out that when cross compiling for windows using mingw, that force feeding the GLIBC version causes boost to take a strange path leaving various aspects undefined, including the bahavior or availability of threading. I surrounded it with an #ifndef _WIN32 which made the problem go away.
Maybe that -mthreads argument needs to come last.
I have a shared library which is supposed to export only one function which is marked with __attribute__ ((visibility ("default"))). It also links with another static library (fftw), and
#include<fftw3.h>
is preceded with:
#pragma GCC visibility push(hidden)
The linker command used:
g++.exe -fvisibility=hidden -shared -o mylib.dll -Wl,--out-implib,mylib.dll.a -Wl,--no-whole-archive libfftw3.a libfftw3_omp.a -lgomp
Now the resulting library is huge and if I check the exported functions it includes ALL fftw functions, and ALL function from my files. It looks like mingw ignores visibility options. I read that previously it gave warning about -fvisibility, but now it compiles with no warnings whatsoever.
Does mingw and gcc 4.6.1 support visibility flags? If yes, how do I get rid of all unnecessary stuff in my shared library?
Mingw is a Windows port of GCC toolchain but Windows dll are not Linux so. Especially the link part is different. To specify the visibility with MingGW you have to go the Windows way and annotate your classes and functions with :
__declspec(dllexport) while compiling the library
__declspec(dllimport) while linking
If you want multiplatform support for the GCC toolchain you can add a header in your project doing that for you. For a step by step example and lots of details have a look at GCC's visibility guide.
Windows PE object files do not have visibility attributes. The closest is dllexport/dllimport, but that's only for shared libraries (DLL's). So either you don't mark all FFTW functions with __declspec(dllexport), and hope linking the static library does The Right Thing (tm), or you take care not to link to FFTW if linking with your library.
It should warn about bad visibility attributes, perhaps you need to turn up the warning level -Wall -Wextra -pedantic).
Question is similar to this question
Handling header files dependencies with cmake
I have sample program dir having main.c main.h and CMakeLists.txt
main.h contents are
#ifndef MAIN_H
#define MAIN_H
int t=3;
int y=2;
#endif
main.c contents are
#include <main.h>
#include<stdio.h>
int main(){
printf("%d apple",t);
}
and CMakeLists.txt
PROJECT( test )
AUX_SOURCE_DIRECTORY(. test_SRCS)
include_directories(.)
ADD_EXECUTABLE (main ${test_SRCS})
but cmake is not rebuilding main.c on modification of header file.
I want it to auto-generate header file dependency.
Is it possible using cmake ?
if not is there any other tool which can do that ?
As mentioned in my comment, I have tried out your example and things were working fine: if main.h was modified then main.c would be recompiled.
My installation of CMake (version 2.8.0) told me to add
cmake_minimum_required(VERSION 2.8)
to the CMakeLists.txt file, but that is all of the adjustments I needed.
Answering this for others that google search...
I ran into this problem with one of my projects. As it turns out I added the header to the cpp file after running cmake. Re-running cmake fixed the problem. If you run into this, try that and see if it fixes the issue.
From the cmake 2.8.0 documentation of AUX_SOURCE_DIRECTORY:
It is tempting to use this command to avoid writing the list of source
files for a library or executable target. While this seems to work,
there is no way for CMake to generate a build system that knows when a
new source file has been added. Normally the generated build system
knows when it needs to rerun CMake because the CMakeLists.txt file is
modified to add a new source. When the source is just added to the
directory without modifying this file, one would have to manually
rerun CMake to generate a build system incorporating the new file.
Why do you want to avoid creating a list of files? Such lists generally do not change frequently.
I've seen this question on here, tried the proposed fixes, but no success so far for me. I have quite some Java experience, but JNI is a long time ago, never did it on Linux though...
I'm trying to get a simple HelloWorld JNI app running on Linux.
Small java file:
class HelloWorld {
private native void print();
public static void main(String[] args){
new HelloWorld().print();
}
static {
System.out.println(System.getProperty("java.library.path"));
System.loadLibrary("HelloWorld");
}
}
Small C file:
#include <jni.h>
#include <stdio.h>
#include "HelloWorld.h"
JNIEXPORT void JNICALL
Java_HelloWorld_print(JNIEnv *env, jobject obj)
{
printf("Hello World!\n");
return;
}
compiled the C file by:
gcc -shared -Wall -fPIC HelloWorld.c -I/usr/lib/gcc/x86_64-redhat-linux/3.4.3/include/ -o libHelloWorld.so
Run the app by:
java HelloWorld
or
java -Djava.library.path=/home/nxp40954/jnitesting/. HelloWorld
But no good, getting a:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/nxp40954/jnitesting/libHelloWorld.so: /home/nxp40954/jnitesting/libHelloWorld.so: cannot open shared object file: No such file or directory
Strange, because there is actually a /home/nxp40954/jnitesting/libHelloWorld.so file.
Does anyone have a clue?
execute this way:
export LD_LIBRARY_PATH=.
java HelloWorld
The java.lang.UnsatisfiedLinkError is thrown when the .so file cannot be loaded.
The LD_LIBRARY_PATH variable points extra location to look for the *.so files.
I'm on 32bit ubuntu with sun java. I was compiling this way:
gcc -shared -Wall -fPIC HelloWorld.c -I/usr/lib/jvm/java-6-sun-1.6.0.26/include -I/usr/lib/jvm/java-6-sun-1.6.0.26/include/linux -o libHelloWorld.so
Your example worked for me on a 32-bit Linux installation.
Is your shared library compiled as a 32-bit or 64-bit shared library? Check with command file libHelloWorld.so. If your shared library is 64-bit then you need to give command line option -d64 when starting Java so that Java can load the 64-bit shared library.
If your shared library is 32-bit then perhaps the Java option -d32 will solve the problem.
Clarification on java.library.path and system path:
java.library.path is a JVM-Variable which can be set - e.g. - by the command line parameter
-Djava.library.path=xy
DLL's (on windows) and so's (on linux) which are loaded by the java call loadLibrary() must be located in the java.library.path. If it is loaded via JNI it must be located in the system path.
If such a linked library loads another linked library, latter must be found in the system path. In Windows the system path is resolved against the PATH environment variable, in linux it's the LD_LIBRARY_PATH environment variable (for linked libraries).
Another point to ensure in linux: Verify that the linked library has executable permissions for the current user. Usually a
sudo chmod 755 myLinkedLib
does the trick.