I have a file app.c which uses two libraries GStreamer and libXml2. To compile the application I type the following on Terminal
gcc -Wall $(pkg-config --cflags --libs gstreamer-0.10) app.c -o app -I/usr/include/libxml2 -lxml2
When I try to Makefile with the contents as follows :
all:
gcc -Wall $(pkg-config --cflags --libs gstreamer-0.10) app.c -o app -I/usr/include/libxml2 -lxml2
run:
./app
clean:
rm app
On running make command I get the errors as expected. What is the significance of
$(pkg-config --cflags --libs gstreamer-0.10)
on Echoing the above I get some files which when included in Makefile gives me the correct output.
pkg-config --cflags libraryX outputs the path to the header files of libraryX. Without this, the compiler does not know where to look for the header files, and compilation will fail.
Similarly, pkg-config --libs libraryX outputs the path to the actual compiled library files of libraryX. Without this, the linker does not know where to look for the library files, and linking will fail.
pkg-config --cflags --libs libraryX is just combining what I described above. Since you're using gcc to do both compilation and linking, you just pass those parameters together to gcc.
Related
I am trying to cross compile my application for a arm based system.
I have 2 libraries compiled in the following way:
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libfoo.so foo.o
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libbar.so bar.o
A third library is compiled:
gcc -shared -o $LIBPATH/libfoobar.so --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH foobar.o -lfoo -lbar
Then finally I compile a binary:
gcc -o app --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH app.o -lfoobar
However when compiling app I get
warning: libfoo.so, needed by libfoobar.so, not found (try using -rpath or -rpath-link)
I believe you need to use -Wl,-rpath-link=$LIBPATH to tell the linker where to look to resolve runtime library references during the link operation.
More info can be found in the ld documentation: https://sourceware.org/binutils/docs-2.37/ld/Options.html
I am new to C++ compiling/linking.
I am trying to link all libraries statically with gcc, I tried using LDFLAGS=-static but did not work. Error message showed:
/bin/sh ./libtool --tag=CXX --mode=link /home/dizhang/lib/hdf5/bin/h5c++ -g -O2 -L/home/dizhang/lib/blitz/lib -L/home/dizhang/lib/libconfig/lib -o angora src/libangora.la -lblitz -lconfig++
libtool: link: /home/dizhang/lib/hdf5/bin/h5c++ -g -O2 -o angora -L/home/dizhang/lib/blitz/lib -L/home/dizhang/lib/libconfig/lib src/.libs/libangora.a -L/bgsys/drivers/V1R2M2/ppc64/comm/lib64 -L/bgsys/drivers/V1R2M2/ppc64/comm/lib -L/bgsys/drivers/V1R2M2/ppc64/spi/lib -lpthread -lm /home/dizhang/lib/blitz/lib/libblitz.a /bgsys/drivers/V1R2M2/ppc64/comm/lib/libmpichcxx-gcc.so /bgsys/drivers/toolchain/V1R2M2_base/gnu-linux/powerpc64-bgq-linux/lib/libstdc++.so /bgsys/drivers/V1R2M2/ppc64/comm/lib/libmpich-gcc.so /bgsys/drivers/V1R2M2/ppc64/comm/lib/libopa-gcc.so /bgsys/drivers/V1R2M2/ppc64/comm/lib/libmpl-gcc.so /home/dizhang/lib/libconfig/lib/libconfig++.a /bgsys/drivers/toolchain/V1R2M2_base-efix014/gnu-linux/powerpc64-bgq-linux/lib/libstdc++.so -Wl,-rpath -Wl,/bgsys/drivers/toolchain/V1R2M2_base-efix014/gnu-linux/powerpc64-bgq-linux/lib -Wl,-rpath -Wl,/bgsys/drivers/V1R2M2/ppc64/comm/lib -Wl,-rpath -Wl,/bgsys/drivers/toolchain/V1R2M2_base/gnu-linux/powerpc64-bgq-linux/lib -Wl,-rpath -Wl,/bgsys/drivers/toolchain/V1R2M2_base-efix014/gnu-linux/powerpc64-bgq-linux/lib -Wl,-rpath -Wl,/bgsys/drivers/V1R2M2/ppc64/comm/lib -Wl,-rpath -Wl,/bgsys/drivers/toolchain/V1R2M2_base/gnu-linux/powerpc64-bgq-linux/lib
/bgsys/drivers/toolchain/V1R2M2_base-efix014/gnu-linux/lib/gcc/powerpc64-bgq-linux/4.4.7/../../../../powerpc64-bgq-linux/bin/ld: attempted static link of dynamic object `/bgsys/drivers/V1R2M2/ppc64/comm/lib/libmpichcxx-gcc.so'
collect2: ld returned 1 exit status
I did some search and found that, telling Makefile -Wl -Bstatic may solve this problem, but how exactly I should change this in my Makefile?
I tried searching -Wl in Makefile but it was not in the text.
Thanks,
Di
Looks like you are trying to build HDF5 with MPI support on BGQ.
As long as you end up passing a ".so" version of a lib to gcc on BGQ -- you will see this error. You may need to check how you are passing MPI info to HDF5's configure script.
In my case (building another project that uses CMake) passing BGQ's MPI compiler wrappers to CMake always created a problem where it would try to link MPI using the shared libs instead of the static ones. To resolve this, I had to make sure to explicitly specify the ".a" variants of the MPI libs.
I have installed the latest libxml2-2.8.0, as usual: $ ./configure, $ make, $ make install.
The $ xml2-config --cflags --libs gives this output:
-I/usr/local/include/libxml2
-L/usr/local/lib -lxml2 -lm
But trying to compile any example...
$ gcc `xml2-config --cflags --libs` xmltest.c
The linker says:
/tmp/cc8ezrPl.o: In function `processNode':
xmltest.c:(.text+0x19): undefined reference to `xmlTextReaderConstName'
xmltest.c:(.text+0x38): undefined reference to `xmlTextReaderConstValue'
...etc.
Anything I've googled can be solved by xml2-config --cflags --libs flags, or upgrading to the latest version of libxml2, or something. Unfortunately, neither works for me.
What can be the steps to identify the problem?
Using Ubuntu 12.04 64-bit.
The libraries should be specified only after the source file so that the linker can resolve the undefined references in the source file. Try compiling the example with this
gcc -I/usr/local/include/libxml2 -L/usr/local/lib xmltest.c -lxml2 -lm
So I was merrily learning GTK+ programming with 3.0 in Ubuntu 11.04, and even got a working ruler program running. It compiled with my makefile perfectly.
I took some time away from it, upgraded to 11.10, and now have come back to it. But, alas, when I try to build the program, I get a lot of "undefined reference" errors to pretty much every gtk call in my program. Compiling is fine - the issue is at link time.
The project can be found here: https://github.com/zjmichen/ruler
I've tested it and it compiled fine.
superman#superman-mint ~/work/zjmichen-ruler-e783fe1 $ make
gcc -c -Wall `pkg-config --cflags --libs gtk+-3.0` main.c
gcc -c -Wall `pkg-config --cflags --libs gtk+-3.0` window.c
gcc -c -Wall `pkg-config --cflags --libs gtk+-3.0` graphics.c
gcc -c -Wall `pkg-config --cflags --libs gtk+-3.0` mouse.c
gcc `pkg-config --cflags --libs gtk+-3.0` main.o window.o graphics.o mouse.o -o zruler
superman#superman-mint ~/work/zjmichen-ruler-e783fe1 $
But this was on Linux Mint. Here you've got the arguments produced by pkg-config
-pthread -DGSEAL_ENABLE -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtk-3.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pixman-1 -pthread -L/usr/lib/x86_64-linux-gnu -lgtk-3 -lgdk-3 -latk-1.0 -lcairo-gobject -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lm -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0
I've also did a quick test on Ubuntu 11.10 and indeed it doesn't compile. I'll take a better look this evening.
So I did test it on Ubuntu and changed the line 14 in the makefile to
$(CC) $(OBJS) $(GTKFLAGS) -o $(NAME)
this changes the order of object files and libraries that are being linked. I have no idea why this problem occurs on the new Ubuntu. Maybe it is because it is a different version of gcc. On my linux mint gcc is version 4.5.2 on ubuntu 11.10 it is 4.6.1
Unfortunately I currently don't have access to a running Linux machine with GTK3.0 installed, but looking at your code I noticed the inclusion of X11/xlib.h in main.c. Since you are not using X11 code anywhere in your code and you are using 'pkgconfig ... gtk+-3.0' instead of gtk+-X11-3.0, I assume you could remove that include statement. If you do need the X11 libraries the make sure it is listed in the compiler flags. I hope this helps :)
I'm seeing:
ld: in objs/AttributeValueTest.o, can't link with a main executable for architecture x86_64
When building a very simple program which has only 1 .h and 1 .cpp file.
The compile lines are:
g++ -g -I./ -I/usr/local/include -o objs/AttributeValueTest.o tp_datastruct/tests/AttributeValueTest.cpp -L/usr/local/lib -lavrocpp -lcppunit -lm
g++ -g -I./ -I/usr/local/include -o AttributeValueTest objs/AttributeValueTest.o -L/usr/local/lib -lavrocpp -lcppunit -lm
I tried to specify -arch x86_64, -arch i386 and -m32, but nothing worked (I got other errors, it was complaining that libcppunit was not in the right format).
Any idea/pointer/suggestion?
Thanks!
Very strange. I did some digging around, and saw somewhere that AttributeValueTest.o might be an executable already. I did a "file" on that AttributeValueTest.o, and sure enough, it is a ready-to-go executable. I modified my makefile to rename that .o into AttributeValueTest, and I can happily run it. Also, the executable comes with a ".dSYM" directory, which I can remove without any problem... I don't understand what is going on, but I can run my executable now...
You forgot to specify -c option to the g++ to compile a source code into object file. So it is getting compiled and linked into executable file. Then you are trying to link executable into executable, which fails. From the gcc's manual page:
-c Compile or assemble the source files, but do not link. The
linking stage simply is not done. The
ultimate output is in the form of an
object file for each source file.
By default, the object file name for a source file is made by
r> eplacing the suffix .c, .i, .s, etc.,
with .o. Unrecognized input files, not
requiring compilation or assembly, are
ignored.