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.
Related
I am trying to compile a piece of code on my Linux system (x86_64) for MIPS big endian architecture.
Basically I followed this URL:
https://www.linux-mips.org/wiki/Toolchains
to get my own tool chain.
I tried to compile software, configure phase is OK:
./configure --target=mips-unknown-linux-gnu --host=mips-unknown-linux-gnu CC=/opt/cross/bin/mips-unknown-linux-gnu-gcc --prefix=/opt/mycode
I get this error just after "make":
# make
make all-recursive
make[1]: Entering directory `/usr/local/src/code2.0.9'
Making all in compat
make[2]: Entering directory `/usr/local/src/code2.0.9/compat'
/opt/cross/bin/mips-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -Wall -O2 -MT Thread.o -MD -MP -MF .deps/Thread.Tpo -c -o Thread.o Thread.c
In file included from Thread.c:71:0:
../include/headers.h:78:20: fatal error: stdlib.h: No such file or directory
#include <stdlib.h>
How can I fix this issue?
Thank you
I finally solved with buildroot.
I set target mips and build my toolchain.
After that, I used this command to compile source:
./configure --enable-static --disable-shared --target=mips-buildroot-linux-gnu --host=mips-buildroot-linux-gnu CC=/home/myuser/buildroot-2019.05.1/output/host/bin/mips-linux-gcc --with-openssl=no --disable-profiling
All went ok
I think host command is not correct.
try this,
./configure --target=mips-unknown-linux-gnu --host=linux CC=/opt/cross/bin/mips-unknown-linux-gnu-gcc --prefix=/opt/mycode
I'm on a Windows machine and use MinGW, attempting to compile a hello world program that uses a shared library. After an absurd amount of attempts, I found out the following:
Manually compiling it with gcc and providing -I and -L flags for the required directories works fine.
Using the msys make.exe file provided under the MinGW/msys/1.0/bin installation directory properly executes a Makefile with no problems
Using the mingw32-make.exe provided under MinGW/bin doesn't work properly when trying to build using the same Makefile. From my understanding, it doesn't parse the -I and -L flags at all. It works fine if I add the dependencies (both includes and libs) under their respective MinGW directories.
These past few days while I was trying and familiarizing myself with these tools (I'm comfortable with C's syntax but know about nothing past that) I read many guides and no one seemed to have this issue (from the few that actually attempted this on a Windows machine without using an IDE). Did I miss something? Is my MinGW installation known to have this issue?
Note that at first I was attempting to compile the project using the 64-bit version of the library but failed. I'm guessing this means that I have a 32-bit MinGW installation.
Knowing that some will ask to see the Makefile:
CC = gcc
MY_LIB = -L/e/C_Projects/Libraries/MySharedLib/lib -lMyLibName
MY_INCLUDE = -I/e/C_Projects/Libraries/MySharedLib/include
CFLAGS = -Wall -c $(MY_INCLUDE)
LDFLAGS = -lmingw32 -mwindows $(MY_LIB)
EXE = Test.exe
all: $(EXE)
$(EXE): main.o
$(CC) $< $(LDFLAGS) -o $#
main.o: main.c
$(CC) $(CFLAGS) $< -o $#
clean:
del *.o && del $(EXE)
The error produced by mingw32-make.exe is the following
main.c:1:22: fatal error: MyLib.h: No such file or directory
#include <MyLib.h>
^
compilation terminated.
Makefile:19: recipe for target 'main.o' failed
mingw32-make: *** [main.o] Error 1
I'm trying to compile a program that uses both python.h and cl.h using: gcc -Wall -I/usr/include/python2.7 -lpython2.7 -I/home/arm/bin/c/hashcat/deps/OpenCL-Headers/CL -lOpenCL cpu_md4.c -o cpu_md4, however when I run this I get the following:
arm#arm-Aspire-5733Z:~/bin/python/dagon/bin/attacks/cpu_attack$ gcc -Wall -I/usr/include/python2.7 -lpython2.7 -I/home/arm/bin/c/hashcat/deps/OpenCL-Headers/CL -lOpenCL cpu_md4.c -o cpu_md4
In file included from types.h:889:0,
from cpu_md4.c:10:
ext_OpenCL.h:15:19: fatal error: CL/cl.h: No such file or directory
#include <CL/cl.h>
^
compilation terminated.
arm#arm-Aspire-5733Z:~/bin/python/dagon/bin/attacks/cpu_attack$
How I got the cl.h directory was doing this:
arm#arm-Aspire-5733Z:~/bin/python/dagon/bin/attacks/cpu_attack$ find / -iname cl.h 2>/dev/null
/home/arm/bin/c/hashcat/deps/OpenCL-Headers/CL/cl.h
How can I compile this application using the header files that I already have?
I am having trouble linking to the libpng library.
The build seems unable to define references to Libpng calls.
I think the problem is in my Libpng install.
I am runing in the Mingw environment on a Win7 laptop
My build environment is as follows:
My path starts with C:\MinGW\bin;C:\MinGW\msys\1.0\bin;C:\MinGW\git\cmd;C:\Program Files
C:\Users\Bob\Home\png23d>g++ --version
g++ (GCC) 5.3.0
I have built and installed libpng-1.6.28 which creates the following:
C:\MinGW\bin>
libpng-config
libpng16-config
libpng16.dll
C:\MinGW\include\libpng
png.h
pngconf.h
pnglibconf.h
C:\MinGW\include\libpng16
png.h
pngconf.h
pnglibconf.h
C:\MinGW\lib\pkgconfig
C:\MinGW\lib>
libpng.a
libpng.dll.a
libpng16.a
libpng16.dll.a
a symbolic link `libpng' to `libpng16'
a symbolic link `libpng.pc' to `libpng16.pc'
a symbolic link `libpng.a' to `libpng16.a'
a symbolic link `libpng-config' to `libpng16-config
when I try to build a program "png23d" I get the following
C:\Users\Bob\Home\png23d>make
g++ -DUSE_LIBPNG -lpng png23d.o option.o bitmap.o mesh.o mesh_gen.o mesh_index.o mesh_simplify.o out_pgm.o out_rscad.o out_pscad.o out_stl.o -o png23d
bitmap.o:bitmap.c:(.text+0x102): undefined reference to `png_sig_cmp'
bitmap.o:bitmap.c:(.text+0x142): undefined reference to `png_create_read_struct'
.
.
.
bitmap.o:bitmap.c:(.text+0x418): undefined reference to `png_read_end'
bitmap.o:bitmap.c:(.text+0x466): undefined reference to `png_destroy_read_struct'
collect2.exe: error: ld returned 1 exit status
<builtin>: recipe for target 'png23d' failed
make: *** [png23d] Error 1
I am almost sure its the -lpng that is not working.... I am just don't know how to fix it.
I am guessing that it is a symbolic link problem and I know I did not create one during the libpng build.
If I am right what do I need to link it to.
I tried changing -lpng to -llpng16. It made no difference.
Thanks from the command prompt that work fine.
just have to figure out how to change the make file.
#!/usr/bin/make
#
# png23d is a program to convert png images into 3d files
#
# Copyright 2011 Vincent Sanders <vince#kyllikki.org>
#
# Released under the MIT License,
# http://www.opensource.org/licenses/mit-license.php
CC = g++
VERSION=100
PREFIX =
WARNFLAGS = -W -Wall -Wundef -Wpointer-arith \
-Wcast-align -Wwrite-strings -Wstrict-prototypes \
-Wmissing-prototypes -Wmissing-declarations -Wredundant-decls \
-Wnested-externs
ifneq ($(GCCVER),2)
WARNFLAGS += -Wno-unused-parameter
endif
OPTFLAGS=-O2
#OPTFLAGS=-O0
CFLAGS+=$(WARNFLAGS) -MMD -DVERSION=$(VERSION) $(OPTFLAGS) -g
LDFLAGS+= -DUSE_LIBPNG -lpng
PNG23D_OBJ=png23d.o option.o bitmap.o mesh.o mesh_gen.o mesh_index.o mesh_simplify.o out_pgm.o out_rscad.o out_pscad.o out_stl.o
.PHONY : all clean
all:png23d
png23d:$(PNG23D_OBJ)
-include $(PNG23D_OBJ:.o=.d)
-include test/Makefile.sub
clean: testclean
${RM} png23d $(PNG23D_OBJ) *.d *~ png23d.png
install:png23d
install -D png23d $(DESTDIR)$(PREFIX)/bin
install-man:png23d.1
install -D png23d.1 $(DESTDIR)$(PREFIX)/share/man/man1
# logo creation
png23d.png:png23d.pov
povray +L/usr/share/povray/include/ -D +Q11 +O$# +UV +UL +A0.2 +FP8 +W400 +H300 $<
Move -lpng to after the object files.
I have the following code:
gcc -Wall -fno-stack-protector -O2 -g -fPIC -c ec.c
pwd
gcc -shared -Wl,-soname,libec.so.1 -o libec.so.1.0 ec.o /urs/src/soem/ethercat*.o ../soem/nicdrv.o -lc -lpthread
mv libec.so.1.0 /usr/lib/.
cd /usr/lib
ldconfig -v -n
ln -sf libec.so.1.0 libec.so
ln -sf libec.so.1.0 libec.so.1
It gives the following error when compiling:
/home/ebox/Documents/SVN/Libs/ec
gcc: error: /urs/src/soem/ethercat*.o: No such file or directory
mv: cannot stat ‘libec.so.1.0’: No such file or directory
I understand there is something wrong with the gcc command, but cannot figure out how to fix this. There are several .o files in the path that start with ethercat*.
How can I get this fixed?
The error means that there are no files that match the pattern /urs/src/soem/ethercat*.o.
Note that the first component is urs. Probably it should be usr.