Undefined reference errors in gcc when compiling on another machine - c

I wrote a program (myreader.c) to manipulate a RFID reader.
I compile by type "make" in the root of the package, makefile is shown below
# CC and CFLAGS are varilables
CC=gcc
CFLAGS = -c
# -c option ask g++ to compile the source files, but do not link.
# -g option is for debugging version
# -O2 option is for optimized version
OPTFLAGS = -O2 -g
myreader : src/myreader.c
$(CC) $(OPTFLAGS) src/myreader.c src/crypto1.c src/nfc-utils.c -lnfc -o ./bin/myreader
# clean all the .o and executable files
clean:
rm -rf bin/myreader
and it works well on my original machine(64 bits, Ubuntu 12.04 LTS), and the only problem is, when I type make, the warning info would come up.
src/myreader.c:519:6: warning: conflicting types for ‘printResult’ [enabled by default]
src/myreader.c:211:3: note: previous implicit declaration of ‘printResult’ was here
But /bin/myreader works well.
However, when I move the package to another machine(64 bits, Ubuntu 11.10), and type make in the same way as in the original machine.
Error messages in the below appears:
berln#ubuntu:~/桌面/useful code$ make
gcc -O2 -g src/myreader.c src/crypto1.c src/nfc-utils.c -lnfc -o ./bin/myreader
src/myreader.c:519:6: warning: conflicting types for ‘printResult’ [enabled by default]
src/myreader.c:211:3: note: previous implicit declaration of ‘printResult’ was here
/tmp/ccrKvhjm.o: In function `mf_enhanced_auth':/home/berln/桌面/useful code/src/myreader.c:373: undefined reference to `nfc_configure'
/home/berln/桌面/useful code/src/myreader.c:380: undefined reference to `nfc_configure'
/home/berln/桌面/useful code/src/myreader.c:390: undefined reference to `nfc_configure'
/home/berln/桌面/useful code/src/myreader.c:434: undefined reference to `nfc_configure'
/tmp/ccrKvhjm.o: In function `mf_configure':
/home/berln/桌面/useful code/src/myreader.c:484: undefined reference to `nfc_configure'
/tmp/ccrKvhjm.o:/home/berln/桌面/useful code/src/myreader.c:489: more undefined references to `nfc_configure' follow
/tmp/ccrKvhjm.o: In function `main':
/home/berln/桌面/useful code/src/myreader.c:155: undefined reference to `nfc_connect'
/home/berln/桌面/useful code/src/myreader.c:213: undefined reference to `nfc_disconnect'
collect2: ld returned 1 exit status
make: *** [myreader] Error 1
I have no ideas why this error happened on only one machine instead of both.
If you need more information, you can download the package here.
Thanks in advance.

It seems the problem is in the nfc library, but the linker doesn't complain that it's missing, so something wrong with it. Try to recompile it. If it's a package check that it's the same version as on the other server.

Most likely your nfc library is missing or not installed properly on your other computer.
One of the options you pass to the linker is -lnfc, which tells it to link to the nfc library. Your errors are coming from the linker, which cannot find the nfc_configure and other nfc_ symbols. This means that the linker cannot find these symbols. Check the nfc library installation.

Related

Installing AODV protocol on Raspberry pi (https://github.com/erimatnor/aodv-uu)

I'm trying to install AODV protocol on Raspberry pi. After completing git clone from "https://github.com/erimatnor/aodv-uu" when I tried to do "make" and I am getting below error. Expecting your suggestion. Thank you!
make
gcc -Wall -O3 -g -DDEBUG -DCONFIG_GATEWAY -DDEBUG -o aodvd main.o list.o debug.o timer_queue.o aodv_socket.o aodv_hello.o aodv_neighbor.o aodv_timeout.o routing_table.o seek_list.o aodv_rreq.o aodv_rrep.o aodv_rerr.o nl.o locality.o
aodv_neighbor.o: In function neighbor_add':
/home/pi/aodv-uu/aodv_neighbor.c:68: undefined reference tohello_update_timeout'
aodv_timeout.o: In function route_discovery_timeout':
/home/pi/aodv-uu/aodv_timeout.c:98: undefined reference tort_table_update_timeout'
aodv_rreq.o: In function rreq_route_discovery':
/home/pi/aodv-uu/aodv_rreq.c:460: undefined reference tort_table_update_timeout'
aodv_rreq.o: In function rreq_local_repair':
/home/pi/aodv-uu/aodv_rreq.c:521: undefined reference tort_table_update_timeout'
aodv_rrep.o: In function rrep_forward':
/home/pi/aodv-uu/aodv_rrep.c:231: undefined reference tort_table_update_timeout'
nl.o: In function nl_kaodv_callback':
/home/pi/aodv-uu/nl.c:282: undefined reference tort_table_update_timeout'
collect2: error: ld returned 1 exit status
Makefile:112: recipe for target 'aodvd' failed
make: *** [aodvd] Error 1
The code available from sourceforge is the same code that is on github. If you download the archive, you'll see that the latest modification date of any file there is 2010. Given the age of this code, I wouldn't be surprised to find that things simply don't work anymore.
However, here's a quick workaround for your problem. The root cause appears to be that the problem functions, like rt_table_update_timeout, are declared as inline, but that information seems to get lost somewhere in the build process such that other object files are trying to reference these as non-inline functions.
You can avoid this by opening defs.h, looking for this line:
#define NS_INLINE inline
And replace it with:
#define NS_INLINE
This will allow aodvd to compile correctly (make aodvd). On my system, the kernel module will subsequently fail to compile:
cc1: fatal error: /lib/modules/4.13.15-100.fc25.x86_64/build/include/linux/modversions.h: No such file or directory
As far as I can tell, the modversions.h file is no longer produced by modern Linux kernels.

The procedure entry point axiom_attribute_create could not be located in the dynamic link library

I have a project in c and I want to compile it in CodeBlocks with MinGW.
I tried to link its needed libraries but I got
undefined reference error
so I searched and found out that the libraries that I was using was compiled with MVC++ and cannot be used with MinGW. (I am not an expert in c, so I'm a little bit confused.) I found This link and did what they said in order to solve my problem.
I have created axis2c .a files from the original axis2c .dll files.
I created .def files with reimp
then I modified each stdcall function in .def files (I changed "_name#ordinal" to "name")
then I used dlltool to create .a files.
I linked the .a files to my project. Everything went fine and I could compile my project. but when I try to run it. I get this error.
The procedure entry point axiom_attribute_create could not be located in the dynamic link library
I have included my project in this Link.
I downloaded a CodeBlocks with MinGW. codeblocks-10.05mingw-setup.exe (which I guess uses MinGw32bit).Then I followed the steps that #mikekinghan said to set up Build Options. Then I built the project. I got this error.
I have already added Axis2c lib folder to path Environment. (I even copied axiom.dll to "C:\Windows\SysWOW64" as #mikekinghan suggested.
Here is the build log :
-------------- Build: Debug in Math ---------------
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\adb_addOperatorResponse.c -o obj\Debug\adb_addOperatorResponse.o
In file included from C:\Tools\axis2c\include/platforms/axutil_platform_auto_sense.h:40,
from C:\Tools\axis2c\include/axutil_dll_desc.h:31,
from C:\Tools\axis2c\include/axutil_class_loader.h:31,
from C:\Tools\axis2c\include/axis2_util.h:24,
from E:\dev\c\Math\adb_addOperatorResponse.h:21,
from E:\dev\c\Math\adb_addOperatorResponse.c:10:
C:\Tools\axis2c\include/platforms/windows/axutil_windows.h:221:5: warning: "/*" within comment
E:\dev\c\Math\adb_addOperatorResponse.c: In function 'adb_addOperatorResponse_serialize_obj':
E:\dev\c\Math\adb_addOperatorResponse.c:466: warning: format '%I32d' expects type 'long int', but argument 3 has type 'int'
E:\dev\c\Math\adb_addOperatorResponse.c:374: warning: unused variable 'ns_already_defined'
E:\dev\c\Math\adb_addOperatorResponse.c:372: warning: unused variable 'qname_prefix'
E:\dev\c\Math\adb_addOperatorResponse.c:371: warning: unused variable 'qname_uri'
E:\dev\c\Math\adb_addOperatorResponse.c:367: warning: unused variable 'tag_closed'
E:\dev\c\Math\adb_addOperatorResponse.c: In function 'adb_addOperatorResponse_reset_addOperatorReturn':
E:\dev\c\Math\adb_addOperatorResponse.c:568: warning: unused variable 'element'
E:\dev\c\Math\adb_addOperatorResponse.c:567: warning: unused variable 'count'
E:\dev\c\Math\adb_addOperatorResponse.c:566: warning: unused variable 'i'
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\axis2_extension_mapper.c -o obj\Debug\axis2_extension_mapper.o
In file included from C:\Tools\axis2c\include/platforms/axutil_platform_auto_sense.h:40,
from C:\Tools\axis2c\include/axutil_dll_desc.h:31,
from C:\Tools\axis2c\include/axutil_class_loader.h:31,
from C:\Tools\axis2c\include/axis2_util.h:24,
from E:\dev\c\Math\axis2_extension_mapper.h:14,
from E:\dev\c\Math\axis2_extension_mapper.c:10:
C:\Tools\axis2c\include/platforms/windows/axutil_windows.h:221:5: warning: "/*" within comment
E:\dev\c\Math\axis2_extension_mapper.c: In function 'axis2_extension_mapper_type_from_node':
E:\dev\c\Math\axis2_extension_mapper.c:31: warning: unused variable 'element_qname'
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\axis2_stub_MathService.c -o obj\Debug\axis2_stub_MathService.o
In file included from C:\Tools\axis2c\include/platforms/axutil_platform_auto_sense.h:40,
from C:\Tools\axis2c\include/axutil_dll_desc.h:31,
from C:\Tools\axis2c\include/axutil_class_loader.h:31,
from C:\Tools\axis2c\include/axis2_util.h:24,
from C:\Tools\axis2c\include/neethi_includes.h:22,
from C:\Tools\axis2c\include/neethi_operator.h:29,
from C:\Tools\axis2c\include/neethi_policy.h:29,
from C:\Tools\axis2c\include/axis2_svc_client.h:56,
from C:\Tools\axis2c\include/axis2_stub.h:35,
from C:\Tools\axis2c\include/axis2_client.h:31,
from E:\dev\c\Math\axis2_stub_MathService.h:14,
from E:\dev\c\Math\axis2_stub_MathService.c:10:
C:\Tools\axis2c\include/platforms/windows/axutil_windows.h:221:5: warning: "/*" within comment
E:\dev\c\Math\axis2_stub_MathService.c: In function 'axis2_stub_populate_services_for_MathService':
E:\dev\c\Math\axis2_stub_MathService.c:72: warning: unused variable 'status'
E:\dev\c\Math\axis2_stub_MathService.c:71: warning: unused variable 'neethi_policy'
E:\dev\c\Math\axis2_stub_MathService.c:70: warning: unused variable 'policy_root_ele'
E:\dev\c\Math\axis2_stub_MathService.c:69: warning: unused variable 'policy_node'
E:\dev\c\Math\axis2_stub_MathService.c:68: warning: unused variable 'desc'
E:\dev\c\Math\axis2_stub_MathService.c:66: warning: unused variable 'policy_include'
E:\dev\c\Math\axis2_stub_MathService.c: In function 'axis2_stub_on_complete_MathService_addOperator':
E:\dev\c\Math\axis2_stub_MathService.c:277: warning: unused variable 'soap_fault'
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\main.c -o obj\Debug\main.o
In file included from C:\Tools\axis2c\include/platforms/axutil_platform_auto_sense.h:40,
from C:\Tools\axis2c\include/axutil_dll_desc.h:31,
from C:\Tools\axis2c\include/axutil_class_loader.h:31,
from C:\Tools\axis2c\include/axis2_util.h:24,
from C:\Tools\axis2c\include/neethi_includes.h:22,
from C:\Tools\axis2c\include/neethi_operator.h:29,
from C:\Tools\axis2c\include/neethi_policy.h:29,
from C:\Tools\axis2c\include/axis2_svc_client.h:56,
from C:\Tools\axis2c\include/axis2_stub.h:35,
from C:\Tools\axis2c\include/axis2_client.h:31,
from E:\dev\c\Math\axis2_stub_MathService.h:14,
from E:\dev\c\Math\main.c:1:
C:\Tools\axis2c\include/platforms/windows/axutil_windows.h:221:5: warning: "/*" within comment
E:\dev\c\Math\main.c:3: warning: second argument of 'main' should be 'char **'
E:\dev\c\Math\main.c: In function 'main':
E:\dev\c\Math\main.c:8: warning: unused variable 'operation'
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\adb_addOperator.c -o obj\Debug\adb_addOperator.o
In file included from C:\Tools\axis2c\include/platforms/axutil_platform_auto_sense.h:40,
from C:\Tools\axis2c\include/axutil_dll_desc.h:31,
from C:\Tools\axis2c\include/axutil_class_loader.h:31,
from C:\Tools\axis2c\include/axis2_util.h:24,
from E:\dev\c\Math\adb_addOperator.h:21,
from E:\dev\c\Math\adb_addOperator.c:10:
C:\Tools\axis2c\include/platforms/windows/axutil_windows.h:221:5: warning: "/*" within comment
E:\dev\c\Math\adb_addOperator.c: In function 'adb_addOperator_serialize_obj':
E:\dev\c\Math\adb_addOperator.c:574: warning: format '%I32d' expects type 'long int', but argument 3 has type 'int'
E:\dev\c\Math\adb_addOperator.c:640: warning: format '%I32d' expects type 'long int', but argument 3 has type 'int'
E:\dev\c\Math\adb_addOperator.c:480: warning: unused variable 'ns_already_defined'
E:\dev\c\Math\adb_addOperator.c:478: warning: unused variable 'qname_prefix'
E:\dev\c\Math\adb_addOperator.c:477: warning: unused variable 'qname_uri'
E:\dev\c\Math\adb_addOperator.c:473: warning: unused variable 'tag_closed'
E:\dev\c\Math\adb_addOperator.c: In function 'adb_addOperator_reset_num1':
E:\dev\c\Math\adb_addOperator.c:742: warning: unused variable 'element'
E:\dev\c\Math\adb_addOperator.c:741: warning: unused variable 'count'
E:\dev\c\Math\adb_addOperator.c:740: warning: unused variable 'i'
E:\dev\c\Math\adb_addOperator.c: In function 'adb_addOperator_reset_num2':
E:\dev\c\Math\adb_addOperator.c:848: warning: unused variable 'element'
E:\dev\c\Math\adb_addOperator.c:847: warning: unused variable 'count'
E:\dev\c\Math\adb_addOperator.c:846: warning: unused variable 'i'
mingw32-g++.exe -LC:\Tools\axis2c\include -LE:\dev\CodeBlocks\MinGW\lib -o bin\Debug\Math.exe obj\Debug\adb_addOperatorResponse.o obj\Debug\axis2_extension_mapper.o obj\Debug\axis2_stub_MathService.o obj\Debug\main.o obj\Debug\adb_addOperator.o -laxiom -laxutil -laxis2_engine -laxis2_parser
e:/dev/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: cannot find -laxiom
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 6 seconds)
1 errors, 35 warnings
It seems that I made a mistake putting ../include in Search Directories>Linker I fixed that mistake.
I build the project then I get this :
-------------- Build: Debug in Math ---------------
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\adb_addOperatorResponse.c -o obj\Debug\adb_addOperatorResponse.o
In file included from C:\Tools\axis2c\include/platforms/axutil_platform_auto_sense.h:40,
from C:\Tools\axis2c\include/axutil_dll_desc.h:31,
from C:\Tools\axis2c\include/axutil_class_loader.h:31,
from C:\Tools\axis2c\include/axis2_util.h:24,
from E:\dev\c\Math\adb_addOperatorResponse.h:21,
from E:\dev\c\Math\adb_addOperatorResponse.c:10:
C:\Tools\axis2c\include/platforms/windows/axutil_windows.h:221:5: warning: "/*" within comment
E:\dev\c\Math\adb_addOperatorResponse.c: In function 'adb_addOperatorResponse_serialize_obj':
E:\dev\c\Math\adb_addOperatorResponse.c:466: warning: format '%I32d' expects type 'long int', but argument 3 has type 'int'
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\axis2_extension_mapper.c -o obj\Debug\axis2_extension_mapper.o
In file included from C:\Tools\axis2c\include/platforms/axutil_platform_auto_sense.h:40,
from C:\Tools\axis2c\include/axutil_dll_desc.h:31,
from C:\Tools\axis2c\include/axutil_class_loader.h:31,
from C:\Tools\axis2c\include/axis2_util.h:24,
from E:\dev\c\Math\axis2_extension_mapper.h:14,
from E:\dev\c\Math\axis2_extension_mapper.c:10:
C:\Tools\axis2c\include/platforms/windows/axutil_windows.h:221:5: warning: "/*" within comment
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\axis2_stub_MathService.c -o obj\Debug\axis2_stub_MathService.o
In file included from C:\Tools\axis2c\include/platforms/axutil_platform_auto_sense.h:40,
from C:\Tools\axis2c\include/axutil_dll_desc.h:31,
from C:\Tools\axis2c\include/axutil_class_loader.h:31,
from C:\Tools\axis2c\include/axis2_util.h:24,
from C:\Tools\axis2c\include/neethi_includes.h:22,
from C:\Tools\axis2c\include/neethi_operator.h:29,
from C:\Tools\axis2c\include/neethi_policy.h:29,
from C:\Tools\axis2c\include/axis2_svc_client.h:56,
from C:\Tools\axis2c\include/axis2_stub.h:35,
from C:\Tools\axis2c\include/axis2_client.h:31,
from E:\dev\c\Math\axis2_stub_MathService.h:14,
from E:\dev\c\Math\axis2_stub_MathService.c:10:
C:\Tools\axis2c\include/platforms/windows/axutil_windows.h:221:5: warning: "/*" within comment
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\main.c -o obj\Debug\main.o
In file included from C:\Tools\axis2c\include/platforms/axutil_platform_auto_sense.h:40,
from C:\Tools\axis2c\include/axutil_dll_desc.h:31,
from C:\Tools\axis2c\include/axutil_class_loader.h:31,
from C:\Tools\axis2c\include/axis2_util.h:24,
from C:\Tools\axis2c\include/neethi_includes.h:22,
from C:\Tools\axis2c\include/neethi_operator.h:29,
from C:\Tools\axis2c\include/neethi_policy.h:29,
from C:\Tools\axis2c\include/axis2_svc_client.h:56,
from C:\Tools\axis2c\include/axis2_stub.h:35,
from C:\Tools\axis2c\include/axis2_client.h:31,
from E:\dev\c\Math\axis2_stub_MathService.h:14,
from E:\dev\c\Math\main.c:1:
C:\Tools\axis2c\include/platforms/windows/axutil_windows.h:221:5: warning: "/*" within comment
E:\dev\c\Math\main.c:3: warning: second argument of 'main' should be 'char **'
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\adb_addOperator.c -o obj\Debug\adb_addOperator.o
In file included from C:\Tools\axis2c\include/platforms/axutil_platform_auto_sense.h:40,
from C:\Tools\axis2c\include/axutil_dll_desc.h:31,
from C:\Tools\axis2c\include/axutil_class_loader.h:31,
from C:\Tools\axis2c\include/axis2_util.h:24,
from E:\dev\c\Math\adb_addOperator.h:21,
from E:\dev\c\Math\adb_addOperator.c:10:
C:\Tools\axis2c\include/platforms/windows/axutil_windows.h:221:5: warning: "/*" within comment
E:\dev\c\Math\adb_addOperator.c: In function 'adb_addOperator_serialize_obj':
E:\dev\c\Math\adb_addOperator.c:574: warning: format '%I32d' expects type 'long int', but argument 3 has type 'int'
E:\dev\c\Math\adb_addOperator.c:640: warning: format '%I32d' expects type 'long int', but argument 3 has type 'int'
mingw32-g++.exe -LC:\Tools\axis2c\lib -LE:\dev\CodeBlocks\MinGW\lib -o bin\Debug\Math.exe obj\Debug\adb_addOperatorResponse.o obj\Debug\axis2_extension_mapper.o obj\Debug\axis2_stub_MathService.o obj\Debug\main.o obj\Debug\adb_addOperator.o -laxiom -laxutil -laxis2_engine -laxis2_parser
obj\Debug\adb_addOperatorResponse.o: In function `adb_addOperatorResponse_create':
E:/dev/c/Math/adb_addOperatorResponse.c:58: undefined reference to `_imp__axutil_error_set_error_number'
E:/dev/c/Math/adb_addOperatorResponse.c:58: undefined reference to `_imp__axutil_error_set_status_code'
E:/dev/c/Math/adb_addOperatorResponse.c:64: undefined reference to `_imp__axutil_strdup'
E:/dev/c/Math/adb_addOperatorResponse.c:67: undefined reference to `_imp__axutil_qname_create'
obj\Debug\adb_addOperatorResponse.o: In function `adb_addOperatorResponse_free_obj':
E:/dev/c/Math/adb_addOperatorResponse.c:139: undefined reference to `_imp__axutil_error_set_error_number'
E:/dev/c/Math/adb_addOperatorResponse.c:139: undefined reference to `_imp__axutil_error_set_status_code'
E:/dev/c/Math/adb_addOperatorResponse.c:139: undefined reference to `_imp__axutil_error_set_status_code'
E:/dev/c/Math/adb_addOperatorResponse.c:150: undefined reference to `_imp__axutil_qname_free'
obj\Debug\adb_addOperatorResponse.o: In function `adb_addOperatorResponse_deserialize_obj':
E:/dev/c/Math/adb_addOperatorResponse.c:209: undefined reference to `_imp__axutil_error_set_error_number'
E:/dev/c/Math/adb_addOperatorResponse.c:209: undefined reference to `_imp__axutil_error_set_status_code'
E:/dev/c/Math/adb_addOperatorResponse.c:209: undefined reference to `_imp__axutil_error_set_status_code'
E:/dev/c/Math/adb_addOperatorResponse.c:215: undefined reference to `_imp__axiom_node_get_next_sibling'
E:/dev/c/Math/adb_addOperatorResponse.c:213: undefined reference to `_imp__axiom_node_get_node_type'
E:/dev/c/Math/adb_addOperatorResponse.c:227: undefined reference to `_imp__axiom_node_get_data_element'
E:/dev/c/Math/adb_addOperatorResponse.c:228: undefined reference to `_imp__axiom_element_get_qname'
E:/dev/c/Math/adb_addOperatorResponse.c:229: undefined reference to `_imp__axutil_qname_equals'
E:/dev/c/Math/adb_addOperatorResponse.c:232: undefined reference to `_imp__axiom_node_get_first_child'
E:/dev/c/Math/adb_addOperatorResponse.c:237: undefined reference to `_imp__axutil_qname_to_string'
E:/dev/c/Math/adb_addOperatorResponse.c:237: undefined reference to `_imp__axutil_qname_to_string'
E:/dev/c/Math/adb_addOperatorResponse.c:260: undefined reference to `_imp__axiom_node_get_next_sibling'
E:/dev/c/Math/adb_addOperatorResponse.c:258: undefined reference to `_imp__axiom_node_get_node_type'
E:/dev/c/Math/adb_addOperatorResponse.c:264: undefined reference to `_imp__axiom_node_get_data_element'
E:/dev/c/Math/adb_addOperatorResponse.c:265: undefined reference to `_imp__axiom_element_get_qname'
E:/dev/c/Math/adb_addOperatorResponse.c:268: undefined reference to `_imp__axutil_qname_create'
E:/dev/c/Math/adb_addOperatorResponse.c:272: undefined reference to `_imp__axutil_qname_equals'
E:/dev/c/Math/adb_addOperatorResponse.c:274: undefined reference to `_imp__axutil_qname_equals'
E:/dev/c/Math/adb_addOperatorResponse.c:280: undefined reference to `_imp__axiom_element_get_text'
E:/dev/c/Math/adb_addOperatorResponse.c:298: undefined reference to `_imp__axutil_qname_free'
E:/dev/c/Math/adb_addOperatorResponse.c:308: undefined reference to `_imp__axutil_qname_free'
E:/dev/c/Math/adb_addOperatorResponse.c:317: undefined reference to `_imp__axutil_qname_free'
obj\Debug\adb_addOperatorResponse.o: In function `adb_addOperatorResponse_serialize_obj':
E:/dev/c/Math/adb_addOperatorResponse.c:392: undefined reference to `_imp__axutil_error_set_error_number'
E:/dev/c/Math/adb_addOperatorResponse.c:392: undefined reference to `_imp__axutil_error_set_status_code'
E:/dev/c/Math/adb_addOperatorResponse.c:392: undefined reference to `_imp__axutil_error_set_status_code'
E:/dev/c/Math/adb_addOperatorResponse.c:395: undefined reference to `_imp__axutil_hash_make'
E:/dev/c/Math/adb_addOperatorResponse.c:398: undefined reference to `_imp__axiom_namespace_create'
E:/dev/c/Math/adb_addOperatorResponse.c:401: undefined reference to `_imp__axutil_strdup'
E:/dev/c/Math/adb_addOperatorResponse.c:401: undefined reference to `_imp__axutil_hash_set'
E:/dev/c/Math/adb_addOperatorResponse.c:404: undefined reference to `_imp__axiom_element_create'
E:/dev/c/Math/adb_addOperatorResponse.c:407: undefined reference to `_imp__axiom_element_set_namespace'
E:/dev/c/Math/adb_addOperatorResponse.c:411: undefined reference to `_imp__axiom_data_source_create'
E:/dev/c/Math/adb_addOperatorResponse.c:412: undefined reference to `_imp__axiom_data_source_get_stream'
E:/dev/c/Math/adb_addOperatorResponse.c:414: undefined reference to `_imp__axutil_hash_get'
E:/dev/c/Math/adb_addOperatorResponse.c:418: undefined reference to `_imp__axutil_hash_set'
E:/dev/c/Math/adb_addOperatorResponse.c:420: undefined reference to `_imp__axiom_namespace_create'
E:/dev/c/Math/adb_addOperatorResponse.c:420: undefined reference to `_imp__axiom_element_declare_namespace_assume_param_ownership'
E:/dev/c/Math/adb_addOperatorResponse.c:436: undefined reference to `_imp__axutil_strlen'
E:/dev/c/Math/adb_addOperatorResponse.c:436: undefined reference to `_imp__axutil_strlen'
E:/dev/c/Math/adb_addOperatorResponse.c:441: undefined reference to `_imp__axutil_strlen'
E:/dev/c/Math/adb_addOperatorResponse.c:441: undefined reference to `_imp__axutil_strlen'
E:/dev/c/Math/adb_addOperatorResponse.c:458: undefined reference to `_imp__axutil_strcmp'
Process terminated with status 1 (0 minutes, 9 seconds)
50 errors, 9 warnings
Form what #MikeKinghan tried to teach me, I understand the meaning of Linker commands now, and I see that the Linker is set correctly this time. but why can't it compile properly?
Your project contains 5 source files, which each has to be successfully compiled, and then all
need linked together, along with some axis2c DLLs, to build your program.
Let's look at your build log.
There is a compile command for each of the 5 source files:
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\adb_addOperatorResponse.c -o obj\Debug\adb_addOperatorResponse.o
...
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\axis2_extension_mapper.c -o obj\Debug\axis2_extension_mapper.o
...
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\axis2_stub_MathService.c -o obj\Debug\axis2_stub_MathService.o
...
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\main.c -o obj\Debug\main.o
...
mingw32-gcc.exe -Wall -g -IC:\Tools\axis2c\include -IE:\dev\CodeBlocks\MinGW -c E:\dev\c\Math\adb_addOperator.c -o obj\Debug\adb_addOperator.o
...
and then there is a link command:
mingw32-g++.exe -LC:\Tools\axis2c\include -LE:\dev\CodeBlocks\MinGW\lib -o bin\Debug\Math.exe obj\Debug\adb_addOperatorResponse.o obj\Debug\axis2_extension_mapper.o obj\Debug\axis2_stub_MathService.o obj\Debug\main.o obj\Debug\adb_addOperator.o -laxiom -laxutil -laxis2_engine -laxis2_parser
...
Copy/paste these commands out somewhere where you can see them from end to end.
In all of the places where I have put '...', the compiler or linker has emitted some complaint about your program.
All of the diagnostics emitted by the 5 compile commands are warnings. Whatever is not right, it doesn't actually stop the compiler from compiling the source
file (.c) into an object file (.o). If there had been any compilation errors in any .c file, then the compiler would not have been able to create the .o file,
and the build would have stopped without attempting to link the program, because linking it when some object files are missing would be futile.
This does not mean you don't have to bother about the compiler warnings. They might be warnings about possible bugs in your program, and some of them are.
So you'll need to fix them.
The link command has failed. You have no program, which is your top problem.
In order to make sense of compiler and linker diagnostics, and be able to fix them yourself, you need to understand what the compiler and linker commands mean.
We can see that the toolchain Code::Blocks is driving for you is the MinGW project's 32-bit Windows port of GCC (The GNU Compiler Collection).
GCC is the daddy of C/C++ programming toolchains: it's supported for every operating system and every processor; it's used in every application domain.
It's completely independent of any of the numerous IDEs that you can get to drive it, and all of those IDEs (Eclipse, Code::Blocks, KDevelop, CodeLite, Anjuta,
Dev-C++, etc.) come to you with the implicit assumption that you understand compiling and linking with GCC. At least, none of them can save you from having
to understand compiling and linking with GCC.
Before going any further then, the life-lesson of all this is going to be: Kick away your IDE for a while. Learn about building programs with GCC, itself.
Then it will be obvious how to do it with your IDE.
All of your compile commands are executed by mingw32-gcc.exe. That's the GCC tool-driver, in its C compiler "posture". If you look in the directory where it's installed,
maybe C:\MinGW\bin, you'll see also programs gcc.exe, g++.exe, plus those two with the prefix mingw32-. All of these programs
are the GCC tool driver, in different "postures" adapted to different roles.
Your link command is executed by mingw32-g++.exe. That's the GCC tool-driver again, in its C++ linker "posture". It may seem puzzling that Code::Blocks
by default configures the C++ linker to link C programs. It does that because C++ linkage works for programs that are all C, all C++, or a mixture of the two.
But C linkage won't work for C++ programs.
Whatever "posture" is suggested by the name, the GCC tool driver figures out what needs to be done by inspecting the options on its commandline and the file extensions
of the files that are passed to it. So it tries to compile each of your .c source files as C because they are .c files.
If they were .cpp files then it would try to compile them as C++. Once it figures out what it do, it delegates the work to an appropriate specialized tool -
C compiler, C++ compiler, assembler, linker.
Here's what each of your compile commands means:
-Wall => Enable all warnings
-g => Generate debugging information in the object file.
-IC:\Tools\axis2c\include => Search for non-standard header files in C:\Tools\axis2c\include
-IE:\dev\CodeBlocks\MinGW => Also search for non-standard header files in E:\dev\CodeBlocks\MinGW
-c => Just compile; don't link
E:\dev\c\Math\some_filename.c => Compile this file.
-o obj\Debug\some_filename.o => Output the object file obj\Debug\some_filename.o
And here's what your link command means:
-LC:\Tools\axis2c\include => Search for non-standard libraries (.lib, .a, .dll) in C:\Tools\axis2c\include
-LE:\dev\CodeBlocks\MinGW\lib => Also search for non-standard libraries in E:\dev\CodeBlocks\MinGW\lib
-o bin\Debug\Math.exe => Output the executable bin\Debug\Math.exe
obj\Debug\adb_addOperatorResponse.o => Link this object file
obj\Debug\axis2_extension_mapper.o => Also link this object file
obj\Debug\axis2_stub_MathService.o => Also link this object file
obj\Debug\main.o => Also link this object file
obj\Debug\adb_addOperator.o => Also link this object file
-laxiom => Link the libary axiom.dll or failing that, axiom.lib or libaxiom.a, wherever it is first found in the specified linker
search directories (-L), or failing that in the linker's standard directories.
-laxutil => Link the libary axutil.dll or failing that, axutil.lib or libaxutil.a, etc...
-laxis2_engine => Link the libary axis2_engine.dll or failing that, axis2_engine.lib or libaxis2_engine.a, etc...
-laxis2_parser => Link the libary axis2_parser.dll or failing that, axis2_parser.lib or libaaxis2_parser.a, etc...
You might wonder how the tool-driver knows that the link command is a link command, and not perhaps a C++ compile command?
It knows there is no compiling to do because none of the input files can be compiled. They are all object files (.o).
And it knows it is supposed to link them because it hasn't been told not to link them: the -c option is absent.
You linkage failed because:
e:/dev/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: cannot find -laxiom
ld.exe is the linker itself: the specialized tool that the GCC tool driver invokes when there is linking to be done.
It can't find your axiom library in any of the linker search directories you specified (-L), nor, of course, in
any of the standard search directories.
Now that you understand the meaning of your link command, it will be easy for you to see what's wrong. The linker
search directories that you specified are:
C:\Tools\axis2c\include
E:\dev\CodeBlocks\MinGW\lib
and your axis2c libraries (axiom.dll etc) aren't in either of those places. C:\Tools\axis2c\include
is the same place where you told the compiler to search for the axis2c header files: you have:
-IC:\Tools\axis2c\include
So if that's where the axis2c header files are, then the libraries, I guess, are in C:\Tools\axis2c\lib. Have a look.
Assuming that's right, then in the C::B IDE you need to delete the wrong C:\Tools\axis2c\include from Search directories -> Linker
for your project and replace it with the correct C:\Tools\axis2c\lib Leave C:\Tools\axis2c\include in Search directories -> Compiler,
because that is correct.
Continued for OP's further issues
I believe that your axis2c libraries and header files originated from Apache's Axis2/C download page
from the archive axis2c-bin-1.6.0-win32.zip.
This release suffers from a bug in its header files that causes the linkage errors
you are seeing with the MinGW32 toolchain.
This bug does not affect Google's release of Axis2/C that I referred you to
in my first answer to this question. At that time you said that you were building with 64-bit MinGW, but it has since
become clear that you are building with 32-bit MinGW. In that case, you should download Google's 32-bit build Axis2/C
Unzip the archive with 7-Zip and rename the unzipped folder from axis2c to axis2c-x86-google, to make clear what it is, then copy it somewhere convenient
for your development. Let's say you put it at C:\Tools\axis2c-x86-google.
Then in the C::B IDE, in Search directories -> Compiler, change:
C:\Tools\axis2c\include
to:
C:\Tools\axis2c-x86-google\include\axis2-1.6.0
and in Search directories -> Linker, change:
C:\Tools\axis2c\lib
to:
C:\Tools\axis2c-x86-google\lib
The library that is called axiom.dll in the Apache release is called axis2_axiom.dll in Google's release. Therefore
in your Linker settings -> Other linker options, change:
-laxiom
to:
-laxis2_axiom
Your program then links successfully (for me).
Continued again
Per your comments, the program now fails to load at runtime with the error:
The procedure entry point axis2_callback_create could not be located in the dynamic link library
This means the correct DLL providing axis2_callback_create is not found at runtime.
You say:
I also added the "lib" to path environment. and also added the lib dll files to "C:\Windows\SysWOW64"
Do one or the other, not both.
Depending on what you did to add the Axis2/C library directory to the PATH, it may have had no effect.
If you did this in a shell (command prompt) window that was not the very same one in which your tried to run your
program, then it will have had no effect, since environment settings that you make in a shell apply only to
processes launched in the same shell.
If you did this by modifying the PATH environment variable in Advanced System Settings then that will have
no effect on a shell already open in which you tried to run your program. You would need save the Advanced System Settings
and then try again to run your program in a new shell.
I am able to start your program without DLL errors in all of the following ways:
With all of the files C:\Tools\axis2c-x86-google\lib\*.dll located in the same directory with Math.exe
With all of the files C:\Tools\axis2c-x86-google\lib\*.dll located instead in C:Windows\SysWOW64
In a shell window in which I have previously run: set PATH=%PATH%;C:\path\to\my\axis2c-x86-google\lib
In a new shell after I have added C:\path\to\my\axis2c-x86-google\lib to the PATH environment
variable in Advanced System Settings.
If none of them works for you then I'm afraid the problem is beyond me :(
I don't follow the reasoning behind the steps you have taken and don't
have any concrete data about what you did, so this is an answer "from first principles".
If you want to link a DLL foo.dll with your program using Microsoft's linker (which you are not doing) you cannot
pass foo.dll directly to the linker. As you know, you must instead pass an import library, foo.lib, which is
a small static library of "stubs" representing the functions that are exported by foo.dll. At runtime,
the program loader scans these stubs and (if possible) replaces them with matching references to
to exported functions that it finds by searching available DLLs according to the Windows DLL Search Path
If you want to link foo.dll with your program using the MinGW GNU linker (which you are doing), no
import library foo.lib is necessary. This linker can link foo.dll directly. There is no reason for you to
do otherwise.
To link foo.dll directly with your program using the MinGW GNU linker, the linker, of course,
must be able to find foo.dll at linktime by the the rules that it follows to find libraries, whether static or
dynamic. And just as with Microsoft's linker, successful linkage of a DLL does not guarantee that the DLL
will also be found at runtime by the program loader. The program loader searches for DLLs according to
the the Windows DLL Search Path: it doesn't know or care which linker you used to link your program. You
have to make sure that the linker finds the DLL at linktime, and then you need to make sure that the program
loader will find it at runtime.
How do you tell the MinGW linker to link foo.dll directly? You just follow the rules for passing libraries to
the linker, as documented here.
But before you can attempt that there is one other basic condition that has to be satisfied. You
can't link a 32-bit DLL with a 64-bit program, or vice versa. You say you are building with 64-bit MinGW;
so by default it will build 64-bit executables, and if your are building a 64-bit .exe then you must link it with 64-bit builds of the axis2c DLLs.
I don't know where you got your axis2c libraries, but if you downloaded Apache's v1.6.0 binary archive
then you have got 32-bit DLLs.
You could tell your 64-bit MinGW to build a 32-bit .exe, but you'd probably prefer to link it with 64-bit axis2c DLLs. Fortunately,
a 64-bit build is provided by Google. Download it from here. The 64-bit archive is
x86_64-wsdk7.1-r7acae470da50.7z.
Download it somewhere convenient; extract it with 7-Zip, and then I suggest you rename the extracted folder to something that will identify it
clearly, like axis2c-x86_64-google.
Now, I'll compile and link at the command prompt an example axis2c program, following the linker's rules for finding libraries.
The program I'll build is one of the sample programs provided in the Apache package: axis2c-bin-1.6.0-win32\samples\src\client\echo.
I picked it at random: it contains only one source file, which is echo.c. My toolchain is 64-bit GCC 4.9.2. I have my 64-bit axis2c package downloaded, unzipped and renamed as
C:\develop\stackoverflow\axis2c-x86_64-google
I open a command prompt in the echo directory and enter:
gcc -IC:\develop\stackoverflow\axis2c-x86_64-google\include\axis2-1.6.0 -c echo.c -o echo.o
I'm telling gcc to compile echo.c to echo.o, and that it should search for non-standard header files
in C:\develop\stackoverflow\axis2c-x86_64-google\include\axis2-1.6.0. (To understand basically how to compile and
link programs with GCC, I suggest you read this tutorial).
I get a compiler warning:
warning Please include winsock2.h before windows.h
but it's not an error so I'm not going to worry about it for the purposes of this demonstration.
Next, I want to link the echo.o I've just built with the axis2c DLLs that it requires to
make a program called axis2c-echo.exe. So I enter:
gcc -o axis2c-echo.exe echo.o -LC:\develop\stackoverflow\axis2c-x86_64-google\lib -laxiom -laxutil -laxis2_engine -laxis2_parser
I'm telling gcc that besides the object file echo.o, the program needs to link the libraries (-l) axiom, axutil, axis2_engine and axis2_parser,
and that the linker should look for non-standard libraries in C:\develop\stackoverflow\axis2c-x86_64-google\lib.
Notice that I don't need to tell the linker that, say, the axiom library is axiom.dll and not axiom.lib or libaxiom.a. -laxiom tells the
linker to look for any of these in a given search directory and if it happens to finds a dynamic library (axiom.dll) it will prefer it to any static
library axiom.lib or libaxiom.a. In C:\develop\stackoverflow\axis2c-x86_64-google\lib it will in fact find both axiom.dll and axiom.lib,
and prefer the former; but you don't need to care.
The linkage command succeeds, so now I have a program, axis2c-echo.exe in the same directory. I'll run it:
axis2c-echo
But I can't. I just get a Windows error dialog that says:
This program can't start because axiom.dll is missing from your computer. Try reinstalling the program to fix this error.
The problem is that axiom.dll was linked from C:\develop\stackoverflow\axis2c-x86_64-google\lib, which is not one of the
places where the program loader searches for DLLs at runtime.
Now if I planned to be regularly running axis2c programs on my computer, I would solve this by installing the 64-bit axis2c DLLs
in C:\Windows\SysWOW64, because 64-bit Windows always searches for DLLs there. But I don't plan to do that, so instead I'll just
temporarily add C:\develop\stackoverflow\axis2c-x86_64-google\lib to the Windows DLL Search Path. The last stop on the Windows DLL Search Path
is: The directories listed in the PATH environment variable. So at my command prompt I'll enter:
set PATH=%PATH%;C:\develop\stackoverflow\axis2c-x86_64-google\lib
and then run axis2c-echo again. This time, the output is:
AXIS2C_HOME is not set - log is written to . dir
Using endpoint : http://localhost:9090/axis2/services/echo
Error creating service client, Please check AXIS2C_HOME again
Now the program itself is complaining, but that's good enough for me! It has compiled, linked, loaded,
produced some output and finished gracefully.
It's probably obvious now how you would set up a Code::Blocks project to build this same program:
Create a C-language console project in the echo directory.
Delete the default main.c source file from the project
Add the single source file echo.c to the project.
In the project's Build options -> Search directories -> Compiler, add C:\develop\stackoverflow\axis2c-x86_64-google\include\axis2-1.6.0
(or path\to\your\axis2c-1.6.0\header-files)
In the project's Build options -> Search directories -> Linker, add C:\develop\stackoverflow\axis2c-x86_64-google\lib
(or path\to\your\axis2c-1.6.0\libraries)
In the project's Build options -> Linker settings -> Other linker options, add -laxiom -laxutil -laxis2_engine -laxis2_parser
This isn't the only way you could successfully configure this project in C::B, but it corresponds to the way someone would normally build the
project at the command prompt, and means that the toolchain commands that C::B executes will be concise and normal-looking.
If you follow these steps to build the example echo project you shouldn't have much difficulty successfully configuring your own project.

DSO missing from command line although it is available

I am working with c++ code for a physics simulation, which uses a lot of external libraries (like GSL and cern`s ROOT). Trying to recompile project I encountered problems with linking. When running compilation of final file via:
g++ -fno-inline -O2 -fpic -o main.out ${ROOTINCS} main.o ext.o ${ROOTLIBS} $(objects2)
with :
objects2= many .o files made by us
ROOTLIBS=-L/usr/local/lib/root -lTree -lRIO -lNet -lHist -lMathCore -lCore -lGraf -lGraf3d -lGpad -lMatrix -lThread -lCint -lPhysics -lPostscript -lRint -lSpectrum -lg
ROOTINCS=-pthread -m64
I get annoying error:
/usr/bin/ld: /usr/local/lib/root/libHist.so: undefined reference to symbol 'gRandom'
/usr/local/lib/root/libMathCore.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
The problem is nm -C run on libMathCore states 'gRandom' is declared there. Also -lMathCore is present in my command line.
When I run ld to check if it understands the flag:
ld -L/usr/local/lib/root -lMathCore --verbose 2>/dev/null
it does not complain and tries to link properly.
According to https://stackoverflow.com/a/24675715/3602168 order of libraries is correct in my linking (libHist uses libMathCOre and therefore is stated first).
Compilation runs under g++ 4.8.2 on ubuntu 14.04, 64 bit
Converting comment to answer:
Have you tried moving $(objects2) before ${ROOTLIBS}? I think the issue may be that you have libraries specified before the object files that use them.

Error compiling Rglpk on Windows

I need to use the R package Rglpk in a project and need to modify the package - in particular, I need to add a time limit control parameter option to the interface (it is a option in GLPK v4.5.2 itself, but Rglpk 0.5-2 does not support this parameter). This will allow R to call GLPK and limit the search time to be user specified (i.e., search time <= t).
I have modified Rglpk code and have successfully compiled the package on Mac OS X v10.9.2 and verified that it worked as expected. My project needs to run on Windows and I have not been able to compile the modified Rglpk package, or for that matter the unmodified package (Rglpk 0.5-2), on Windows. I have tried uploading the original package to Win Builder (http://win-builder.r-project.org/), but I have received the same errors.
The following is a summary of what I have done on Windows 7 (my machine):
(1) Download the Rglpk 0.5-2 package source from http://cran.r-project.org/web/packages/Rglpk/index.html
(2) Unzip the file to a directory. All the code is in a directory called Rglpk.
(3) Start RStudio v0.98.490. I have devtools v1.4.1 installed, Rtools v3.1 installed, and R v3.0.2
(4) Open a new project and select the Rglpk directory mentioned in (2).
(5) Under the 'Build' menu, select 'Build and Reload'. The result of this is that the package compiles and is loaded:
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (Rglpk)
(6) Under the 'Build' menu, select 'Check Package'. The result is that the installation fails. The log file is shown below.
I have tried to compile another package that has C code and have not been able to compile it either. The package I tried to compile is devtools v1.5 The error that came back in that case is 'LoadLibrary failure: %1 is not a valid Win32 application.'
Does anyone have any experience compiling R packages on Windows that include C code? I have been able to compile packages that involve only R code, but it seems C code is troublesome.
Any help would be appreciated.
Log File
* using R version 3.0.2 (2013-09-25)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* checking for file 'Rglpk/DESCRIPTION' ... OK
* this is package 'Rglpk' version '0.5-2'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... NOTE
Found the following apparent object files/libraries:
src/GLPK/alloc.o src/GLPK/amd/amd_1.o src/GLPK/amd/amd_2.o
src/GLPK/amd/amd_aat.o src/GLPK/amd/amd_control.o
src/GLPK/amd/amd_defaults.o src/GLPK/amd/amd_dump.o
src/GLPK/amd/amd_info.o src/GLPK/amd/amd_order.o
src/GLPK/amd/amd_post_tree.o src/GLPK/amd/amd_postorder.o
src/GLPK/amd/amd_preprocess.o src/GLPK/amd/amd_valid.o
src/GLPK/bignum.o src/GLPK/cfg.o src/GLPK/cfg1.o
src/GLPK/colamd/colamd.o src/GLPK/dmp.o src/GLPK/env.o
src/GLPK/error.o src/GLPK/ffalg.o src/GLPK/fhv.o src/GLPK/fhvint.o
src/GLPK/glpapi01.o src/GLPK/glpapi02.o src/GLPK/glpapi03.o
src/GLPK/glpapi04.o src/GLPK/glpapi05.o src/GLPK/glpapi06.o
src/GLPK/glpapi07.o src/GLPK/glpapi08.o src/GLPK/glpapi09.o
src/GLPK/glpapi10.o src/GLPK/glpapi11.o src/GLPK/glpapi12.o
..... (more lines are here, I have removed them for brevity)
src/GLPK/triang.o src/GLPK/wclique.o src/GLPK/wclique1.o
src/GLPK/zlib/adler32.o src/GLPK/zlib/compress.o
src/GLPK/zlib/crc32.o src/GLPK/zlib/deflate.o src/GLPK/zlib/gzclose.o
src/GLPK/zlib/gzlib.o src/GLPK/zlib/gzread.o src/GLPK/zlib/gzwrite.o
src/GLPK/zlib/inffast.o src/GLPK/zlib/inflate.o
src/GLPK/zlib/inftrees.o src/GLPK/zlib/trees.o
src/GLPK/zlib/uncompr.o src/GLPK/zlib/zio.o src/GLPK/zlib/zutil.o
Object files/libraries should not be included in a source package.
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking whether package 'Rglpk' can be installed ... ERROR
Installation failed.
The contents of the 00install.out file are:
* installing *source* package 'Rglpk' ...
** libs
*** arch - i386
gcc -m32 -I"C:/PROGRA~1/R/R-30~1.2/include" -DNDEBUG -IGLPK -IGLPK/amd -IGLPK/colamd -IGLPK/minisat -IGLPK/proxy -IGLPK/zlib -I"d:/RCompile/CRANpkg/extralibs64/local/include" -O3 -Wall -std=gnu99 -mtune=core2 -c Rglpk_initialize.c -o Rglpk_initialize.o
gcc -m32 -I"C:/PROGRA~1/R/R-30~1.2/include" -DNDEBUG -IGLPK -IGLPK/amd -IGLPK/colamd -IGLPK/minisat -IGLPK/proxy -IGLPK/zlib -I"d:/RCompile/CRANpkg/extralibs64/local/include" -O3 -Wall -std=gnu99 -mtune=core2 -c Rglpk_read_file.c -o Rglpk_read_file.o
Rglpk_read_file.c: In function 'Rglpk_read_file':
Rglpk_read_file.c:84:6: warning: 'status' may be used uninitialized in this function [-Wuninitialized]
Rglpk_read_file.c: In function 'Rglpk_retrieve_MP_from_file':
Rglpk_read_file.c:192:6: warning: 'status' may be used uninitialized in this function [-Wuninitialized]
gcc -m32 -I"C:/PROGRA~1/R/R-30~1.2/include" -DNDEBUG -IGLPK -IGLPK/amd -IGLPK/colamd -IGLPK/minisat -IGLPK/proxy -IGLPK/zlib -I"d:/RCompile/CRANpkg/extralibs64/local/include" -O3 -Wall -std=gnu99 -mtune=core2 -c Rglpk_solve.c -o Rglpk_solve.o
Rglpk_solve.c: In function 'R_glp_solve':
Rglpk_solve.c:25:10: warning: variable 'kl' set but not used [-Wunused-but-set-variable]
gcc -m32 -shared -s -static-libgcc -o Rglpk.dll tmp.def Rglpk_initialize.o Rglpk_read_file.o Rglpk_solve.o GLPK/libglpk.a -Ld:/RCompile/CRANpkg/extralibs64/local/lib/i386 -Ld:/RCompile/CRANpkg/extralibs64/local/lib -LC:/PROGRA~1/R/R-30~1.2/bin/i386 -lR
c:/rtools/gcc-4.6.3/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/bin/ld.exe: i386:x86-64 architecture of input file `GLPK/libglpk.a(glpmpl04.o)' is incompatible with i386 output
c:/rtools/gcc-4.6.3/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/bin/ld.exe: i386:x86-64 architecture of input file `GLPK/libglpk.a(error.o)' is incompatible with i386 output
c:/rtools/gcc-4.6.3/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/bin/ld.exe: i386:x86-64 architecture of input file `GLPK/libglpk.a(glpmpl03.o)' is incompatible with i386 output
c:/rtools/gcc-4.6.3/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/bin/ld.exe: i386:x86-64 architecture of input file `GLPK/libglpk.a(alloc.o)' is incompatible with i386 output
c:/rtools/gcc-4.6.3/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/bin/ld.exe: i386:x86-64 architecture of input file `GLPK/libglpk.a(glpenv07.o)' is incompatible with i386 output
c:/rtools/gcc-4.6.3/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/bin/ld.exe:
.....
Error: 64-bit reloc in dll
Error: 64-bit reloc in dll
Error: 64-bit reloc in dll
.....
Rglpk_initialize.o:Rglpk_initialize.c:(.text+0x33): undefined reference to `glp_term_hook'
Rglpk_initialize.o:Rglpk_initialize.c:(.text+0x44): undefined reference to `glp_version'
Rglpk_read_file.o:Rglpk_read_file.c:(.text+0x10): undefined reference to `glp_delete_prob'
Rglpk_read_file.o:Rglpk_read_file.c:(.text+0x4f): undefined reference to `glp_term_out'
Rglpk_read_file.o:Rglpk_read_file.c:(.text+0x60): undefined reference to `glp_delete_prob'
Rglpk_read_file.o:Rglpk_read_file.c:(.text+0x65): undefined reference to `glp_create_prob'
.....
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0x4326): undefined reference to `strcpy'
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0x4d39): undefined reference to `strcpy'
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0x4dc5): undefined reference to `strcpy'
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0x4e05): undefined reference to `floor'
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0x4e16): undefined reference to `floor'
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0x502e): undefined reference to `floor'
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0x50e2): undefined reference to `sprintf'
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0x5111): undefined reference to `sprintf'
.....
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0x990): undefined reference to `exp'
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0x9e0): undefined reference to `log'
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0xa30): undefined reference to `log10'
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0xaee): undefined reference to `sin'
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0xb4e): undefined reference to `cos'
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0xb65): undefined reference to `atan'
GLPK/libglpk.a(glpmpl03.o):glpmpl03.c:(.text+0xb79): undefined reference to `atan2'
.....
GLPK/libglpk.a(deflate.o):deflate.c:(.text+0x2ec0): undefined reference to `memcpy'
GLPK/libglpk.a(deflate.o):deflate.c:(.text+0x2ed5): undefined reference to `memcpy'
GLPK/libglpk.a(deflate.o):deflate.c:(.text+0x2ee7): undefined reference to `memcpy'
GLPK/libglpk.a(zutil.o):zutil.c:(.text+0x47): undefined reference to `malloc'
GLPK/libglpk.a(zutil.o):zutil.c:(.text+0x54): undefined reference to `free'
collect2: ld returned 1 exit status
ERROR: compilation failed for package 'Rglpk'
It looks like a couple things are going wrong:
Object files are getting pre-compiled, but not cleaned out.
Because these object files are being pre-compiled, and it looks like they were compiled for 64-bit architecture, when you try to use these in a 32-bit build, the installation process barfs.
The fix here is going to be deleting all of those *.o files (they need to be compiled as part of the R CMD build step, I imagine), and the resulting tarball can then be R CMD checked.
You should consider installing a more up-to-date version of RStudio and devtools, and ensure you use devtools to handle the build process -- it might be able to help you out here.

MinGW undefined reference to malloc, free, sprintf, _beginthreadex

I'm using MinGW. I have some code which calls malloc and a few other general purpose functions. When I type:
gcc TestCode.c
I get an a.exe file, it works perfect, and I don't get any warnings.
If I type this:
gcc -c TestCode.c -o TestCode.o
ld *.o
I get a whole bunch of warnings such as:
TestCode.o:TestCode.c:(.text+0xa): undefined reference to `__main'
TestCode.o:TestCode:(.text+0x2e): undefined reference to `printf'
TestCode.o:TestCode:(.text+0x42): undefined reference to `_strerror'
TestCode.o:TestCode:(.text+0x69): undefined reference to `snprintf'
TestCode.o:TestCode:(.text+0x7e): undefined reference to `malloc'
TestCode.o:TestCode:(.text+0x93): undefined reference to `_strerror'
TestCode.o:TestCode:(.text+0xb1): undefined reference to `sprintf'
TestCode.o:TestCode:(.text+0xcf): undefined reference to `free'
I'm assuming this is an issue with how I'm calling the linker. As such, I'll only post the code if it isn't clear what the problem is. I'm hoping this is an easy fix and that I simply forgot to include some super obvious library when linking.
It appears that your ld doesn't link any libraries by default. From your error messages, it looks like you need at least the C runtime and libc. Use gcc to link to get some handy defaults linked in for you:
gcc -c TestCode.c -o TestCode.o
gcc *.o
If you really want to use ld directly, you're going to need to figure out the names of your C runtime library and libc. For example (assuming libraries named libcrt and libc):
ld *.o -lcrt -lc
As Carl Norum said, you can pass object files to gcc and it'll know it doesn't need to compile them - it just passes them on to the linker (whether or not you're compiling other source files in the same invocation).
And you should probably do that because there's a fair amount of detail that goes into linking in the CRT and windows support libraries (unless you have a very specific need to not use the default runtime). My current MinGW setup links in the following items along with my object files:
crt2.o
crtbegin.o
-ladvapi32
-lshell32
-luser32
-lkernel32
-lmingw32
-lgcc
-lmoldname
-lmingwex
-lmsvcrt
crtend.o
Use the --verbose option to see how gcc links for you.

Resources