I just wanted to try out using OpenCL under Windows.
Abstract: I got an "undefined reference to" error when I tried to compile (using the command gcc my.o -o my.exe -L "C:\Program Files (x86)\AMD APP\lib\x86_64" -l OpenCL).
My Code
#include <CL/cl.h>
#include <stdio.h>
int main(void) {
cl_platform_id platform;
int err;
err = clGetPlatformIDs(1, &platform, NULL);
if(err < 0) {
perror("There's No Platform!");
exit(1);
}
/* Some more code... */
system("PAUSE");
}
Makefile
all: addition
addition:
gcc -c -I "C:\Program Files (x86)\AMD APP\include" my.c -o my.o
gcc my.o -o my.exe -L "C:\Program Files (x86)\AMD APP\lib\x86_64" -l OpenCL
Used Programs
MinGW's gcc
Visual Studio's nmake
AMD's OpenCL™ APP SDK (that's where I took the OpenCL library and the CL.h file from)
The Structure of APP SDK's Folders
%>tree /F "C:\Program Files (x86)\AMD APP\lib\x86_64"
Auflistung der Ordnerpfade
Volumeseriennummer : D2DC-D765
C:\PROGRAM FILES (X86)\AMD APP\LIB\X86_64
libOpenCL.a
OpenCL.lib
OpenVideo64.lib
Es sind keine Unterordner vorhanden
%>tree /F "C:\Program Files (x86)\AMD APP\include"
Auflistung der Ordnerpfade
Volumeseriennummer : D2DC-D765
C:\PROGRAM FILES (X86)\AMD APP\INCLUDE
├───CAL
│ cal.h
│ calcl.h
│ cal_ext.h
│ cal_ext_counter.h
│ cal_ext_d3d10.h
│ cal_ext_d3d9.h
│
├───CL
│ cl.h
│ cl.hpp
│ cl_d3d10.h
│ cl_ext.h
│ cl_gl.h
│ cl_gl_ext.h
│ cl_platform.h
│ opencl.h
│
└───OpenVideo
OpenVideo.h
OVDecode.h
OVDecodeTypes.h
OVEncode.h
OVEncodeTypes.h
Error Message
gcc addition.o -o addition.exe -L "C:\Program Files (x86)\AMD APP\lib\x86_64" -l OpenCL
addition.o:addition.c:(.text+0x2d): undefined reference to `clGetPlatformIDs#12'
addition.o:addition.c:(.text+0x83): undefined reference to `clGetDeviceIDs#24'
addition.o:addition.c:(.text+0xc2): undefined reference to `clGetDeviceIDs#24'
collect2: ld returned 1 exit status
NMAKE : fatal error U1077: "C:\prog-x86\MinGW\bin\gcc.EXE": Rückgabe-Code "0x1"
Stop.
My Questions
My questions are simple:
Why doesn't my code compile how it is expected to?
What can I do to get rid of this problem?
Thanks.
UPDATE: The error message after dropping the spaces like described in #codaddict 's answer.
(Makefile)
all: addition
addition:
gcc -c -I "C:\prog-x86\AMD-APP\include" addition.c -o addition.o
gcc addition.o -o addition.exe -LC:\prog-x86\AMD-APP\lib\x86_64 -lOpenCL
(Shelldata)
%>nmake
Microsoft (R) Program Maintenance Utility, Version 11.00.50727.1
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.
gcc -c -I "C:\Program Files (x86)\AMD APP\include" addition.c -o addition.o
addition.c: In function 'main':
addition.c:14:9: warning: incompatible implicit declaration of built-in function 'exit' [enabled by d
efault]
addition.c:23:9: warning: incompatible implicit declaration of built-in function 'exit' [enabled by d
efault]
gcc addition.o -o addition.exe -LC:\prog-x86\AMD-APP\lib\x86_64 -lOpenCL
addition.o:addition.c:(.text+0x2d): undefined reference to `clGetPlatformIDs#12'
addition.o:addition.c:(.text+0x83): undefined reference to `clGetDeviceIDs#24'
addition.o:addition.c:(.text+0xc2): undefined reference to `clGetDeviceIDs#24'
collect2: ld returned 1 exit status
NMAKE : fatal error U1077: "C:\prog-x86\MinGW\bin\gcc.EXE": Rückgabe-Code "0x1"
Stop.
%>
The default MinGW distribution only ships tools for building x86 applications. You cannot link against the x64 version of the OpenCL library. So you either have to use MinGW-w64 or use the x86 version (change the library path to the x86 subfolder of the APP SDK).
Try changing
-l OpenCL
to
-lOpenCL
in the compile line.
The -l option of gcc expects the name of the library (without the lib prefix) right next to it without any space. Remember using -lm in school to link to libm?
The 64 bit g++ compiler on windows 10 is also in the bin folder:
"C:\MinGW\bin\x86_64-w64-mingw32-g++.exe"
So this works for me:
C:\MinGW\bin>x86_64-w64-mingw32-g++ "C:\Users\...\main.cpp" -o
C:\Users\...\saxpy -L "C:\Program Files\...\x64" -lOpenCL -I
"C:\...\OpenCL\sdk\include"
Notes:
-o output name
-L folder contains OpenCL.lib
-I folder contains header file e.g. CL/cl.h
Related
I am working on windows with mingw and CMake.
Someone provide a library with lib, dll and header files. I am able to use it quite easily in Visual Studio projects. But I was not able to integrate it into a CMake project. There are already a lot of questions about this topic but only working for Linux, or with library build with CMake, or library where sources are available, or the same use case as me but with a lot of erratum in comments saying that the answer is never completely correct...
I would like to use the foo_function from the foo library in my bar project. I don't have the source of this foo project. Only a dll, lib and header file.
BarProject
├───
├─── CMakeLists.txt
├─── Foo
├─── include
└─── foo.h
├─── x64
|─── foo.dll
└─── foo.lib
└─── main_bar.c
This is the content of my CmakeLists.txt file :
cmake_minimum_required(VERSION 3.10)
# set the project name and version
project(bar VERSION 1.0)
# add the executable
add_executable(bar main_bar.c)
target_include_directories(bar PUBLIC "${PROJECT_BINARY_DIR}" "foo/include")
add_library(foo SHARED IMPORTED)
set_property(TARGET foo PROPERTY
IMPORTED_LOCATION "${CMAKE_SOURCE_DIR}/Foo/x64/foo.dll")
set_property(TARGET foo PROPERTY
IMPORTED_IMPLIB "${CMAKE_SOURCE_DIR}/Foo/x64/foo.lib")
target_link_libraries(bar PRIVATE foo)
set(CMAKE_VERBOSE_MAKEFILE ON)
set(CMAKE_SUPPRESS_REGENERATION true)
set_property(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY VS_STARTUP_PROJECT bar)
Finally to test my work :
$ ls
main_bar.c CMakeLists.txt Foo
$ mkdir tutu
$ cd tutu
$ cmake .. && cmake --build . -v
-- Building for: Visual Studio 16 2019
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
-- The C compiler identification is MSVC 19.29.30145.0
-- The CXX compiler identification is MSVC 19.29.30145.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
(...)
cl /c /IC:\Users\lambe\work\repository\bar\tutu /IC:\Users\lambe\work\repository\bar\. /IC:\Users\lambe\work\repository\bar\Foo\include/Wall /WX /diagnostics:column /Od /D _MBCS /D WIN32 /D _WINDOWS /D STAND_ALONE /D "CMAKE_INTDIR=\"Debug\"" /Gm- /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"bar.dir\Debug\\" /Fd"bar.dir\Debug\vc142.pdb" /external:W4 /Gd /TC /wd4996 /wd4820 /wd5045 /wd4668 /errorReport:queue C:\Users\lambe\work\repository\bar\main_bar.c
main_bar.c
Generating Code...
Link:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\link.exe /ERRORREPORT:QUEUE /OUT:"C:\Users\lambe\work\repository\bar\tutu\Debug\bar.exe" /INCREMENTAL /ILK:"bar.dir\Debug\bar.ilk" /NOLOGO ..\Foo\x64\foo.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG /PDB:"C:/Users/lambe/work/repository/bar/tutu/Debug/bar.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:/Users/lambe/work/repository/bar/tutu/Debug/bar.lib" /MACHINE:X64 /machine:x64 bar.dir\Debug\main_bar.obj
bar.dir\Debug\main_bar.obj
main_bar.obj : error LNK2019: unresolved external symbol foo_function referenced in function main [C:\Users\lambe\work\repository\bar\tutu\bar.vcxproj]
C:\Users\lambe\work\repository\bar\tutu\Debug\bar.exe : fatal error LNK1120: 1 unresolved externals [C:\Users\lambe\work\repository\bar\tutu\bar.vcxproj]
The compilation step is working great, the issue is during the linking step.
EDIT:
Ok after the comment from Ben Voigt, I choose to explore the solution to use the gcc/g++ compiler from mingw instead of using the CL/Visual Studio thing.
The new test procedure :
$ cmake .. -G "MinGW Makefiles" && cmake --build . -v
(...)
C:\MinGW\bin\gcc.exe -DSTAND_ALONE #CMakeFiles/bar.dir/includes_C.rsp -MD -MT CMakeFiles/bar.dir/main_bar.c.obj -MF
CMakeFiles\bar.dir\main_bar.c.obj.d -o CMakeFiles\bar.dir\main_bar.c.obj -c C:\Users\lambe\work\repository\bar\main_bar.c
[100%] Linking C executable bar.exe
"C:\Program Files\CMake\bin\cmake.exe" -E cmake_link_script CMakeFiles\bar.dir\link.txt --verbose=1
"C:\Program Files\CMake\bin\cmake.exe" -E rm -f CMakeFiles\bar.dir/objects.a
C:\MinGW\bin\ar.exe qc CMakeFiles\bar.dir/objects.a #CMakeFiles\bar.dir\objects1.rsp
C:\MinGW\bin\gcc.exe -Wl,--whole-archive CMakeFiles\bar.dir/objects.a -Wl,--no-whole-archive -o bar.exe -Wl,--out-implib,libbar.dll.a -Wl,--major-image-version,0,--minor-image-version,0 #CMakeFiles\bar.dir\linklibs.rsp
CMakeFiles\bar.dir/objects.a(main_bar.c.obj):main_bar.c:(.text+0x4f4e): undefined reference to `foo_function'
collect2.exe: error: ld returned 1 exit status
CMakeFiles\bar.dir\build.make:830: recipe for target 'bar.exe' failed
mingw32-make.exe[2]: *** [bar.exe] Error 1
mingw32-make.exe[2]: Leaving directory 'C:/Users/lambe/work/repository/bar/test'
CMakeFiles\Makefile2:81: recipe for target 'CMakeFiles/bar.dir/all' failed
mingw32-make.exe[1]: *** [CMakeFiles/bar.dir/all] Error 2
mingw32-make.exe[1]: Leaving directory 'C:/Users/lambe/work/repository/bar/test'
Makefile:89: recipe for target 'all' failed
mingw32-make.exe: *** [all] Error 2
Ok the result is the same but at least, the command line and tools are more familiar for me.
I cannot find any reference to the foo library in the command line. Then I check the file linklibs.rsp and here we are :
$ cat CMakeFiles/bar.dir/linklibs.rsp
-lm *Foo/x64/foo.lib* -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
Is it the expected result?
I want to compile a c-file with the path .\test\test.c. The file includes a .h-file in the current working directory.
gcc compiles the file when I run:
gcc -c .\test\test.c -o .\test.o -I .
However, it fails when I run:
gcc -c .\test\test.c -o .\test.o -I .\
Giving me the following error message:
.\test\test.c:13:10: fatal error: clib_string.h: No such file or directory
#include "clib_string.h"
^~~~~~~~~~~~~~~
compilation terminated.
This makes me wonder if there is a difference between the paths . and .\ in windows or if this is just a quirk of gcc?
I'm using automake to build my project. I have some third-party (open source) libraries as git submodules in my project that I want to individually build and link. Here's an edited (names changed) version of my Makefile.am:
lib_LTLIBRARIES = libfoo.la libbar.la
libbar_la_SOURCES = ../submodules/bar/bar.c
libfoo_la_LIBADD = libbar.la
libfoo_la_SOURCES = \
some_source.c \
some_other_source.c
libfoo_la_CFLAGS = $(CFLAGS)
libfoo_la_LDFLAGS = $(LIBS)
if OS_LINUX
libfoo_la_SOURCES += \
linux/some_source.c \
linux/some_other_source.c
libfoo_la_CFLAGS += $(PTHREAD_CFLAGS)
libfoo_la_LDFLAGS += $(PTHREAD_LIBS)
endif
if OS_WINDOWS_MSYS
libfoo_la_SOURCES += \
nt/some_source.c \
nt/some_other_source.c
libfoo_la_LDFLAGS += -no-undefined
endif
bin_PROGRAMS = main
main_SOURCES = main.c
main_LDADD = libfoo.la
autoreconf, configure and make run normally but make install fails with
/usr/bin/ld: cannot find -lbar
collect2: error: ld returned 1 exit status
It seems autoconf is trying to use libbar as a global, installed library instead of a local one? LDADD on the main target works fine though.
autoreconf -V outputs
autoreconf (GNU Autoconf) 2.71
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>, <https://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David J. MacKenzie and Akim Demaille.
EDIT: I am on Linux. Don't mind the windows parts.
I tried to reproduce this on https://github.com/ndim/stackoverflow-q70584133 by basically copying the Makefile.am you have given and adding a few very basic source files.
I found that building on Linux for Linux (Fedora 35, autoconf 2.69-37, automake 1.16.2-5, libtool 2.4.6-42) worked fine. Also running the make installed result:
[user#host stackoverflow-q70584133]$ mkdir _b-host && cd _b-host
[user#host _b-host]$ ../configure --prefix=$PWD/_i
[user#host _b-host]$ make && make install && ./_i/bin/main
[...]
main: x86_64-pc-linux-gnu
foo_func
bar_func
foo_host_func: Linux 331524 = 0x50f04 = 5.15.4 (5.15.4)
[user#host _b-host]$ _
So if you have problems building on and for Linux, something else must be off.
I presume you have run make distclean and then re-run autoreconf and configure to make sure your buildsystem and source tree and build tree are in a well defined state.
However, building on Fedora 35 for Windows (both 32 and 64bit) failed for me when building libbar.la without -no-undefined:
/bin/sh ../libtool --tag=CC --mode=link i686-w64-mingw32-gcc -g -O2 -o libbar.la -rpath /home/user/stackoverflow-q70584133/_b-w32/_i/lib ../bar/libbar_la-bar.lo
libtool: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries; building static only
libtool: link: i686-w64-mingw32-ar cru .libs/libbar.a ../bar/libbar_la-bar.o
libtool: link: i686-w64-mingw32-ranlib .libs/libbar.a
libtool: link: ( cd ".libs" && rm -f "libbar.la" && ln -s "../libbar.la" "libbar.la" )
/bin/sh ../libtool --tag=CC --mode=link i686-w64-mingw32-gcc -g -O2 -no-undefined -o libfoo.la -rpath /home/user/stackoverflow-q70584133/_b-w32/_i/lib foo/libfoo_la-foo.lo foo/libfoo_la-foo-nt.lo libbar.la
*** Warning: This system cannot link to static lib archive libbar.la.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
libtool: link: i686-w64-mingw32-gcc -shared foo/.libs/libfoo_la-foo.o foo/.libs/libfoo_la-foo-nt.o -g -O2 -o .libs/libfoo-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libfoo.dll.a
/usr/lib/gcc/i686-w64-mingw32/11.2.1/../../../../i686-w64-mingw32/bin/ld: foo/.libs/libfoo_la-foo.o: in function `foo_func':
/home/user/stackoverflow-q70584133/_b-w32/src/../../src/foo/foo.c:10: undefined reference to `bar_func'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:521: libfoo.la] Error 1
Adding a line to Makefile.am like
libbar_la_LDFLAGS += -no-undefined
fixed the linking for Windows problem and made the whole thing build and run (built on Linux, run on Linux using wine):
[user#host stackoverflow-q70584133]$ mkdir _b-w64 && cd _b-w64
[user#host _b-w64]$ ../configure --host=x86_64-w64-mingw32 --prefix=$PWD/_i
[user#host _b-w64]$ make && make install && ./_i/bin/main.exe
[...]
main: x86_64-w64-mingw32
foo_func
bar_func
foo_host_func: Windows 0x0a00 = 10.0
[user#host _b-w64]$ _
(And BTW, LIBS and _LIBS type variables should probably be added to a _LIBADD or _LDADD variable, not to a _LDFLAGS variable.)
UPDATE
Building on Debian 10 (autoconf 2.69-11, automake 1:1.16.1-4, libtool 2.4.6-9), does produce a linker error when main_LDADD is missing libbar.la and src/main.c calls the bar_func() function from libbar (uncomment the #define in src/main.c to reproduce):
[user#host _b-host]$ make
[...]
/bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -o main main-main.o libfoo.la
libtool: link: gcc -g -O2 -o .libs/main main-main.o ./.libs/libfoo.so -pthread -Wl,-rpath -Wl,/home/user/stackoverflow-q70584133/_b-host/_i/lib
/usr/bin/ld: main-main.o: undefined reference to symbol 'bar_func'
/usr/bin/ld: //home/user/stackoverflow-q70584133/_b-host/src/.libs/libbar.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:525: main] Error 1
make[1]: Leaving directory '/home/user/stackoverflow-q70584133/_b-host/src'
make: *** [Makefile:390: all-recursive] Error 1
[user#host _b-host]$ _
However, after removing the direct calls to libbar's bar_func() from src/main.c, the make command will work again, as does make install:
[user#host _b-host]$ make install && ./_i/bin/main
main: x86_64-pc-linux-gnu
foo_func
bar_func
foo_host_func: Linux 267216 = 0x413d0 = 4.19.208
[user#host _b-host]$ _
This suggests that calling a function from libbar from a linking unit without explicitly linking that unit against libbar is an error, and that does make sense.
So I still cannot reproduce OP's report of make working but make install failing. OP is using newer autoconf (2.71) than I do (2.69). Perhaps OP is using different automake/libtool versions as well with different set of bugs (dpkg -l autoconf automake libtool, rpm -q autoconf automake libtool, etc.)?
I download python launcher
and try to build it independently.
I have tried:
gcc launcher.c -lversion -o py.exe
gcc launcher.o -lversion -lWs2_32 -o py.exe
with both posix/win32 mingw-w64 and meet same error:
(.text+0x1b02): undefined reference to `__imp__wdupenv_s'
collect2.exe: error: ld returned 1 exit status
I know there must be one more lib I have to link it, but I don't know which one.
Could anyone help?
or provide a method to find which lib contains specify function
_wdupenv_s() had been apparently introduced in Visual Studio 2008's CRT (msvcr90), but it seems it didn't make it into the system CRT (msvcrt). mingw-w64 GCCs generally link only to the system CRT by default so that's why ld can't find the symbol.
You can try to link to a Visual Studio CRT explicitly, but beware this might have bad consequences, because the resulting binary links to both CRTs and mixing CRTs is known to cause issues.
gcc -municode launcher.c -o launcher.exe -lversion -lmsvcr120
If your toolchain has that feature (the one built by MSYS2 has), you can replace the system CRT with the Visual Studio CRT completely:
gcc -municode -mcrtdll=msvcr120 launcher.c -o launcher.exe -lversion
I also added a -municode argument, otherwise I get an undefined reference to WinMain.
Also note that in the build files there's 4 binaries built from launcher.c, each with its own set of defines:
[...] -o pylauncher.exe -D_CONSOLE
[...] -o pywlauncher.exe -D_WINDOWS
[...] -o venvlauncher.exe -D_CONSOLE -DVENV_REDIRECT
[...] -o venvwlauncher.exe -D_WINDOWS -DVENV_REDIRECT
You should probably use one of these sets when compiling.
If you do a few more steps, you can even have a nice icon and stuff:
copy /y ..\Include\patchlevel.h pythonnt_rc.h
echo #define FIELD3 106 >> pythonnt_rc.h
echo #define MS_DLL_ID "10.0" >> pythonnt_rc.h
echo #define PYTHON_DLL_NAME "foopython3.dll" >> pythonnt_rc.h
windres -I..\Include -I. pylauncher.rc -o pylauncher.o
gcc -municode -mcrtdll=msvcr120 -D_CONSOLE launcher.c pylauncher.o -o pylaunc
her.exe -lversion
I've been having trouble debugging some C code that I'm writing as part of an R package. The code compiles and executes when I use R CMD SHLIB from the Windows console (i.e. cmd.exe):
>R CMD SHLIB MaximumAgreementForest.c
gcc -m64 -I"C:/PROGRA~1/R/R-32~1.4RE/include" -DNDEBUG -I"d:/RCompile/r-compiling/local/local323/include" -O2 -Wall -std=gnu99 -mtune=core2 -c MaximumAgreementForest.c -o MaximumAgreementForest.o
gcc -m64 -shared -s -static-libgcc -o MaximumAgreementForest.dll tmp.def MaximumAgreementForest.o -Ld:/RCompile/r-compiling/local/local323/lib/x64 -Ld:/RCompile/r-compiling/local/local323/lib -LC:/PROGRA~1/R/R-32~1.4RE/bin/x64 -lR
The script also built correctly in Netbeans until I started using the functions R_alloc and C_alloc from the R libraries. Now it doesn't seem to be able to find the definitions of a number of R-specific functions. When I attempt to build the project in Netbeans the console lists the following:
cd 'C:\Work\Fun\implied_weight\MAF'
C:\MinGW\msys\1.0\bin\make.exe -f Makefile CONF=Debug
"/C/MinGW/msys/1.0/bin/make.exe" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
make.exe[1]: Entering directory `/c/Work/Fun/implied_weight/MAF'
"/C/MinGW/msys/1.0/bin/make.exe" -f nbproject/Makefile-Debug.mk dist/Debug/MinGW-Windows/libMAF.dll
make.exe[2]: Entering directory `/c/Work/Fun/implied_weight/MAF'
mkdir -p build/Debug/MinGW-Windows/_ext/5c0
rm -f "build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o.d"
gcc -DDEBUG -O2 -Wall -mtune=core2 -c -g -Wall -I/C/Program\ Files/R/R-3.2.4revised/include -MMD -MP -MF "build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o.d" -o build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o ../MaximumAgreementForest.c
mkdir -p dist/Debug/MinGW-Windows
gcc -DDEBUG -O2 -Wall -mtune=core2 -o dist/Debug/MinGW-Windows/libMAF.dll build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o -L/C/Program\ Files/R -L/C/Program\ Files/R/R-3.2.4revised/library -shared
build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o: In function `forest_new':
C:\Work\Fun\implied_weight\MAF/../MaximumAgreementForest.c:37: undefined reference to `R_alloc'
build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o: In function `forest_plant':
C:\Work\Fun\implied_weight\MAF/../MaximumAgreementForest.c:55: undefined reference to `S_alloc'
[...]
C:\Work\Fun\implied_weight\MAF/../MaximumAgreementForest.c:515: undefined reference to `R_chk_free'
collect2.exe: error: ld returned 1 exit status
My script, a single .c file, contains the lines
#define USE_RINTERNALS
#include <R.h> // which itself #includes R_ext/Memory, R_ext Printf
#include <R_ext/Print.h>
#include <R_ext/Memory.h>
#include <Rinternals.h>
Figuring that Netbeans is failing to point to the relevant libraries, I have tried adding and removing C:/Program Files/R/R-3.2.4revised/include and C:/Program Files/R/R-3.2.4revised/bin/x64 at File→Project Properties→General→Source folders, to no effect.
Under File→Project Properties→Build→C compiler, I have included C:/Program Files/R/R-3.2.4revised/include.
When I add C:/Program Files/R/R-3.2.4revised/bin/x64/R.dll to Build→Linker→Libraries→Libraries, via the Add Library... option, I receive the error c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -lR, and the linker exits without (before?) complaining about the undefined references.
When I subsequently add "C:/Program Files/R/R-3.2.4revised/bin/x64/", which is already in by System PATH, to Build→Linker→Additional Library Directories, the compiler fails with the message C:/Program Files/R/R-3.2.4revised/bin/x64/R.dll: file not recognized: File format not recognized
What am I missing... how can I point Netbeans to the relevant R libraries?
The File format not recognized error is encountered when a 32-bit compiler tries to load to a 64-bit .dll (or vice-versa). Changing the path
C:/Program Files/R/R-3.2.4revised/bin/x64/R.dll
to
C:/Program Files/R/R-3.2.4revised/bin/i386/R.dll
resolved the problem.