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.
Related
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.
I am building a project over cmake with a ninja generator and build my project for coverage with add_compile_options("$<$<CONFIG:COVERAGE>:-g;-O0;-ftest-coverage;-fprofile-arcs;-fno-builtin>"). What happens is that my gcno files are put in the ${CMAKE_BINARY_DIR} and not in the corresponding target directory like ${CMAKE_BINARY_DIR}/CMakeFiles/Project.dir.
The implication of this difference is that I now cannot have source files with the same name.
When I build the same project with makefiles, the gcno files do end up in those folders. I checked the different calls it does in the command line and the difference is the following. It is most definitely the change of working directory.
How can I tell ninja to also put the gcno files in the corresponding project directories?
make
cd C:/my_project/MASTER/build/EXTERNAL_3RDPARTY/blake2 && C:/qnx700/host/win64/x86_64/usr/bin/qcc.exe -Vgcc_ntox86_64 -IC:/C:/my_project/3RDPARTY/blake2/src -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wconversion -Wall -Wextra -pedantic -Wmissing-declarations -Wunused -Wpedantic -Wlogical-op -Wdouble-promotion -Wformat=2 -fmessage-length=0 -fno-exceptions -march=broadwell -g -O0 -ftest-coverage -fprofile-arcs -fno-builtin -std=c11 -o CMakeFiles/libblake2.dir/src/blake2/blake2b.c.o -c C:/my_project/3RDPARTY/blake2/src/blake2/blake2b.c
ninja:
C:\qnx700\host\win64\x86_64\usr\bin\qcc.exe -Vgcc_ntox86_64 -IC:/C:/my_project/3RDPARTY/blake2/src -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wconversion -Wall -Wextra -pedantic -Wmissing-declarations -Wunused -Wpedantic -Wlogical-op -Wdouble-promotion -Wformat=2 -fmessage-length=0 -fno-exceptions -march=broadwell -g -O0 -ftest-coverage -fprofile-arcs -fno-builtin -std=c11 -Wp,-MD,EXTERNAL_3RDPARTY\blake2\CMakeFiles\libblake2.dir\src\blake2\blake2b.c.o.d -Wp,-MT,EXTERNAL_3RDPARTY/blake2/CMakeFiles/libblake2.dir/src/blake2/blake2b.c.o -Wp,-MF,EXTERNAL_3RDPARTY\blake2\CMakeFiles\libblake2.dir\src\blake2\blake2b.c.o.d -o EXTERNAL_3RDPARTY/blake2/CMakeFiles/libblake2.dir/src/blake2/blake2b.c.o -c C:/my_project/3RDPARTY/blake2/src/blake2/blake2b.c
We did some more research and came to the conclusion that the qcc.exe wrapper is the actual problem. Using gcc.exe directly resolves the issue.
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 have been trying to install the HDF5 API in Windows using MinGW and Cygwin. I have given up on MinGW (after failing to compile HDF5-1.8.11 on it) because I need to use HDF5 on Fortran.
Using Cygwin with HDF5-1.8.11 produces errors when running the configure (bash) script and therefore it does not even start to compile. I read on this link that the HDF5-1.8 compiles on Cygwin including the Fortran module. I downloaded an older version (HDF5-1.8.0) and the configure works fine, but the compile (2nd make) gives the following error:
Making all in src
make[1]: Entering directory `/cygdrive/c/hdf5-1.8.0/src'
make all-am
make[2]: Entering directory `/cygdrive/c/hdf5-1.8.0/src'
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/cygdrive/c/cygwin/usr/include -DNDEBUG -UH5_DEBUG_API -ansi -pedantic -Wall -W -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -O3 -fomit-frame-pointer -finline-functions -MT H5Omtime.lo -MD -MP -MF .deps/H5Omtime.Tpo -c -o H5Omtime.lo H5Omtime.c
gcc -DHAVE_CONFIG_H -I. -I/cygdrive/c/cygwin/usr/include -DNDEBUG -UH5_DEBUG_API -ansi -pedantic -Wall -W -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -O3 -fomit-frame-pointer -finline-functions -MT H5Omtime.lo -MD -MP -MF .deps/H5Omtime.Tpo -c H5Omtime.c -o H5Omtime.o
In file included from H5private.h:29:0,
from H5Omtime.c:24:
H5public.h:154:18: warning: ISO C90 does not support ‘long long’ [-Wlong-long]
H5public.h:155:16: warning: ISO C90 does not support ‘long long’ [-Wlong-long]
H5Omtime.c: In function ‘H5O_mtime_decode’:
H5Omtime.c:194:9: warning: implicit declaration of function ‘tzset’ [-Wimplicit-function-declaration]
H5Omtime.c:194:9: warning: nested extern declaration of ‘tzset’ [-Wnested-externs]
H5Omtime.c:230:17: error: ‘timezone’ undeclared (first use in this function)
H5Omtime.c:230:17: note: each undeclared identifier is reported only once for each function it appears in
Makefile:813: recipe for target `H5Omtime.lo' failed
make[2]: *** [H5Omtime.lo] Error 1
make[2]: Leaving directory `/cygdrive/c/hdf5-1.8.0/src'
Makefile:488: recipe for target `all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory `/cygdrive/c/hdf5-1.8.0/src'
Makefile:410: recipe for target `all-recursive' failed
make: *** [all-recursive] Error 1
I would appreciate any help on this! Thanks!
I was able to reproduce this error. It seems that the configure script sets a number of #define flags which indicate the presence of the timezone global variable, which in reality is not present within the cygwin environment and is thus reported missing in the error message. By removing the #define H5_HAVE_TIMEZONE from the header file H5pubconf.h I was able to get rid of this error.
Unfortunately, then still another error occurs during the make process, which can also be avoided by removing the #define H5_HAVE_GETPWUID from the same header file H5pubconf.h.
Although this does not explain what really went wrong during configure, with these two modifications I am able to successfully compile the library.
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?