09-23-2013 02:18 PM
Hi all,
I have been able to compile the examples provided in teh NiDaqmx Base driver, it used gcc -m32 to do so. This indicate that the library is 32 bit.
As I am writting my own C code and I have to call couple functions to use the NI-USB 6009, I cannot do that due to the linker problem. For example, I have nat_inst.c is the code to control the 6009. I also have another code astro1.c to be used in main.c to be called in an execuatble file named 'run_test'. I made a header file header.h to include "NIDAQmxBase.h". And I have some libraries to link caleld CFLAGS and CFLAGS1. Hence the Makefile should look like
CC = gcc
CFLAGS = -lsig_px14400 -I. -I/usr/local/pgplot -lmCFLAGS1 = -I/usr/local/natinst/nidaqmxbase/include
nilibs = -lnidaqmxbase
run_test : main.o astro1.o nat_inst.o
$(CC) $(CFLAGS) -o $@ $^
main.o astro1.o : main.c astro1.c hearder.h
$(CC) $(CFLAGS) -c $^nat_inst.o : nat_inst.c header.h
$(CC) $(CFLAGS1) -m32 $^ $(nilibs)
The reason I am compiling the object files separately with '-c' and '-m32' is because I can't compile the NI library with the normal -c for 64 bit . By doing so, the compiler for main.c and astro1.c does not recognize the "NIDAQmxBase.h" in my header file. I got it compiled if I leave the header.h off the compiler for main.c and astro1.c, but then when I try to the functions in nat_inst.c under astro1.c, the compiler telling me it doesn't recognize those subfunctions in nat_inst.c since I did not link the library
After some googling, it seems to be a bad idead to mix a 32 bit library in 64 bit code.
Please let me know if you have any suggestion. Thanks in advanced.
09-24-2013 02:18 AM
It's not only a bad idea but simply impossible. For all practicual purposes you have to consider 32 bit and 64 bit object code totally incompatible with each other, just the same as if you had object code compiled for x86 CPU and a PPC. They are very different architectures and can not be mixed together in the same executable image (safe from unpractical assembly code acrobatics).
The most pragmatic approach in those cases is to seperate the two different architectures into seperate executables and communicate through some form of InterApplication Communication (IAC) between them. This can be a syscall interface in the case of OS ABI services but a more general approach is to use either pipes or (TCP/IP) sockets to communicate between the two processes.