I'm trying to use MinGW-W64 instead of MinGW in Codelite. When I compile simple "hello, world" project it's all right. But when I try to link some libraries, I get a strange linker error. Project with exactly same settings compiles by MinGW with any problems. There are build output for both variants:
MinGW GCC 4.8.1
`C:\Windows\system32\cmd.exe /C D:/apps/mingw/bin/mingw32-make.exe -j8 SHELL=cmd.exe -e -f Makefile
"----------Building project:[ code - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'D:/Projects/codelite/code'
codelite-cc D:/apps/mingw/bin/g++.exe -c "D:/Projects/codelite/code/src/main.cpp" -Wfatal-errors -g -O0 -pedantic -W -std=c++11 -Wall -o ./Debug/src_main.cpp.o -I./inc/
D:/apps/mingw/bin/g++.exe -o bin/code #"code.txt" -L./lib/ -lopengl32
mingw32-make.exe[1]: Leaving directory 'D:/Projects/codelite/code'
====0 errors, 0 warnings====`
MinGW-W64 GCC 5.2.0
`C:\Windows\system32\cmd.exe /C D:/apps/mingw-w64/mingw32/bin/mingw32-make.exe -j8 SHELL=cmd.exe -e -f Makefile
"----------Building project:[ code - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'D:/Projects/codelite/code'
codelite-cc D:/apps/mingw-w64/mingw32/bin/g++.exe -c "D:/Projects/codelite/code/src/main.cpp" -Wfatal-errors -g -O0 -pedantic -W -std=c++11 -Wall -o ./Debug/src_main.cpp.o -I./inc/
D:/apps/mingw-w64/mingw32/bin/g++.exe -o bin/code #"code.txt" -L./lib/ -lopengl32
g++.exe: error: #code.txt -L./lib/: No such file or directory
mingw32-make.exe[1]: *** [bin/code] Error 1
code.mk:78: recipe for target 'bin/code' failed
mingw32-make.exe[1]: Leaving directory 'D:/Projects/codelite/code'
mingw32-make.exe: *** [All] Error 2
Makefile:4: recipe for target 'All' failed
====1 errors, 0 warnings====`
This looks like a bug in your toolchain and not in CodeLite.
There is a space between the "#code.text" and -L./lib and for some reason g++ does not see it...
I put my money on the mingw32-make tool. You can tell CodeLite to use the mingw32-make.exe from the 4.8.1 version (which worked): settings->build settings->compilers->[YOUR COMPILER NAME]->Make
Another option is to disable the option that tells CodeLite to generate Makefile that passes the object list via file to the compiler:
Settings->Build Settings->compilers->[YOUR COMPILER NAME]->Advanced tab and uncheck the option: pass object list to the linker via file
Lately i too have found the similar problem. Later i was able to figure out the issue. We just to need to go to the project settings under change makefile generator default to codelite makefile generator i think that will work.
Related
System Info: FreeBSD 11.3-RELEASE-p3, amd64
I have tried using nvm to install node v12.16.2, v10.20.1, and v10.15.3, however it fails building from source (no binary available for pull on BSD) with the same error on all three:
/usr/bin/ld:/usr/home/ifiht/.nvm/.cache/src/node-v12.16.2/files/out/Release/obj.target/tools/v8_gypfiles/libv8_libbase.a: file format not recognized; treating as linker script
/usr/bin/ld:/usr/home/ifiht/.nvm/.cache/src/node-v12.16.2/files/out/Release/obj.target/tools/v8_gypfiles/libv8_libbase.a:1: syntax error
Configure completes successfully:
$>./configure --prefix=/home/ifiht/.nvm/versions/node/v12.16.2 <
INFO: configure completed successfully
gmake -C out BUILDTYPE=Release V=0
and the last command before failure is:
/usr/bin/clang++ -o /usr/home/ifiht/.nvm/.cache/src/node-v12.16.2/files/out/Release/bytecode_builtins_list_generator -pthread -rdynamic -m64 -Wl,--export-dynamic -Wl,--start-group /usr/home/ifiht/.nvm/.cache/src/node-v12.16.2/files/out/Release/obj.target/bytecode_builtins_list_generator/deps/v8/src/builtins/generate-bytecodes-builtins-list.o /usr/home/ifiht/.nvm/.cache/src/node-v12.16.2/files/out/Release/obj.target/bytecode_builtins_list_generator/deps/v8/src/interpreter/bytecode-operands.o /usr/home/ifiht/.nvm/.cache/src/node-v12.16.2/files/out/Release/obj.target/bytecode_builtins_list_generator/deps/v8/src/interpreter/bytecodes.o /usr/home/ifiht/.nvm/.cache/src/node-v12.16.2/files/out/Release/obj.target/tools/v8_gypfiles/libv8_libbase.a -L/usr/local/lib -lexecinfo -Wl,--end-group
I'm out of troubleshooting ideas, if anyone knows how to enable nvm install verbosity that would also help, not sure why the linker is trying to read random .a (assembly?) files??
I'm trying to cross compile perl 5.24 using following method since the target machine does not have ssh installed.
https://github.com/arsv/perl-cross
Just for Fyi, my local machine is ubuntu x86_64 GNU/Linux.
I configure the toolchain with the following option:
./configure -Dsysroot=$QNX_TARGET -Dcc=ntoarmv7-gcc -Dtargetarch=armle -Dprefix=$HOME/localperl -Duseshrplib
The reason I think the above scripts worked just fine because it generates the makefile with the following message:
Generating config.h
Extracting config.h (with variable substitutions)
Generating Makefile.config
Configuration completed for native build
platform: x86_64-
c compiler: ntoarmv7-gcc
ld: ntoarmv7-gcc
ar: ar
ranlib: ranlib
when i run the make -j4 option i end up getting either of the following 2 results:
./generate_uudmap uudmap.h bitcount.h mg_data.h
./generate_uudmap: 1: ./generate_uudmap: Syntax error: word unexpected (expecting ")")
make: *** [uudmap.h] Error 2
OR
cp -f op.c opmini.c
cp -f perl.c perlmini.c
cp -f ext/re/re.pm lib/re.pm
sh cflags.SH
cp -f dist/ExtUtils-ParseXS/lib/ExtUtils/xsubpp lib/ExtUtils/xsubpp
ntoarmv7-gcc -DPERL_CORE --sysroot=/opt/qnx650/target/qnx6 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -Wno-unused-function -c -o op.o op.c
./miniperl_top lib/unicore/mktables -w -C lib/unicore -P pod -maketest -makelist -p
./miniperl_top: no ./miniperl found; build it before using miniperl_top
make: *** [lib/unicore/CombiningClass.pl] Error 1
I couldn't find much info on how to resolve the above issues. Could it be because i have not provided correct setting options for ./configure ?? If so, can you provide more insight on this.
EDIT:
It looks like i was passing the wrong information to ./configure script (it was considering it as the native rather than cross), I updated it with the following and was able to make bit of progress.
./configure -Dsysroot=/opt/qnx6 -Dcc=arm-unknown-nto-qnx6.6.0eabi-gcc --target-tools-prefix=arm-unknown-nto-qnx6.6.0eabi- --target=arm-unknown-nto-qnx6.6.0eabi --host=arm-unknown-nto-qnx6.6.0eabi -Dprefix=$HOME/localperl
with this, the configuration was successfull for the cross platform. Now when I perform the make, it runs fine for a bit and I run it following error
arm-unknown-nto-qnx6.6.0eabi-ar cru libperl.a op.o perl.o gv.o toke.o perly.o pad.o regcomp.o dump.o dquote.o util.o mg.o reentr.o mro_core.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o keywords.o caretx.o time64.o DynaLoader.o
arm-unknown-nto-qnx6.6.0eabi-ranlib libperl.a
./miniperl_top statars > static.list
./miniperl_top extlibs > ext.libs
arm-unknown-nto-qnx6.6.0eabi-gcc -DPERL_CORE --sysroot=/opt/qnx6 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -c -o perlmain.o perlmain.c
arm-unknown-nto-qnx6.6.0eabi-gcc --sysroot=/opt/qnx6 -Wl,-E -o perl perlmain.o libperl.a
libperl.a(pp.o): In function `Perl_pp_crypt':
pp.c:(.text+0xffd8): warning: The 'crypt' function has been deprecated in libc. Link against liblogin for extended algorithm support.
libperl.a(toke.o): In function `Perl_scan_num':
toke.c:(.text+0x27b82): undefined reference to `pow'
libperl.a(util.o): In function `Perl_drand48_r':
util.c:(.text+0xa36e): undefined reference to `ldexp'
libperl.a(sv.o): In function `S_hextract':
sv.c:(.text+0x13ca0): undefined reference to `frexp'
libperl.a(sv.o): In function `Perl_sv_vcatpvfn_flags':
sv.c:(.text+0x16cc0): undefined reference to `frexp'
libperl.a(time64.o): In function `Perl_gmtime64_r':
time64.c:(.text+0x338c): undefined reference to `fmod'
.
.
time64.c:(.text+0x359c): undefined reference to `floor'
time64.c:(.text+0x37e6): undefined reference to `ceil'
collect2: error: ld returned 1 exit status
make: *** [perl] Error 1
final problem was related to linking the libraries. adding -lm fixed the problem
arm-unknown-nto-qnx6.6.0eabi-gcc --sysroot=/opt/qnx660/target/qnx6 -Wl,-rpath,/home/swgroup/localperl/lib/perl5/5.24.0/arm-/CORE -Wl,-E -o perl perlmain.o libperl.so -lm
I m trying to build using gcc arm cross compiler and i get following error
Building file: ../src/application.c
Invoking: GCC C Compiler
arm-linux-gcc -O3 -Wall -c -I -fmessage-length=0 -MMD -MP -MF"src/application.d" -MT"src/application.d" -o "src/application.o" "../src/application.c"
/bin/sh: 1: arm-linux-gcc: not found
i also check my path setting and i had proper valid path to the arm-linux-gcc
and also linux "which" command gives the correct path of arm-linux-gcc..
could some one let me know what i am doing wrong..?
i figured it out,very silly mistake. i was trying to run 32-bit binary on a 64-bit system.
I have some trouble with crosscompiling C++ program which takes advantage of openMP library. I am using Linux Ubuntu 12.04 LTS. I want to obtain executable file runnable on Windows.
I have no problem with compiling my program with OMP with regular g++ command:
g++ a.cpp b.cpp -o OMPres -pg -O3 -I./CBLAS/include -L./ -lcblas
Also when I try crosscompilation without OMP, everything runs perfectly fine:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o res.exe -l gfortran -static
But when I try to crosscompile it with OMP using following command:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o OMPres.exe -l gfortran -static -fopenmp
I get this error:
a.cpp:41:17: fatal error: omp.h: No such file or directory
compilation terminated.
I found where omp.h file is located on my disk, and added the path to the command. After executing it:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include -I/usr/lib/gcc/x86_64-linux-gnu/4.6/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o OMPres.exe -l gfortran -static -fopenmp
I got another error: x86_64-w64-mingw32-g++: error: libgomp.spec: No such file or directory
As I also have this file on the disk I tried to copy it in various places and finaly it worked when I copied it directly into the directory where compilation takes place. Then it produced another error:
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lgomp
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lrt
collect2: ld returned 1 exit status
I don't have a good understanding of how compilers exactly work. I tried to update all mingw-w64 compilers that I could find with apt-cache search but nothing helped. I have no idea what more I can do :(.
First, #nmaier is completely correct in that the Ubuntu x86_64-w64-mingw32 toolchain is crippled, and that you can rebuild the toolchain yourself.
I, however, suggest that you use MXE, which saves you the time of manually compiling gcc and every dependency of it. The steps below should be enough for your purpose:
# Get MXE
git clone https://github.com/mxe/mxe.git && cd mxe
# Settings
cat <<EOF > settings.mk
MXE_TARGETS := x86_64-w64-mingw32.static
JOBS := 4
EOF
# Build gcc, libgomp, blas, and cblas. It will take a while
make -j2 libgomp cblas
# Add toolchain to PATH
# See http://htmlpreview.github.io/?https://github.com/mxe/mxe/blob/master/index.html#tutorial step 4
export PATH=`pwd`/usr/bin:$PATH
# You don't need -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a
# because headers and libraries are installed to standard location and
# I already used `-lcblas -lblas`.
x86_64-w64-mingw32-g++ a.cpp b.cpp -fopenmp -O3 -o res.exe -lcblas -lblas -lgfortran -lquadmath
Your x86_64-w64-mingw32 toolchain appears to have been build without libgomp.
You could check your supplier/distribution if it there additional or variant packages that have libgomp.
Or switch to a different supplier/distribution.
Or you could rebuild (or build in the first place) a cross gcc with --enable-libgomp. This is kinda the hard way.
PS:
Adding paths that do not correspond with your platform, like -I/usr/lib/gcc/x86_64-linux-gnu/4.6/include, is a bad idea in general, and will most certainly fail... This kinda creates a Franken-compiler.
i want to cross compile gsoap for arm-linux and this is my configuration command
./configure CC="arm-linux-gcc" CROSS_COMPILER="arm-linux-" ARCH="arm" --host=arm-linux LR="arm-linux-lr" LD="arm-linux-ld" LDFLAGS="-static" --enable-static --enable-samples --disable-openssl --prefix=/usr/local/gsoap-2.8 CXX="arm-linux-g++"
and i get this error after running make
arm-linux-gcc -DHAVE_CONFIG_H -I. -I../.. -DWITH_YACC -DWITH_LEX -DSOAPCPP_IMPORT_PATH="\"/usr/local/gsoap-2.8/share/gsoap/import\"" -DLINUX -g -O2 -MT soapcpp2-soapcpp2_yacc.o -MD -MP -MF .deps/soapcpp2-soapcpp2_yacc.Tpo -c -o soapcpp2-soapcpp2_yacc.o test -f 'soapcpp2_yacc.c' || echo './'soapcpp2_yacc.c
mv -f .deps/soapcpp2-soapcpp2_yacc.Tpo .deps/soapcpp2-soapcpp2_yacc.Po
/bin/bash ../../ylwrap soapcpp2_lex.l .c soapcpp2_lex.c -- /bin/bash /home/glassess/local/arm/gsoap-2.8/missing --run flex
make[4]: * [soapcpp2_lex.c] Error 1
so whats wrong,i must compile yacc and bison my self for arm-linux
so whats wrong,i must compile yacc and bison myself for arm-linux
You need to install flex for your build environment in order to be able to be executed by make (then not the cross-compiled one).
When I cross compile gSOAP the build output looks like:
/bin/bash ../../ylwrap soapcpp2_lex.l lex.yy.c soapcpp2_lex.c -- flex -l
In yours there is no flex command.
Probably configure flex detection failed.
You probably need to check if flex is available from your build environement, running flex -h or which flex.
compile dont need continue more for me, because i just need lib file and its create before this error