I am using NetBeans under RedHat. I have a couple of open projects that combine together to make a command line executable and a shared object "plugin". There are two static libraries in the mix as well. That is all fine and good.
I just noticed that when I "clean and build" the executable and the shared object that the compiler options are also expressed on the linker line. a la:
g++ -O2 -Wall -c -fmessage-length=0 -c -g -Werror -DDEBUG -DDEBUG_2 -I/usr/include -I/usr/include/c++/4.4.7/x86_64-redhat-linux -I/usr/include/c++/4.4.7 -I../ITGUtilities -MMD -MP -MF "build/Debug/GNU-Linux-x86/LocalCache.o.d" -o build/Debug/GNU-Linux-x86/LocalCache.o LocalCache.cpp
then later in the compile line (edited for brevity):
g++ -O2 -Wall -c -fmessage-length=0 -fPIC -o dist/Debug/GNU-Linux-x86/pam_plugin.so build/Debug/GNU-Linux-x86/pam_plugin.o -L... -lpam -l... -shared -fPIC
g++: build/Debug/GNU-Linux-x86/pam_plugin.o: linker input file unused because linking not done
I think I have a fairly generic set of project configs. I did set the -O2 -Wall -c -fmessage-length=0 compiler options but there are no options supplied for the linker other than whatever defaults NetBeans applies.
For the executable and plugin projects I can go to Properties > Linker > Additional Options and expand the [...] to see what NB thinks it will apply. That does not show the compile options but doing an actual build does apply them.
It is not doing the link step and I am assuming that is because of the compiler options. This is weird.
ideas?
Do not add -c option to the compiler options which says not to run the linker. It will be added as needed when just compiling anyway.
Related
I am trying to link some files. Here is my command:
gcc -T linker.ld -o Stack\ Berry.bin -ffreestanding -O2 -nostlib kernel.o boot.o -fPIC -lgcc
How ever, I get this error:
/usr/bin/ld: boot.o: relocation R_X86_64_32 against `.multiboot' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
I have included the -fPIC argument, have I just put it in the wrong place? I have tried putting the argument in where it compiles but no luck. I haven't been able to find any thing for the syntax for this flag. Thanks!
You are passing -fPIC to your linkage command. It is a compiler option,
because you need to compile your source code to Position Independent object files.
Remove it from this command and add it to your compilation commands.
(-O2 is likewise a compiler, not linker, option.)
I'm building a gst-plugin through yocto 1.6. I've linaro 4.9 cross toolchain of 32 and 64-bit.
When I'm building the plugin using 64-bit toolchain, it was success ( I got the plugin .so file) whereas if I build the same source using 32-bit toolchain I got the below error
/home/build-directory/tmp/sysroots/x86_64-linux/usr/libexec/cortexa8hf-vfp-neon-rdk-linux-gnueabi/gccgcc/arm-rdk-linux-gnueabi/4.9.4/ld: error: .libs/libgstpluginxxx_la-gstpluginxxx.o: requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC
here the whole error
./arm-rdk-linux-gnueabi-libtool --tag=CC --tag=disable-static --mode=link arm-rdk-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 -fno-omit-frame-pointer -fno-optimize-sibling-calls --sysroot=/home/sysroots/path -pthread -I/home/sysroots/path/usr/include/gstreamer-1.0 -I/home/sysroots/path/usr/include/glib-2.0 -I/home/sysroots/path/usr/lib/glib-2.0/include -O2 -pipe -g -feliminate-unused-debug-types -fPIC -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o libgstpluginxxx.la -rpath /usr/lib/gstreamer-1.0 libgstpluginxxx_la-gstpluginxxx.lo -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0
arm-rdk-linux-gnueabi-libtool: link: arm-rdk-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -enable-shared -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 -fno-omit-frame-pointer -fno-optimize-sibling-calls --sysroot=/home/sysroots/path -shared -fPIC -DPIC .libs/libgstpluginxxx_la-gstpluginxxx.o /home/sysroots/path/usr/lib/libgstreamer-1.0.so -L/home/sysroots/path/usr/lib /home/sysroots/path/usr/lib/libgmodule-2.0.so -lm -ldl /home/sysroots/path/usr/lib/libgobject-2.0.so /home/sysroots/path/usr/lib/libffi.so /home/sysroots/path/usr/lib/libglib-2.0.so -lpthread -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 --sysroot=/home/sysroots/path -pthread -O2 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -pthread -Wl,-soname -Wl,libgstpluginxxx.so.0 -o .libs/libgstpluginxxx.so.0.0.0
/home/build-directory/tmp/sysroots/x86_64-linux/usr/libexec/cortexa8hf-vfp-neon-rdk-linux-gnueabi/gcc/arm-rdk-linux-gnueabi/4.9.4/ld: error: .libs/libgstpluginxxx_la-gstpluginxxx.o: requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC
I was confused, why the build was failed to recompile with -fPIC though it was mentioned in the linking command? I tried -fPIC option manually everywhere in the Makefile and libtool script, but no use :(
and
without modifying the source and recipe file, it was success in 32-bit toolchain whereas failed in 64-bit toolchain and telling to recompile with -fPIC option
Below are the build machine info.
BB_VERSION = "1.28.0"
BUILD_SYS = "i686-linux"
NATIVELSBSTRING = "Ubuntu-14.04"
This is likely a bug in gold linker. similar to
https://sourceware.org/ml/binutils/2010-12/msg00473.html
It seems you are using gold linker as default ld. So please pass
LDFLAGS += "-fuse-ld=bfd"
in recipe for this package. and see if that helps. This will force GNU BFD linker to be used for this package.
I was confused, why the build was failed to recompile with -fPIC though it was mentioned in the linking command? I tried -fPIC option manually everywhere in the Makefile and libtool script, but no use :(
Regarding these statements...
make distclean should clean all artifacts so everything gets rebuilt. You will also need to reconfigure.
Before you reconfigure, open your configure.ac and be sure you have a LT_INIT that includes pic-only:
AC_INIT([Crypto++], [8.3], ...)
LT_INIT([pic-only,enable-shared,enable-static])
AM_INIT_AUTOMAKE
...
This is the first time I started use Dlib library.
I make a project and include dlib's face detection example cpp.
I have already linked to pthread and -std=c++1 into my project.
I have already included the folder path which has dlib folder inside.
I have already included source.cpp into my project.
When I build, I have errors from this source.cpp as
15:43:22 * Build of configuration Debug for project ObjectDetectionDlib *
make all
Building file: ../src/ObjectDetectionDlib.cpp
Invoking: GCC C++ Compiler
g++ -DGXX_EXPERIMENTAL_CXX0X -I/home/nyan/Softwares/Dlib_Lib/ -O0 -g3 -Wall -c -fmessage-length=0 -std=c++11 -MMD -MP -MF"src/ObjectDetectionDlib.d" -MT"src/ObjectDetectionDlib.o" -o "src/ObjectDetectionDlib.o" "../src/ObjectDetectionDlib.cpp"
Finished building: ../src/ObjectDetectionDlib.cpp
Building file: ../src/source.cpp
Invoking: GCC C++ Compiler
g++ -DGXX_EXPERIMENTAL_CXX0X -I/home/nyan/Softwares/Dlib_Lib/ -O0 -g3 -Wall -c -fmessage-length=0 -std=c++11 -MMD -MP -MF"src/source.d" -MT"src/source.o" -o "src/source.o" "../src/source.cpp"
../src/source.cpp:7:41: fatal error: ../base64/base64_kernel_1.cpp: No such file or directory
#include "../base64/base64_kernel_1.cpp"
^
compilation terminated.
make: *** [src/source.o] Error 1
What is wrong? I use g++/4.8 as compiler.
I have C code using OpenMP what I want to include in MATLAB as a mex function. I have already done it and works perfectly in MATLAB R2013b under Linux. However, I recently read about OMPi and according to this article it beats most of the commercial compilers, mainly gcc what I currently use. Therefore, I would like make use of it. It works well for C codes, but I cannot make it work with a mex function. I tried it four ways:
Edited the CC='gcc' entry in the mexopts.sh file to CC='ompicc' and called mex
Directly called ompi as ompicc -k -I/opt/MATLAB/R2013b/extern/include mex_sum_openmp.c
Setting the verbose flag for mex, I obtained information about what mex is doing, so I tried to mimic it: ompicc -k -I/opt/MATLAB/R2013b/extern/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fexceptions -fPIC -fno-omit-frame-pointer -pthread -DMX_COMPAT_32 -O -DNDEBUG mex_sum_openmp.c
Since ompi is a source-to-source compiler, I compiled the mex_sum_openmp.c file with ompicc -k mex_sum_openmp.c to mex_sum_openmp_ompi.c and then called gcc on it: gcc -I/opt/MATLAB/R2013b/extern/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fexceptions -fPIC -fno-omit-frame-pointer -pthread -DMX_COMPAT_32 -O -DNDEBUG mex_sum_openmp_ompi.c (this is what ompi does without the -k flag: first creates the source compiled file and then calls a regular compiler on it)
Either way, the result is the same, a bunch of warnings and then error messages.
Here is the original C file: http://s000.tinyupload.com/?file_id=70221693843831744745, here the source compiled file :http://s000.tinyupload.com/?file_id=02497191022856307556 and here are the warnings and errors: http://s000.tinyupload.com/?file_id=93602974698898858427
Thanks
I want to write a tool to capture and visualize pressed keys in a specific application so I searched for a sample source.
My result was this:
http://www.codeguru.com/cpp/w-p/system/keyboard/article.php/c5699
But it doesn't work yet. Here's my approach:
I have imported the sources as makefile project in Elipse (Helios, CDT Version 7.0.0.201006141710) using Mingw 4.6.1 as toolchain.
In keydll3.cpp I added the line
#define KEYDLL3_EXPORTS
to tell the preprocessor that i want to export the dll functions.
Now when I try to compile the project, the following errors occour:
**** Internal Builder is used for build ****
g++ -shared -DBUILDING_EXAMPLE_DLL -IC:\MinGW\include -IC:\MinGW\lib\gcc\mingw32\4.6.1\include\c++ -O2 -g -Wall -c -fmessage-length=0 -oStdAfx.o ..\StdAfx.cpp
g++ -shared -DBUILDING_EXAMPLE_DLL -IC:\MinGW\include -IC:\MinGW\lib\gcc\mingw32\4.6.1\include\c++ -O2 -g -Wall -c -fmessage-length=0 -okeydll3.o ..\keydll3.cpp
..\keydll3.cpp:31:0: warning: ignoring #pragma data_seg [-Wunknown-pragmas]
..\keydll3.cpp:34:0: warning: ignoring #pragma data_seg [-Wunknown-pragmas]
..\keydll3.cpp:36:0: warning: ignoring #pragma comment [-Wunknown-pragmas]
g++ -okeydll3 keydll3.o StdAfx.o
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../libmingw32.a(main.o): In function `main':
C:\MinGW\msys\1.0\src\mingwrt/../mingw/main.c:73: undefined reference to `WinMain#16'
collect2: ld returned 1 exit status
Build error occurred, build is stopped
It seems that the compiler misses the winmain statement because he assume it's a windows application. But a dll isn't.
It also seems that the "-share" option has no effect.
So how do I tell the compiler that my code is a dll with some Windows API calls?
If there's another example which works without visual studio let me know.
Thanks in advance for your contributions.
Noir
You've added the -shared option in the wrong place. It needs to be added to the linker flags, not to the compiler flags. Your commands should look like this.
g++ -DBUILDING_EXAMPLE_DLL -IC:\MinGW\include -IC:\MinGW\lib\gcc\mingw32\4.6.1\include\c++ -O2 -g -Wall -c -fmessage-length=0 -oStdAfx.o ..\StdAfx.cpp
g++ -DBUILDING_EXAMPLE_DLL -IC:\MinGW\include -IC:\MinGW\lib\gcc\mingw32\4.6.1\include\c++ -O2 -g -Wall -c -fmessage-length=0 -okeydll3.o ..\keydll3.cpp
g++ -shared -okeydll3 keydll3.o StdAfx.o