in my homework i must use this command to compile my program:
gcc -o mtm_rentals -std=c99 -Wall -pedantic-errors -Werror -DNDEBUG mtm_ex2.c rentals.c list.c -L -lmtm
what i can change in that line are the files im writing after -DNDEBUG. when i do this the gcc says that there are undefined references to specific functions. now those functions are declared in an .h file and are implemented in a given file called libmtm.a
i concluded that it doesnt recognize libmtm.a, but our homework task says that the -lmtm flag(which is not declared anywhere) is supposed to link libmtm.a to the program.
what am i missing here? am i supposed to implement somehow the -lmtm flag?
thank you!
You are missing a . (single dot) behind the -L.
-lmtm will link against a libmtm library, this is correct. It's not an -lmtm flag, it's a -l flag concatenated with mtm, the library you want to link against. This library is searched in some predefined paths (like /usr/lib/) and additionally in the paths given by -L. Assuming libmtm lives in your current directory, you need to add that to -L, which is done with a ..
Related
Using the Makefile provided by the Pi GPIO library, I made the libpigpio.so shard object using:
# from line 119 in make file
make libpigpio.so
The shared object is created fine. The Makefile first created the pigpio.o object, then the command.o object, and links them together as a shared object. So far so good!
I wrote a very small main function that calls the gpioInitialise and gpioGetPWMfrequency.
It doesn't really matter which functions, what's important is they are defined in pigpio.h and written in pigpio.c.
Meaning the shared object should have them.
The compile command for my code is:
gcc -Wall -pthread -fpic -L. -lpigpio -o drive drive.c
Still I get the undefined reference error to both those functions.
It makes no sense! If it didn't find the shared object, it would reject the command. I also tried it -l:libpigpio.so and still the same problem.
I am compiling directly on the Rpi A+ (not using a cross compiler). So it should work!
What am I missing here?
It is a link order question. Please try the flowing command.
gcc drive.c -Wall -pthread -fpic -o drive -L. -lpigpio
you can read Why does the order in which libraries are linked sometimes cause errors in GCC? for more details.
I have a problem on linking static libraries..
I have checked and proceeded some methods to solve it, like.. reordering libraries or using some options..
However, All what I've done didn't work..
--
First of all, I'm quite sure it is from link error because I have checked the .a file by nm command and there was specific functions shown in error log.
So, I linked static library like below..
LOCAL_LINK_STATIC_LIBS := \
-I$(libdir)/libmicrohttpd.a\
-I$(libdir)/libcryptopp.a\
...
myprog_LDFLAGS = -lstdc++ -g -ldl -lpthread #GLIB_CFLAGS# $(LOCAL_LINK_STATIC_LIBS)
Is there other way to solve it? I really need your feedback..
Thanks for reading.
You must only supply the name with the -l option, e.g. -lmicrohttpd. The linker will add "lib" and ".a" or ".so". Use the -L option to set the search path for the libraries, e.g. -L$(libdir).
Also try using -pthread instead of -lpthread. -lpthread only links the pthread library whereas -pthread will do some additional work.
I am trying to compile using gfortran using the following:
$ gfortran -I/usr/local/include -O3 -Wall -Wno-uninitialized -fbounds-check -g alignparts_lmbfgs.f90 /home/vincent/test/lmbfgs/Lbfgsb.3.0/lbfgsb.f /home/vincent/test/lmbfgs/Lbfgsb.3.0/linpack.f /home/vincent/test/lmbfgs/Lbfgsb.3.0/blas.f /home/vincent/test/lmbfgs/Lbfgsb.3.0/timer.f /home/vincent/test/lmbfgs/minimal_libraries/imlib2010.a /home/vincent/test/lmbfgs/minimal_libraries/genlib.a -o alignparts_lmbfgs.exe -lfftw3 -lm
but it gave me the error
alignparts_lmbfgs.f90:105: Error: Can't open included file '/usr/include/fftw3.f'
even though I specified the -I opitions where the fftw3.f resides.
What am I doing wrong? I don't have root privileges so I can't just move the files from /usr/local/include to /usr/inlcude
I am a noob in compiling. I am only compiling because this is the only way I am getting the executable. Please be as noob-proof as possible when explaining. Thank you so much!
The compiler reports:
alignparts_lmbfgs.f90:105: Error: Can't open included file '/usr/include/fftw3.f'
This means that your source file alignparts_lmbfgs.f90 contains
a line #105 like:
INCLUDE '/usr/include/fftw3.f'
which tells the compiler to copy the file /usr/include/fftw3.f in place
of that line #105. But there is no such file.
You have passed the compiler option -I/usr/local/include which
tells the compiler to search for included files in /usr/local/include,
and you say:
I specified the -I options where the fftw3.f resides.
So probably there is such a file as /usr/local/include/fftw3.f?
In that case, can change:
INCLUDE '/usr/include/fftw3.f'
to:
INCLUDE '/usr/local/include/fftw3.f'
However, if you do that, then the compiler option:
-I/usr/local/include
is pointless, because /usr/local/include/fftw3.f is an absolute filename:
it either exists or it doesn't.
If you want the program to be compilable independently of the absolute location
of fftw3.f - which is emphatically the best practice - then replace line #105 with:
INCLUDE 'fftw3.f'
Then, if fftw3.f is in fact located in /usr/local/include, you can compile
the program with the option -I/usr/local/include, and in general if the file
is located in directory /look/here/for/headers, you can compile the program
with the option -I/look/here/for/headers.
I'm trying to compile AODV for ARM linux. I use a SabreLite as a board with kernel version 3.0.35_4.1.0. It's worth mention that i'm using openembedded to create my Linux Distribution for my board.
The AODV source code (http://sourceforge.net/projects/aodvuu/) has a README file which give some indications on how to install it on ARM as stated a bit here.
(http://w3.antd.nist.gov/wctg/aodv_kernel/kaodv_arm.html).
I was able to upgrade the makefile in order to be used with post 2.6 kernel version ( as stated above, i have the 3.0.35_4.1.0 kernel version).
So, basically, what i am trying to do is that i have to create a module (let's say file.ko) and then load it into the ARM (with insmod file.ko command).
To do that, i am using a cross compiler which some values are stated below:
echo $CC :
arm-oe-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-vfp-neon-oe-linux-gnueabi
echo $ARCH=arm
echo $CFLAGS: O2 -pipe -g -feliminate-unused-debug-types
echo $LD :
arm-oe-linux-gnueabi-ld --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-vfp-neon-oe-linux-gnueabi
echo $LDFLAGS :
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--as-needed
when i launch "make command", i get the following errors:
LD [M] /home/scof/script_emulation/AODV/aodv-uu/lnx/kaodv.o
arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
arm-oe-linux-gnueabi-ld: use the --help option for usage information
It states that there is something wrong with the linker. This linker comes from the cross compilation tools and i normally shouldn't touch it.
Anyway, to get this above errors fixed, i try to withdraw the LDFLAGS like this:
export LDFLAGS='',
and after this, the make command works and i get the module kaodv.ko. But when i insert it into my ARM to check, it does not work. It actually freeze my terminal
So my question is, do i have to specify the LDFLAGS when compiling ? Does withdrawing LDFLAGS can have impact on the generated kernel module.
Actually, i try to understand where might be the problem and the only thing that come to me is that may be i should not change manually the LDFLAGS. But if i don't change de LDFLAGS, i get the unrecognized option error.
My second question related to that is, what are the possibly value of LDFLAGS
in ARM compilation
Thanks !!
echo $LDFLAGS : -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--as-needed
There are two common methods of invoking the linker in a GCC-based toolchain. One is to do it directly, but another is to use GCC as a front end to invoke the linker, rather than invoke it directly. When doing this, options intended for the linker are prefixed with -Wl, so that GCC knows to pass them through rather than interpret them itself.
In your case the error message from LD itself
arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
Indicates that your build system is passing LDFLAGS directly to the linker, and not by way of GCC.
Therefore, you should remove the -Wl, prefix and your LDFLAGS would instead be
-O1 --hash-style=gnu --as-needed --as-needed
(the duplication of the last argument is probably pointless but benign)
-O1 is an option that tells the linker to optimize. I believe it something new, and your linker may be slightly out of date. Try removing -Wl,-O1, it should still work.
In a later stage of the gnu-make process gmake sent a command similar to:
gcc -static foo.so.0 bar.o bizz.o buzz.o -pthreads -lrt
In that command, what dos the -lrt mean?
That has not related to make; make will never add a flag like that on its own. Whomever wrote your makefile will have added that flag to the link line themselves. That is a compilation command, and -lrt is a flag passed to the compiler. The -l flag specifies that you should link with a library, and the name of the library follows; so for -lrt it means "link with the rt library". This causes the linker to go look for libraries named librt.a or librt.so (for shared libraries) and link them with the output file.