I am in my first compilation using the accelerometer_app example. Ninja crashes in step 1. It seems to be due to a problem with the linking process. Here is the output.
PS G:\Cardiovelo_sur_NAS\Laboratoires\Labo_TI\Labo_Movesense\movesense-device-lib\myBuild> ninja
[1/1] Linking CXX executable Movesense
FAILED: Movesense
cmd.exe /C "cd . && C:\PROGRA~2\GNUTOO~1\92019-~1\bin\AR19DD~1.EXE -W -Wall -Werror -Wfatal-errors -Wshadow -Wpointer-arith -Wcast-qual -Wwrite-strings -Wunreachable-code -Wsign-compare -Wno-aggregate-return -Wno-unused-parameter -Wno-unused-function -Wno-cast-align -Wno-strict-aliasing -Wno-maybe-uninitialized -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fno-common -ffreestanding -fno-builtin -mapcs -gdwarf-3 -std=gnu++11 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -fno-unwind-tables -fno-use-cxa-atexit -fno-threadsafe-statics -Wno-old-style-declaration -Wno-discarded-qualifiers -Wp,-w -Wno-write-strings -U__INT32_TYPE__ -D__INT32_TYPE__=int -U__UINT32_TYPE__ -D__UINT32_TYPE__="unsigned int" -Os -g -DWB_UNITTEST_BUILD -Wl,--wrap -Wl,_malloc_r -Wl,--wrap -Wl,_calloc_r -Wl,--wrap -Wl,_free_r -Wl,--wrap -Wl,_realloc_r --specs=nano.specs --specs=nosys.specs -Wl,-Map -Wl,target.map -Wl,--gc-sections -Wl,-static -LG:/Cardiovelo_sur_NAS/Laboratoires/Labo_TI/Labo_Movesense/movesense-device-lib/MovesenseCoreLib/app-build/compiler/../platform/nRF5x/linker/gcc -TG:/Cardiovelo_sur_NAS/Laboratoires/Labo_TI/Labo_Movesense/movesense-device-lib/MovesenseCoreLib/app-build/compiler/../platform/nRF5x/linker/gcc/appflash.ld CMakeFiles/Movesense.dir/AccelerometerSampleService.cpp.obj CMakeFiles/Movesense.dir/App.cpp.obj CMakeFiles/Movesense.dir/generated/sbem-code/sbem_definitions.cpp.obj CMakeFiles/Movesense.dir/generated/app-resources/resources.cpp.obj CMakeFiles/Movesense.dir/app-metadata/metadata.cpp.obj -o Movesense G:/Cardiovelo_sur_NAS/Laboratoires/Labo_TI/Labo_Movesense/movesense-device-lib/MovesenseCoreLib/lib/GCCARM/libmovesense-coreD.a -lm -lstdc++ && cd ."
c:/progra~2/gnutoo~1/92019-~1/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: G:/Cardiovelo_sur_NAS/Laboratoires/Labo_TI/Labo_Movesense/movesense-device-lib/MovesenseCoreLib/lib/GCCARM/libmovesense-coreD.a(nrf_log_backend_serial.c.obj): in function `nrf_log_backend_serial_hexdump_handler':
E:\BuildAgent\work\939b802005569609\vendor\nRF5_SDK\components\libraries\log\src/nrf_log_backend_serial.c:446: undefined reference to `__locale_ctype_ptr'
c:/progra~2/gnutoo~1/92019-~1/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: G:/Cardiovelo_sur_NAS/Laboratoires/Labo_TI/Labo_Movesense/movesense-device-lib/MovesenseCoreLib/lib/GCCARM/libmovesense-coreD.a(manufacturingdata.c.obj): in function `store_pcba_string':
E:\BuildAgent\work\939b802005569609\nea\hal\manufacturingdata/manufacturingdata.c:926: undefined reference to `__locale_ctype_ptr'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed
The first error is:
E:\BuildAgent\work\939b802005569609\vendor\nRF5_SDK\components\libraries\log\src/nrf_log_backend_serial.c:446: undefined reference to `__locale_ctype_ptr'
I installed nrfutil (version 6.0.1) on python 2.7.9 (default version on my PC).
Obviously, there is something that does not work and I need help to solve the problem.
OKAY. The problem was 18 "in front of the screen! I had installed the wrong version of the GNU Toolchain for ARM Embedded compiler. However, it was well written to choose the 2017q4 version.
The subject can be considered closed.
Related
n order to install caffe,which is used for deep learing,i need to upgrade gcc version from 4.4.7 to 4.8.2 in redhat 6.5。
First run ./configure it worked,
then make -j4, it will report
options.c:11145: error: narrowing conversion of '-0x00000000000000001' from 'int' to 'short unsigned int' inside { }
g++ -std=gnu++0x -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace ../../gcc/hash-table.c -o hash-table.o
g++ -std=gnu++0x -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace ../../gcc/file-find.c -o file-find.o
make[3]: *** [options.o] Error 1
make[3]: *** Waiting for unfinished jobs....
I search google,but can't find good ways to fix it ,who has the same issues before?
Replacing the original gcc can cause problems. The alternative is to install Developer Toolset which installs a new gcc version (currently at 4.9) along side the original to avoid file conflict. Get started here: http://developers.redhat.com/products/developertoolset/overview/
I'm trying to build gcc 4.9.2 on RHEL6, as follows:
unpack the source tarball (to ~/gcc-4.9.2)
in the source dir:
./contrib/download_prerequisites
create a separate build directory ~/gcc-4.9.2-build
in the build dir:
~/gcc-4.9.2/configure --prefix=/usr/local/gcc-4.9.2
make
This fails with:
make[6]: Entering directory `/root/gcc-4.9.2-build-try0/x86_64-unknown-linux-gnu/libjava/classpath/native/jni/java-math'
/bin/sh ../../../libtool --tag=CC --mode=compile /root/gcc-4.9.2-build-try0/./gcc/xgcc -B/root/gcc-4.9.2-build-try0/./gcc/ -B/usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/include -isystem /usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/root/gcc-4.9.2/libjava/classpath/native/jni/java-math -I../../../include -I/root/gcc-4.9.2/libjava/classpath/include -I/root/gcc-4.9.2/libjava/classpath/native/jni/classpath -I/root/gcc-4.9.2/libjava/classpath/native/jni/native-lib -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -I/usr/include -g -O2 -MT gnu_java_math_GMP.lo -MD -MP -MF .deps/gnu_java_math_GMP.Tpo -c -o gnu_java_math_GMP.lo /root/gcc-4.9.2/libjava/classpath/native/jni/java-math/gnu_java_math_GMP.c
libtool: compile: /root/gcc-4.9.2-build-try0/./gcc/xgcc -B/root/gcc-4.9.2-build-try0/./gcc/ -B/usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/include -isystem /usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/root/gcc-4.9.2/libjava/classpath/native/jni/java-math -I../../../include -I/root/gcc-4.9.2/libjava/classpath/include -I/root/gcc-4.9.2/libjava/classpath/native/jni/classpath -I/root/gcc-4.9.2/libjava/classpath/native/jni/native-lib -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -I/usr/include -g -O2 -MT gnu_java_math_GMP.lo -MD -MP -MF .deps/gnu_java_math_GMP.Tpo -c /root/gcc-4.9.2/libjava/classpath/native/jni/java-math/gnu_java_math_GMP.c -fPIC -DPIC -o .libs/gnu_java_math_GMP.o
mv -f .deps/gnu_java_math_GMP.Tpo .deps/gnu_java_math_GMP.Plo
/bin/sh ../../../libtool --tag=CC --mode=link /root/gcc-4.9.2-build-try0/./gcc/xgcc -B/root/gcc-4.9.2-build-try0/./gcc/ -B/usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/include -isystem /usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/sys-include -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -I/usr/include -g -O2 -module -version-info 0:0:0 -no-undefined -lgmp -avoid-version -o libjavamath.la -rpath /usr/local/gcc-4.9.2/lib/../lib64/gcj-4.9.2-15 gnu_java_math_GMP.lo ../../../native/jni/classpath/jcl.lo -lrt
libtool: link: /root/gcc-4.9.2-build-try0/./gcc/xgcc -B/root/gcc-4.9.2-build-try0/./gcc/ -B/usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/include -isystem /usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/sys-include -shared .libs/gnu_java_math_GMP.o ../../../native/jni/classpath/.libs/jcl.o /root/gcc-4.9.2-build-try0/./gmp/.libs/libgmp.a -lrt -Wl,-soname -Wl,libjavamath.so -o .libs/libjavamath.so
/usr/bin/ld: /root/gcc-4.9.2-build-try0/./gmp/.libs/libgmp.a(mp_set_fns.o): relocation R_X86_64_32 against `__gmp_default_allocate' can not be used when making a shared object; recompile with -fPIC
/root/gcc-4.9.2-build-try0/./gmp/.libs/libgmp.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[6]: *** [libjavamath.la] Error 1
make[6]: Leaving directory `/root/gcc-4.9.2-build-try0/x86_64-unknown-linux-gnu/libjava/classpath/native/jni/java-math'
A little googling pointed me at the --disable-shared option, which sort of helped, but now:
in the build dir:
~/gcc-4.9.2/configure --prefix=/usr/local/gcc-4.9.2 --disable-shared
make
yielded a slightly different error:
make[8]: Entering directory `/root/gcc-4.9.2-build/x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni/classpath'
/bin/sh ../../../libtool --tag=CC --mode=compile /root/gcc-4.9.2-build/./gcc/xgcc -B/root/gcc-4.9.2-build/./gcc/ -B/usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/include -isystem /usr/local/gcc-4.9.2/x86_64-unknown-linux-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I/root/gcc-4.9.2/libjava/classpath/native/jni/classpath -I../../../include -I/root/gcc-4.9.2/libjava/classpath/include -I/root/gcc-4.9.2/libjava/classpath/native/jni/classpath -I/root/gcc-4.9.2/libjava/classpath/native/jni/native-lib -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -Wstrict-prototypes -pedantic -fexceptions -fasynchronous-unwind-tables -g -O2 -m32 -MT jcl.lo -MD -MP -MF .deps/jcl.Tpo -c -o jcl.lo /root/gcc-4.9.2/libjava/classpath/native/jni/classpath/jcl.c
libtool: compile: not configured to build any kind of library
libtool: compile: See the libtool documentation for more information.
libtool: compile: Fatal configuration error.
make[8]: *** [jcl.lo] Error 1
make[8]: Leaving directory `/root/gcc-4.9.2-build/x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni/classpath'
Adding the --enable-static option made no difference.
Any suggestions on what might be wrong?
BTW, gcc 4.9.1 gave the same errors.
System: Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Sun Jul 27 15:55:46 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
System is RHEL6, fully updated via Redhat, and has no custom RPMs that I know of.
Just completed building 4.9.2 on a CentOS 6.4 VM using 4.4.7 gcc. Ran into an out of space issue, which caused the build to fail, but once resolved, everything else went smoothly.
Looks like your build is failing in the Java side of town? Not sure if you need the Java support, so have you tried compiling just the c/c++ language support?
~/gcc-4.9.2/configure --enable-languages=c,c++ ...
I also don't require 32-bit binaries, so I add --disable-multilib to the list of configure parameters.
I am attempting to use Mingw-w64's 32-bit compiler (the i686-w64-mingw32 toolchain) to cross-compile the ICU library for Windows. The host is Ubuntu 12.10 64-bit.
The steps I have taken look something like this:
Grab the latest source code archive from here and extract it.
Make two copies of the source/ directory - one for the host and one for the target.
For the host build:
./configure ; make
For the target build:
./configure --host=i686-w64-mingw32 --with-cross-build=<host_source_dir>
...where <host_source_dir> is the directory from the previous step.
When I run make in the target source directory, compilation proceeds without any errors for a few moments and then throws this error:
i686-w64-mingw32-g++ -O2 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings
-Wno-long-long -mthreads -o ../../bin/uconv.exe uconv.o uwmsg.o
-L../../lib -licuin50 -L../../lib -licuuc50 -L../../stubdata -licudt50
-lm uconvmsg/uconvmsg.a
uconv.o:uconv.cpp:(.text+0x2f): undefined reference to `_uconvmsg_dat'
What could be causing this error? I backed up a few lines and also noticed this:
pkgdata: i686-w64-mingw32-gcc -O2 -Wall -std=c99 -pedantic -Wshadow
-Wpointer-arith -Wmissing-prototypes -Wwrite-strings -mthreads -shared
-Wl,-Bsymbolic -Wl,--enable-auto-import -Wl,--out-implib=./all.lib -o
../lib/icudt50.dll ./out/tmp/icudt50l_dat.o
Cannot export icudt50_dat: symbol not found
collect2: ld returned 1 exit status
-- return status = 256
Error generating library file. Failed command: i686-w64-mingw32-gcc -O2 -Wall
-std=c99 -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes
-Wwrite-strings -mthreads -shared -Wl,-Bsymbolic -Wl,--enable-auto-import
-Wl,--out-implib=./all.lib -o ../lib/icudt50.dll ./out/tmp/icudt50l_dat.o
Error generating assembly code for data.
What am I doing wrong?
In order to debug your symbol problem just provide the flag -Wl,--trace-symbol=_uconvmsg_dat to i686-w64-mingw32-g++ like follows:
i686-w64-mingw32-g++ -O2 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings
-Wno-long-long -mthreads -o ../../bin/uconv.exe uconv.o uwmsg.o
-L../../lib -licuin50 -L../../lib -licuuc50 -L../../stubdata -licudt50
-lm uconvmsg/uconvmsg.a -Wl,--trace-symbol=_uconvmsg_dat
So it turns out that the problem was indeed with the ICU source code. I'm not sure I understand exactly what the problem is, but thankfully someone else did and wrote three patches.
The first two apply to my question above:
icu4c-50_1_2-crossbuild.patch
icu4c-4_6_1-win32.patch
The third patch is used instead of the second in the list above when building for the x86_64 architecture:
icu4c-4_6_1-win64.patch
There does still seem to be a problem when running make install, but at least the source tree seems to build now.
I'm trying to build Gnu Octave for Windows.I built all the main dependencies without having much problem.And configuring process went well.But when I tried to run make(After few source modifications to get over some errors),It triggers tons of errors like
./.libs/liboctinterp.a(liboctinterp_la-octave.o): In function `safe_source_file':
C:\MinGW\sources\octave-3.6.2\src/octave.cc:312: undefined reference to `___cxa_begin_catch'
At the line
libtool: link: gcc -g -O2 -pthread -DHAVE_CONFIG_H -mieee-fp -Wall -W -Wshadow -Wformat -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -pthread -pthread -g -O2 -pthread -o .libs/octave.exe main.o ./.libs/liboctinterp.a /mingw/sources/octave-3.6.2~~/liboctave/.libs/liboctave.a -L=c:/mingw/bin/../lib/gcc/mingw32/4.7.0 -L=c:/mingw/bin/../lib/gcc -L=c:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../../mingw32/lib -L=c:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../.. -lfltk_gl -lfltk -lole32 -luuid -lcomctl32 -LC:/MinGW/lib /mingw/lib/libfontconfig.dll.a -L=C:/MinGW/lib /mingw/lib/libfreetype.dll.a -lz -lbz2 /mingw/lib/libexpat.dll.a -lopengl32 -lglu32 ../liboctave/.libs/liboctave.a /mingw/sources/octave-3.6.2~~/libcruft/.libs/libcruft.a /mingw/lib/libarpack.a /mingw/lib/libfftw3.a -lreadline -ltermcap /mingw/lib/libpcre.dll.a ../libcruft/.libs/libcruft.a -llapack -lblas -lgfortran -lquadmath -liberty -lgdi32 -lws2_32 -luser32 -lkernel32 -pthread -L/mingw/lib
I dumped the make log to a file and the file is about 39MB!! Just full of errors like above.
I'm very much thankful if someone can help me to get over this.
I am trying to make a library that wraps libpurple (you shouldn't need to know anything about libpurple to help here). Libpurple in turn loads "plugins" which are just .so's accessed via something like dlopen. Those plugins in turn call back to functions in libpurple.
I can build my library just fine, but when it calls the appropriate libpurple init function, and libpurple tries to load a plugin, I get an error like the following:
symbol lookup error: /usr/local/lib/purple-2/autoaccept.so: undefined
symbol: purple_user_dir
purple_user_dir is a function defined in libpurple. When I build a program (not a library) that links to libpurple there are no problems. I have tried using -export-dynamic and that did not seem to help. Here is my build command:
gcc -export-dynamic -I/usr/local/include/libpurple -I/usr/include/python2.5 -DH\
AVE_CONFIG_H -I. -DSTANDALONE -DBR_PTHREADS=0 -DDATADIR=\"/usr/local/share\" -D\
LIBDIR=\"/usr/local/lib/purple-2/\" -DLOCALEDIR=\"/usr/local/share/locale\" -DS\
YSCONFDIR=\"/usr/local/etc\" -Wall -Waggregate-return -Wcast-align -Wdeclarati\
on-after-statement -Wendif-labels -Werror-implicit-function-declaration -Wextra\
-Wno-sign-compare -Wno-unused-parameter -Winit-self -Wmissing-declarations -Wm\
issing-noreturn -Wmissing-prototypes -Wpointer-arith -Wundef -Wp,-D_FORTIFY_SOU\
RCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/inc\
lude/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/gl\
ib-2.0/include -I/usr/include/libxml2 -g -g -O2 -c -o spurple.o spurple.c
gcc -shared -g -O2 -Wl,--export-dynamic -pthread
../../libpurple/.libs/libpurple.so -o spurple.so spurple.o
-Wl,--export-dynamic /usr/local/lib/libpurple.so
-ldbus-glib-1 -ldbus-1 /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so
-ldl /usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so
/usr/lib/libxml2.so -lm -lpython2.5 -lutil -lpthread -lnsl -lresolv
Thanks.
I would try to use the ldd and nm unix commands to look for the symbols in the wrapper and wrapped libraries.
Just a shot in the dark, but do you have a different LD_LIBRARY_PATH environment variable when you build the app than when you run it?