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
...
Related
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 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.
I'm new to ios development, and I want to use the mp4v2 library. I have successfully compiled for iphone simulator, i386, but am having trouble compiling for the iphone architecture. Configuring/Make-ing for i386 was easy:
./configure --disable-gch --enable-ub=i386
However, using armv6/7 as a tag didn't work
./configure --disable-gch --enable-ub=armv6,armv7
While configuring worked, the make command led to the error below:
/bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -arch i386 -arch armv6 -arch armv7 -I./include -I./include -I. -I. -Wall -Wformat -g -O2 -fvisibility=hidden -c -o src/3gp.lo src/3gp.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -arch i386 -arch armv6 -arch armv7 -I./include -I./include -I. -I. -Wall -Wformat -g -O2 -fvisibility=hidden -c src/3gp.cpp -fno-common -DPIC -o src/.libs/3gp.o
llvm-g++-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/arm-apple-darwin11-llvm-g++-4.2': execvp: No such file or directory
llvm-g++-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/arm-apple-darwin11-llvm-g++-4.2': execvp: No such file or directory
lipo: can't figure out the architecture type of: /var/folders/b6/vmqqncd55k79nb1nc4x30nwr0000gn/T//cctU2lnr.out
make: *** [src/3gp.lo] Error 1
How do I compile for iphone?
I guess that this error is caused by trying to find cross compiler from system root path /usr/bin/../llvm-gcc-4.2/bin/arm-apple-darwin11-llvm-g++-4.2 instead of from Developer document.
A little stupid solution is create a symbolic link llvm-gcc-4.2 in system root path /usr, pointing to the real path.
I beleive you may need to verify your xcode-select(1) value so your path includes the new xcode release tree. The tools should have been found under /Applications/xcode with the latest release.
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
I'm creating a web application that requires the use of the perl module Crypt-SSLeay. This module has a dependency of needing OpenSSL headers. Since my Linux server has neither I went through these steps to install, but I'm receiving an error that's hard to understand (see below) because of my limited experience.
Server Information:
Running Oracle Enterprise Linux
Linux version 2.6.18-194.11.4.0.1.el5 (mockbuild#ca-build9.us.oracle.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48))
Steps to replicate the issue:
Downloaded and extracted openssl 0.9.8r from here and ran the following commands (after going to the directory)
./config --openssldir=/usr/local/openssl
make
make test
sudo make install
Downloaded and extracted the Crypt-SSLeay module from here and then ran the following commands (after going to the directory)
perl Makefile.PL
make
I receive the following error after I run "make":
BUILD INFORMATION
================================================
ssl library: OpenSSL 0.9.8r in /usr/local/openssl
ssl header: openssl/ssl.h
libraries: -L/usr/local/openssl/lib -lssl -lcrypto -lgcc
include dir: -I/usr/local/openssl/include
================================================
Note (probably harmless): No library found for -lgcc
Writing Makefile for Crypt::SSLeay
The test suite can attempt to connect to public servers
to ensure that the code is working properly. If you are
behind a strict firewall or have no network connectivity,
these tests may fail (through no fault of the code).
Do you want to run the live tests (y/N)? [N]
-bash-3.2$ make
gcc -c -I/usr/local/openssl/include -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DVERSION=\"0.58\" -DXS_VERSION=\"0.58\" -fPIC "-I/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE" SSLeay.c
SSLeay.c: In function ‘XS_Crypt__SSLeay__CTX_new’:
SSLeay.c:118: warning: unused variable ‘packname’
SSLeay.c: In function ‘XS_Crypt__SSLeay__Conn_new’:
SSLeay.c:395: warning: unused variable ‘packname’
SSLeay.c: In function ‘XS_Crypt__SSLeay__CTX_use_pkcs12_file’:
SSLeay.c:287: warning: ‘RETVAL’ may be used uninitialized in this function
Running Mkbootstrap for Crypt::SSLeay ()
chmod 644 SSLeay.bs
rm -f blib/arch/auto/Crypt/SSLeay/SSLeay.so
gcc -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic SSLeay.o -o blib/arch/auto/Crypt/SSLeay/SSLeay.so \
-L/usr/local/openssl/lib -lssl -lcrypto \
/usr/bin/ld: /usr/local/openssl/lib/libssl.a(s2_clnt.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/local/openssl/lib/libssl.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [blib/arch/auto/Crypt/SSLeay/SSLeay.so] Error 1
I'm not sure what I need to do when I recompile OpenSSL to get this module to work. Any help appreciated.
That looks like an error in the OpenSSL build itself. Are you sure your distribution doesn't provide the OpenSSL headers? (And i'm sure you already had the libraries, right?)
The headers are in a package called "openssl-devel" on RedHat IIRC, should be the same for Oracle Enterprise Linux (I guess, never used that).
If you do find the headers in your distro's packages, don't forget to un-install your custom build (remove the files manually if the OpenSSL Makefile doesn't have an uninstall target).