I tried adding the FaceRecognition wrapper for Opencv in java after this example. I had some issues since I'm trying to do this on Ubuntu, but I was able to create the .so file in the end.
Still I can't use it since I get the error:
/usr/lib/jvm/java-7-openjdk-amd64/bin/java: symbol lookup error: /home/vlad/workspace/HelloJNI/jni/libRecognizer.so: undefined symbol: _ZN2cv24createLBPHFaceRecognizerEiiiid
My makefile looks like this:
# Define a variable for classpath
CLASS_PATH = ../bin
# Define a virtual path for .class in the bin directory
vpath %.class $(CLASS_PATH)
all : libRecognizer.so
# $# matches the target, $< matches the first dependancy
libRecognizer.so : facerec.cpp
g++ -fPIC -o $# -shared -Wl,-rpath, -I"/usr/lib/jvm/java-7-openjdk-amd64/include" -I"/usr/lib/jvm/java-7-openjdk-amd64/include/linux" $<
#cc -fPIC -I"/usr/lib/jvm/java-7-openjdk-amd64/include" -I"/usr/lib/jvm/java-7-openjdk-amd64/include/linux" -Wl, -shared -o $#
# $# matches the target, $< matches the first dependancy
#HelloJNI.o : HelloJNI.c HelloJNI.h
# gcc -m64 -I"/usr/lib/jvm/java-7-openjdk-amd64/include" -I"/usr/lib/jvm/java-7-openjdk-amd64/include/linux" -c $< -o $#
# $* matches the target filename without the extension
LBPHFaceRecognizer.h : LBPHFaceRecognizer.class
javah -classpath $(CLASS_PATH):../jni/opencv-249.jar $*
clean :
rm LBPHFaceRecognizer.h LBPHFaceRecognizer.o libRecognizer.so
I tried "ldd" and "libopencv_java249.so" seems to be there:
vlad#woow-1022:~/workspace/HelloJNI/jni$ ldd libRecognizer.so
linux-vdso.so.1 => (0x00007fff969fe000)
/home/vlad/workspace/HelloJNI/jni/libopencv_java249.so (0x00007fb24797a000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb247658000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb247441000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb24723d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb24701f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb246e16000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb246b10000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb24674a000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb248ed1000)
So I really don't know what to try next...
UPDATE:
I ended up doing something like this in the terminal:
g++ -L/usr/lib/jni -fPIC -o libRecognizer.so -shared -Wl,-rpath, -I"/usr/lib/jvm/java-7-openjdk-amd64/include" -I"/usr/lib/jvm/java-7-openjdk-amd64/include/linux" facerec.cpp -lopencv_java249
so for /usr/lib/jni/libopencv_java249.so I had to add -L/usr/lib/jni and -lopencv_java249
I ended up doing something like this in the terminal:
g++ -L/usr/lib/jni -fPIC -o libRecognizer.so -shared -Wl,-rpath, -I"/usr/lib/jvm/java-7-openjdk-amd64/include" -I"/usr/lib/jvm/java-7-openjdk-amd64/include/linux" facerec.cpp -lopencv_java249
Related
REM Create the header with javac -h . ClassName.java
REM Remember to set your JAVA_HOME env var
g++ -c -I "%JAVA_HOME%\include" -I "%JAVA_HOME%\include\win32" com_baeldung_jni_HelloWorldJNI.cpp -o com_baeldung_jni_HelloWorldJNI.o
g++ -c -I "%JAVA_HOME%\include" -I "%JAVA_HOME%\include\win32" com_baeldung_jni_ExampleParametersJNI.cpp -o com_baeldung_jni_ExampleParametersJNI.o
g++ -c -I "%JAVA_HOME%\include" -I "%JAVA_HOME%\include\win32" com_baeldung_jni_ExampleObjectsJNI.cpp -o com_baeldung_jni_ExampleObjectsJNI.o
g++ -shared -o ..\..\..\native\win32\native.dll com_baeldung_jni_HelloWorldJNI.o com_baeldung_jni_ExampleParametersJNI.o com_baeldung_jni_ExampleObjectsJNI.o -Wl,--add-stdcall-alias
Output :
D:\work\git\project\tutorials-master\java-native\src\main\cpp>REM Create the header with javac -h . ClassName.java
D:\work\git\project\tutorials-master\java-native\src\main\cpp>REM Remember to set your JAVA_HOME env var
D:\work\git\project\tutorials-master\java-native\src\main\cpp>g++ -c -I "D:\Program Files\Java\jdk1.8.0_101\include" -I "D:\Program Files\Java\jdk1.8.0_101\include\win32" com_baeldung_jni_HelloWorldJNI.cpp -o com_baeldung_jni_HelloWorldJNI.o
D:\work\git\project\tutorials-master\java-native\src\main\cpp>g++ -c -I "D:\Program Files\Java\jdk1.8.0_101\include" -I "D:\Program Files\Java\jdk1.8.0_101\include\win32" com_baeldung_jni_ExampleParametersJNI.cpp -o com_baeldung_jni_ExampleParametersJNI.o
D:\work\git\project\tutorials-master\java-native\src\main\cpp>g++ -c -I "D:\Program Files\Java\jdk1.8.0_101\include" -I "D:\Program Files\Java\jdk1.8.0_101\include\win32" com_baeldung_jni_ExampleObjectsJNI.cpp -o com_baeldung_jni_ExampleObjectsJNI.o
D:\work\git\project\tutorials-master\java-native\src\main\cpp>g++ -shared -o ..\..\..\native\win32\native.dll com_baeldung_jni_HelloWorldJNI.o com_baeldung_jni_ExampleParametersJNI.o com_baeldung_jni_ExampleObjectsJNI.o -Wl,--add-stdcall-alias
**d:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe: cannot open output file ..\..\..\native\win32\native.dll: No such file or directory**
collect2.exe: error: ld returned 1 exit status
Process finished with exit code 1
enter image description here
What's wrong?
Apparently, GCC (or G++) needs the output (might also apply to others: dump, auxiliary, ...) directory to exist*.
By default, the output directory is CWD (.), which exists (in most cases).
Here's a dummy examle.
sample.c:
#include <stdio.h>
int main()
{
printf("Dummy text\n");
return 0;
}
(qaic-env) [cfati#cfati-5510-0:/mnt/e/Work/Dev/StackOverflow/q073923282]> ~/sopr.sh
### Set shorter prompt to better fit when pasted in StackOverflow (or other) pages ###
[064bit prompt]> ls
sample.c
[064bit prompt]>
[064bit prompt]> OUT_DIR=.
[064bit prompt]> gcc -o ${OUT_DIR}/sample.out sample.c
[064bit prompt]> ./sample.out
Dummy text
[064bit prompt]>
[064bit prompt]> OUT_DIR=inner0
[064bit prompt]> gcc -o ${OUT_DIR}/sample.out sample.c
/usr/bin/ld: cannot open output file inner0/sample.out: No such file or directory
collect2: error: ld returned 1 exit status
[064bit prompt]> mkdir -p ${OUT_DIR}
[064bit prompt]> gcc -o ${OUT_DIR}/sample.out sample.c
[064bit prompt]> ./inner0/sample.out
Dummy text
[064bit prompt]>
[064bit prompt]> OUT_DIR=inner1/inner11
[064bit prompt]> gcc -o ${OUT_DIR}/sample.out sample.c
/usr/bin/ld: cannot open output file inner1/inner11/sample.out: No such file or directory
collect2: error: ld returned 1 exit status
[064bit prompt]> mkdir inner1
[064bit prompt]> gcc -o ${OUT_DIR}/sample.out sample.c
/usr/bin/ld: cannot open output file inner1/inner11/sample.out: No such file or directory
collect2: error: ld returned 1 exit status
[064bit prompt]> mkdir -p ${OUT_DIR}
[064bit prompt]> gcc -o ${OUT_DIR}/sample.out sample.c
[064bit prompt]> ./inner1/inner11/sample.out
Dummy text
[GNU.GCC]: Options Controlling the Kind of Output (-o file section) doesn't mention anything about this (which makes it strange, as GCC is well documented).
Also, the error message suggest otherwise:
/usr/bin/ld: cannot open output file inner0/sample.out: No such file or directory
collect2: error: ld returned 1 exit status
Going further (passing -v (verbose) option to GCC):
[064bit prompt]> gcc -v -o inexistent/sample.out sample.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.4.0-1ubuntu1~20.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-Av3uEd/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)
COLLECT_GCC_OPTIONS='-v' '-o' 'inexistent/sample.out' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/9/cc1 -quiet -v -imultiarch x86_64-linux-gnu sample.c -quiet -dumpbase sample.c -mtune=generic -march=x86-64 -auxbase sample -version -fasynchronous-unwind-tables -fstack-protector-strong -Wformat -Wformat-security -fstack-clash-protection -fcf-protection -o /tmp/ccjdCTrC.s
GNU C17 (Ubuntu 9.4.0-1ubuntu1~20.04.1) version 9.4.0 (x86_64-linux-gnu)
compiled by GNU C version 9.4.0, GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/9/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/9/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C17 (Ubuntu 9.4.0-1ubuntu1~20.04.1) version 9.4.0 (x86_64-linux-gnu)
compiled by GNU C version 9.4.0, GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c0c95c0b4209efec1c1892d5ff24030b
COLLECT_GCC_OPTIONS='-v' '-o' 'inexistent/sample.out' '-mtune=generic' '-march=x86-64'
as -v --64 -o /tmp/ccP79PwB.o /tmp/ccjdCTrC.s
GNU assembler version 2.34 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.34
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'inexistent/sample.out' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/9/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/9/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper -plugin-opt=-fresolution=/tmp/cc3Q3S6A.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro -o inexistent/sample.out /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/9 -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/9/../../.. /tmp/ccP79PwB.o -lgcc --push-state --as-needed -lgcc_s --po
p-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/9/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crtn.o
/usr/bin/ld: cannot open output file inexistent/sample.out: No such file or directory
collect2: error: ld returned 1 exit status
It becomes obvious that not GCC is having trouble creating the output directory, but the GNU Linker ([Man7]: LD(1)) which GCC invokes under the hood (other linkers might behave differently).
As a side note, not only the linker is experiencing this issue, but also the preprocessor, compiler, assembler - which is visible by passing to GCC one of -E, -S, -c flags.
I've browsed a bit LD's documentation, but I couldn't find a way to make it create the intermediary directories.
The fix (workaround) is simple: create the directory (mkdir -p) before invoking GCC (G++).
It's a common practice (which is most visible inside Makefiles).
So I am trying to make a jni library but the make file gives a strange error that I don't really understand.
/tmp/ccPWlMuy.o: In function `Java_GameLogic_setMap':
GameLogic.c:(.text+0x0): multiple definition of `Java_GameLogic_setMap'
/tmp/ccajmgva.o:GameLogic.c:(.text+0x0): first defined here
/tmp/ccPWlMuy.o: In function `Java_GameLogic_hello':
GameLogic.c:(.text+0x1c): multiple definition of `Java_GameLogic_hello'
/tmp/ccajmgva.o:GameLogic.c:(.text+0x1c): first defined here
collect2: ld returned 1 exit status
make: *** [GameLogic.o] Error 1
and the make file is:
# Define a variable for classpath
CLASS_PATH = .
# Define a virtual path for .class in the bin directory
vpath %.class $(CLASS_PATH)
all : libGameLogic.so
# $# matches the target, $< matches the first dependancy
libGameLogic.so : GameLogic.o
gcc -W1 -shared -o $# $<
# $# matches the target, $< matches the first dependancy
GameLogic.o : GameLogic.c GameLogic.h
gcc -fPIC -I /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.38.x86_64/include -I /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.38.x86_64/include/linux -shared GameLogic.c -o libGameLogic.so Map.c GameLogic.c
GameLogic.h: GameLogic.class PlayGame.class Bot.class
javah -classpath $(CLASS_PATH) GameLogic
GameLogic.class: GameLogic.java
javac *.java
PlayGame.class: PlayGame.java
javac *.java
Bot.class: Bot.java
javac *.java
clean :
rm GameLogic.o libGameLogic.so
To run the make file I type in make into the terminal and this is the error that it creates. For this I need to have it so that JNI makes a c call which then calls a method in another c file.
So Java <-> JNI <-> GameLogic <-> Map
In that order.
Any advice is much appreciated many thanks.
gcc -fPIC -I /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.38.x86_64/include -I /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.38.x86_64/include/linux -shared -o libGameLogic.so Map.c GameLogic.c
Map.h:7: warning: array ‘name’ assumed to have one element
Map.h:10: warning: array ‘map’ assumed to have one element
gcc -W1 -shared -o libGameLogic.so GameLogic.o
gcc: GameLogic.o: No such file or directory
gcc: no input files
make: *** [libGameLogic.so] Error 1
-bash-4.1$
You are compiling and linking GameLogic.c twice in this line:
# $# matches the target, $< matches the first dependancy
GameLogic.o : GameLogic.c GameLogic.h
gcc -fPIC -I /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.38.x86_64/include
-I /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.38.x86_64/include/linux
-shared GameLogic.c -o libGameLogic.so Map.c GameLogic.c
I am trying to access functions from a c++ .so file in java(JNA). I am able to call simple "Hello" type function from this .so file. But when I am trying to access other functions which internally calls functions from other files (.so file which is written in C), I am getting exception like:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/stpl/workspace/TestJNA/bin/libhello.so: undefined symbol: PInit
I am stuck in this. Any help will be appreciated.
Now my problem is solved.
In case anyone have the same problem, the problem was in .so file.
Below is the script for .mk file to create .so file.
CC=g++
CFLAG= -g -O0
PRNINC= -I ./Include -I ./PRT.IF -I./app
PRNLIBS= -lHWIGotPrinter -lcommon -lpthread -ldl
ASTYLE=astyle
ASTYLEFLAGS= --style=ansi -t -p -b -S -K
compiledate=$(shell date '+%F %T')
DEFS=-D DEFINE_MKDATE="\"$(compiledate)\""
INC_PUB= -I./Include -I./PRT.IF -I./SCANNER.IF -I ./Include
INCLUDE=$(INC_PUB)
%.o: %.cpp
$(CC) $(CFLAG) $(DEFS) -fPIC $(INCLUDE) -c $< -shared -o $#
%.o: %.c
$(CC) $(CFLAG) $(DEFS) -fPIC $(INCLUDE) -c $< -shared -o $#
.PHONY:all
all: PRN
HSCAN CDU UPS
PRNAPPS= bin/libprntest.so
PRN: $(PRNAPPS)
bin/libprntest.so: app/prn_proc.cpp app/prntest.cpp app/myCpp.cpp
$(CC) $(CFLAG) $(DEFS) $(PRNINC) $(PRNLIBS) $^ -shared -o $#
dist: all
mkdir -p insttest
rm -rf insttest/*
cp -a bin insttest/
cp -f Makefile inst/
tar -czf inst-$(MAJOR).$(MINOR).tgz insttest/
rm -rf insttest
install:
install -m 755 $(PRNAPPS) /usr/bin
cleanbak:
find . -name *.o |xargs rm -f
find . -name *~ |xargs rm -f
find . -name *.bak |xargs rm -f
find . -name *.orig |xargs rm -f
find . -name *.cpp |xargs chmod 644
find . -name .h |xargs chmod 644
chmod 644 ./etc-lib/gotlib.
clean:
find . -name *.o |xargs rm -f
find . -name *~ |xargs rm -f
find . -name *.bak |xargs rm -f
find . -name *.orig |xargs rm -f
find . -name *.cpp |xargs chmod 644
find . -name *.h |xargs chmod 644
rm -f $(PRNAPPS) $(SCANAPPS) $(HSCANAPPS) $(UPSAPPS) $(CDUAPPS) $(HARDWAREAPPS) $(CMOSAPPS) $(TOOLSAPPS)
help:
echo "make style "
echo "make cleanbak"
echo "make clean"
echo "make"
echo "make dist"
echo "make install"
I'm trying to create a .dll while following this tutorial (http://www3.ntu.edu.sg/home/ehchua/programming/java/JavaNativeInterface.html) to use JNI in my eclipse project. There's an issue with my makefile however that may be unrelated to all the JNI stuff.
I'm getting "unknown option: --add-stdcall-alias" when I build (make all). I'm using the Mac GCC Compiler. Here's my console log and make file:
EDIT: So i removed the option that is giving me the error and my build worked. However, I feel unsafe just removing a line of code that I am clueless about. Any one want to tell me the implications of removing this code?
console output:
18:05:33 ** Build of configuration Default for project HPA* Testing *
make all
javah -classpath ../bin HPAProgram
gcc -Wl,--add-stdcall-alias -shared -o hpaprogram.dll HPAProgram.o
ld: unknown option: --add-stdcall-alias
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: ** [hpaprogram.dll] Error 1
18:05:34 Build Finished (took 823ms)
makefile:
# Define a variable for classpath
CLASS_PATH = ../bin
# Define a virtual path for .class in the bin directory
vpath %.class $(CLASS_PATH)
all : hpaprogram.dll
# $# matches the target, $< matches the first dependancy
hpaprogram.dll : HPAProgram.o
gcc -Wl,--add-stdcall-alias -shared -o $# $<
# $# matches the target, $< matches the first dependancy
HPAProgram.o : HPAProgram.c++ HPAProgram.h
gcc -I /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ -c $< -o $#
# $* matches the target filename without the extension
HPAProgram.h : HPAProgram.class
javah -classpath $(CLASS_PATH) $*
clean :
rm HPAProgram.h HPAProgram.o hpaprogram.dll
I practiced by following the same tutorial, it turned out that it's OK to get rid of "-Wl,--add-stdcall-alias".
BTW, in Mac, you have to use ".dylib" instead of ".so", otherwise you will get error saying "java.lang.UnsatisfiedLinkError: no hello in java.library.path".
I am trying to create a DLL to use it with Java JNI. I am using Netbeans C/C++ plugin to create the dll.
but after compile i am getting the following error (.o objects already created)
any idea? am i missing something?
"/usr/bin/make" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
make[1]: Entering directory `/c/projects/hdijni'
rm -f -r build/Debug
rm -f dist/Debug/MinGW-Windows/libhdijni.dll
make[1]: Leaving directory `/c/projects/hdijni'
CLEAN SUCCESSFUL (total time: 18s)
"/usr/bin/make" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
make[1]: Entering directory `/c/projects/hdijni'
"/usr/bin/make" -f nbproject/Makefile-Debug.mk dist/Debug/MinGW-Windows/libhdijni.dll
make[2]: Entering directory `/c/projects/hdijni'
mkdir -p build/Debug/MinGW-Windows/src
rm -f build/Debug/MinGW-Windows/src/ByteJNI.o.d
gcc.exe -mno-cygwin -Wl,--add-stdcall-alias -shared -m32 -c -g -Isrc/Windows -Isrc -I../../MinGW/jni/include/win32 -I../../MinGW/jni/include -MMD -MP -MF build/Debug/MinGW-Windows/src/ByteJNI.o.d -o build/Debug/MinGW-Windows/src/ByteJNI.o src/ByteJNI.c
gcc.exe: --add-stdcall-alias: linker input file unused because linking not done
mkdir -p build/Debug/MinGW-Windows/src
rm -f build/Debug/MinGW-Windows/src/HDIJNI.o.d
gcc.exe -mno-cygwin -Wl,--add-stdcall-alias -shared -m32 -c -g -Isrc/Windows -Isrc -I../../MinGW/jni/include/win32 -I../../MinGW/jni/include -MMD -MP -MF build/Debug/MinGW-Windows/src/HDIJNI.o.d -o build/Debug/MinGW-Windows/src/HDIJNI.o src/HDIJNI.c
gcc.exe: --add-stdcall-alias: linker input file unused because linking not done
mkdir -p build/Debug/MinGW-Windows/src
rm -f build/Debug/MinGW-Windows/src/common.o.d
gcc.exe -mno-cygwin -Wl,--add-stdcall-alias -shared -m32 -c -g -Isrc/Windows -Isrc -I../../MinGW/jni/include/win32 -I../../MinGW/jni/include -MMD -MP -MF build/Debug/MinGW-Windows/src/common.o.d -o build/Debug/MinGW-Windows/src/common.o src/common.c
gcc.exe: --add-stdcall-alias: linker input file unused because linking not done
mkdir -p build/Debug/MinGW-Windows/src
rm -f build/Debug/MinGW-Windows/src/Generic.o.d
gcc.exe -mno-cygwin -Wl,--add-stdcall-alias -shared -m32 -c -g -Isrc/Windows -Isrc -I../../MinGW/jni/include/win32 -I../../MinGW/jni/include -MMD -MP -MF build/Debug/MinGW-Windows/src/Generic.o.d -o build/Debug/MinGW-Windows/src/Generic.o src/Generic.c
gcc.exe: --add-stdcall-alias: linker input file unused because linking not done
mkdir -p build/Debug/MinGW-Windows/src/Windows
rm -f build/Debug/MinGW-Windows/src/Windows/win.o.d
gcc.exe -mno-cygwin -Wl,--add-stdcall-alias -shared -m32 -c -g -Isrc/Windows -Isrc -I../../MinGW/jni/include/win32 -I../../MinGW/jni/include -MMD -MP -MF build/Debug/MinGW-Windows/src/Windows/win.o.d -o build/Debug/MinGW-Windows/src/Windows/win.o src/Windows/win.c
gcc.exe: --add-stdcall-alias: linker input file unused because linking not done
mkdir -p dist/Debug/MinGW-Windows
gcc.exe -mno-cygwin -Wl,--add-stdcall-alias -shared -m32 -shared -o dist/Debug/MinGW-Windows/libhdijni.dll build/Debug/MinGW-Windows/src/ByteJNI.o build/Debug/MinGW-Windows/src/HDIJNI.o build/Debug/MinGW-Windows/src/common.o build/Debug/MinGW-Windows/src/Generic.o build/Debug/MinGW-Windows/src/Windows/win.o
build/Debug/MinGW-Windows/src/HDIJNI.o: In function `callRuntimePropertiesMethod':
C:/projects/hdijni/src/HDIJNI.c:142: multiple definition of `callRuntimePropertiesMethod'
build/Debug/MinGW-Windows/src/ByteJNI.o:C:/projects/hdijni/src/ByteJNI.c:288: first defined here
build/Debug/MinGW-Windows/src/HDIJNI.o: In function `closeJVM':
C:/projects/hdijni/src/HDIJNI.c:192: multiple definition of `closeJVM'
build/Debug/MinGW-Windows/src/ByteJNI.o:C:/projects/hdijni/src/ByteJNI.c:402: first defined here
build/Debug/MinGW-Windows/src/HDIJNI.o: In function `getFailedCalls':
C:/projects/hdijni/src/HDIJNI.c:251: multiple definition of `getFailedCalls'
build/Debug/MinGW-Windows/src/ByteJNI.o:C:/projects/hdijni/src/ByteJNI.c:800: first defined here
build/Debug/MinGW-Windows/src/HDIJNI.o: In function `getJNIStatus':
C:/projects/hdijni/src/HDIJNI.c:266: multiple definition of `getJNIStatus'
build/Debug/MinGW-Windows/src/ByteJNI.o:C:/projects/hdijni/src/ByteJNI.c:900: first defined here
build/Debug/MinGW-Windows/src/HDIJNI.o: In function `getStrategyInfo':
C:/projects/hdijni/src/HDIJNI.c:282: multiple definition of `getStrategyInfo'
build/Debug/MinGW-Windows/src/ByteJNI.o:C:/projects/hdijni/src/ByteJNI.c:1090: first defined here
build/Debug/MinGW-Windows/src/HDIJNI.o: In function `getSuccessfulCalls':
C:/projects/hdijni/src/HDIJNI.c:339: multiple definition of `getSuccessfulCalls'
build/Debug/MinGW-Windows/src/ByteJNI.o:C:/projects/hdijni/src/ByteJNI.c:1154: first defined here
build/Debug/MinGW-Windows/src/HDIJNI.o: In function `getTotalDACalls':
C:/projects/hdijni/src/HDIJNI.c:354: multiple definition of `getTotalDACalls'
build/Debug/MinGW-Windows/src/ByteJNI.o:C:/projects/hdijni/src/ByteJNI.c:1169: first defined here
build/Debug/MinGW-Windows/src/HDIJNI.o: In function `getTotalDACallsFor':
C:/projects/hdijni/src/HDIJNI.c:375: multiple definition of `getTotalDACallsFor'
build/Debug/MinGW-Windows/src/ByteJNI.o:C:/projects/hdijni/src/ByteJNI.c:1190: first defined here
build/Debug/MinGW-Windows/src/HDIJNI.o: In function `initialiseJVM':
C:/projects/hdijni/src/HDIJNI.c:464: multiple definition of `initialiseJVM'
build/Debug/MinGW-Windows/src/ByteJNI.o:C:/projects/hdijni/src/ByteJNI.c:1229: first defined here
build/Debug/MinGW-Windows/src/HDIJNI.o: In function `loadStrategy':
C:/projects/hdijni/src/HDIJNI.c:836: multiple definition of `loadStrategy'
build/Debug/MinGW-Windows/src/ByteJNI.o:C:/projects/hdijni/src/ByteJNI.c:1907: first defined heremake[2]: Leaving directory `/c/projects/hdijni'
make[1]: Leaving directory `/c/projects/hdijni'
collect2: ld returned 1 exit status
make[2]: *** [dist/Debug/MinGW-Windows/libhdijni.dll] Error 1
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
BUILD FAILED (exit value 2, total time: 1s)
sorry guys,
it was duplicate methods problem. ;)
question closed.