I am trying to compile boost on cygwin with help of following article
But when I ran following statement
bjam --without-python --without-serialization toolset=gcc-android4.4.3 link=static runtime-link=static target-os=linux --stagedir=android
It started compilation but failed due to following error:
cc1plus.exe: error: unrecognized command line option "-mthreads"
I am using latest cygwin and boost 1.48.0
I would appreciate if anybody can give me a hint to remove this error.
Update:
I found solution. Boost assumed cygwin has MingW gcc compiler so it added that special option in configuation file "gcc.jam" Once I removed the option it ran OK.
Short
Pass target-os=android to b2
Explanation
I faced with same issue for Boost 1.59
According boost/tools/build/src/tools/gcc.jam line 1024
rule setup-threading ( targets * : sources * : properties * )
{
local threading = [ feature.get-values threading : $(properties) ] ;
if $(threading) = multi
{
local target = [ feature.get-values target-os : $(properties) ] ;
local option ;
local libs ;
switch $(target)
{
case android : # No threading options, everything is in already.
case windows : option = -mthreads ;
case cygwin : option = -mthreads ;
case solaris : option = -pthreads ; libs = rt ;
case beos : # No threading options.
case haiku : option = ;
case *bsd : option = -pthread ; # There is no -lrt on BSD.
case sgi : # gcc on IRIX does not support multi-threading.
case darwin : # No threading options.
case * : option = -pthread ; libs = rt ;
}
if $(option)
{
OPTIONS on $(targets) += $(option) ;
}
if $(libs)
{
FINDLIBS-SA on $(targets) += $(libs) ;
}
}
}
As you can see -mthreads depends on target-os param
Related
When I compile my project:
----------------------------------------------------------------------
wxFlasher configuration :
+ DEBUG = 0
+ UNICODE = 1
+ STATIC = 0
+ WX_VERSION = 3.0.2
+ SRC_DIR = /home/barnaud/dev/wxFlasher/wxFlasher/src
+ BUILD_DIR_BASE = /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu
+ OUT_DIR = /home/barnaud/dev/wxFlasher/wxFlasher/out_gcc/releaseu
+ GCC_PATH = /usr/bin/gcc
+ GCC_VERSION = gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
----------------------------------------------------------------------
Generating Main/Headers.h.gch...
/home/barnaud/dev/wxFlasher/wxFlasher/src/Main/Headers.h:18:23: fatal error: wx/wxprec.h: Aucun fichier ou dossier de ce type
#include <wx/wxprec.h>
I well installed the libraries:
$ wx-config --libs
-L/usr/lib/x86_64-linux-gnu -pthread -lwx_gtk2u_unofficial_xrc-3.0 -lwx_gtk2u_unofficial_webview-3.0 -lwx_gtk2u_unofficial_html-3.0 -lwx_gtk2u_unofficial_qa-3.0 -lwx_gtk2u_unofficial_adv-3.0 -lwx_gtk2u_unofficial_core-3.0 -lwx_baseu_unofficial_xml-3.0 -lwx_baseu_unofficial_net-3.0 -lwx_baseu_unofficial-3.0
cxxflags output :
wx-config --cxxflags
-I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0-unofficial -I/usr/include/wx-3.0-unofficial -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread
Now, how can I include the library in my project?
Look at the compiler command line (by running make -n if necessary, i.e. if your makefile hides it by default) and check if it uses the correct flags from wx-config. If it does, also check that you ran make install after building wxWidgets so that the headers are indeed available in the directory appearing in wx-config --cxxflags output.
Here's some sample test code I'm trying to run on an embedded Linux system:
#include <iostream>
int main(int argc, char *argv[])
{
char c = 'A';
int i = 7;
std::cout << "Hello World from C++" << std::endl;
std::cout << "c=" << c << std::endl;
std::cout << "i=" << i << std::endl;
}
The embedded system is a Microblaze, which is a 32-bit RISC softcore processor running on a Xilinx FPGA. Please don't be put off by that, as a lot of your standard Linux knowledge will still apply. The processor is configured as LSB with an MMU, and the Linux build I'm using (PetaLinux, supplied by Xilinx) is expecting the same. I'm using the supplied GNU compiler; Microblaze appears to be officially supported in GCC.
The problem I'm having is that when the stdlib needs to interact with the integer, it segfaults. Here's the output:
Hello World from C++
c=A
Segmentation fault
Note that the char is handled fine. The C equivalent of this code also works fine:
#include <stdio.h>
int main(int argc, char *argv[])
{
char c = 'A';
int i = 7;
printf("Hello World from C\n");
printf("c=%c\n", c);
printf("i=%i\n", i);
return 0;
}
...
Hello World from C
c=A
i=7
This leads me to suspect an issue with the shared library libstdc++.so.6.0.20. That library is supplied by Xilinx though, so it should be correct. The file output of that library is:
libstdc++.so.6.0.20: ELF 32-bit LSB shared object, Xilinx MicroBlaze 32-bit RISC, version 1 (SYSV), dynamically linked, not stripped
The file output of my binary is:
cpptest: ELF 32-bit LSB executable, Xilinx MicroBlaze 32-bit RISC, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 2.6.32, stripped
I've also tried statically linking my binary using the -static flag, but the result was the same.
Here are the most relevant compiler and linker settings I'm using, but I've tried changing these with no avail.
CC=microblazeel-xilinx-linux-gnu-gcc
CXX=microblazeel-xilinx-linux-gnu-g++
CFLAGS= -O2 -fmessage-length=0 -fno-common -fno-builtin -Wall -feliminate-unused-debug-types
CPPFLAGS?=
CXXFLAGS= -O2 -fmessage-length=0 -fno-common -fno-builtin -Wall -feliminate-unused-debug-types
LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
To compile:
#$(CCACHE) $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(CFLAGS) $< -o "$#"
To link:
#$(CXX) $(RELOBJECTS) $(LDFLAGS) $(EXT_LIBS) -o $(RELBINARY)
Note that microblazeel refers to the little endian version of the microblaze compiler.
I would very much like to debug this or at least look at a coredump, but no coredump seems to be produced when the segfault happens, and there's no gdb executable in the Microblaze Linux build. Maybe I'm missing something?
Thanks for taking your time to read this. Any thoughts?
From what I could see after a bit of research, vivado is the HW development IDE [because they offer a trial period--so it's the HW devel, which they always want to charge for].
If you're using the standard SDK board from Xilinx, everything should be preconfigured. Otherwise, a HW designer produces a HW design that has Microblaze in it.
From that, you may have to use petalinux to generate a new boot, kernel, etc. image that is compatible.
You may need to rebuild libstdc++ from source, but I'd do that as a last resort. For example, don't bother with it, until you've got gdb working and have test results.
Here are some petalinux PDF files:
http://www.xilinx.com/support/documentation/sw_manuals/petalinux2013_10/ug977-petalinux-getting-started.pdf
http://www.xilinx.com/support/documentation/sw_manuals/petalinux2013_10/ug981-petalinux-application-development-debug.pdf
The development guide shows how to invoke gdb (e.g.):
On the target system:
gdbserver host:1534 /bin/myapp
On the development system:
petalinux-utils --gdb myapp followed by target remote 192.168.0.10:1534
I've done some editing on your Makefile with annotations. I've commented out some of the non-essential options. Note that I'm using the += operator to build up CFLAGS/CXXFLAGS gradually
The basic idea here is to do a build with minimum deviations from "standard". Add only proven essential options. Build and test. Add back the options one-by-one [rebuild and test each time] until you find the option that is causing the problem.
I do, however, have a strong suspicion about -fno-common being a source of problems. Also, to a lesser extent, I'm a bit suspicious of -Wl,--as-needed
Should these options work? Sure, but xilinx/microblaze ain't no x86 ...
I've added two command line make variables:
DEBUG -- generate for debug with gdb
VERBOSE -- show everything about the build process
For example, try make <whatever> DEBUG=1 VERBOSE=1
CC = microblazeel-xilinx-linux-gnu-gcc
CXX = microblazeel-xilinx-linux-gnu-g++
CPPFLAGS ?=
CMFLAGS += -Wall -Werror
CMFLAGS += -fmessage-length=0
# compile for gdb session
# NOTES:
# (1) -gdwarf-2 may or may not be the the right option for microblaze
# (2) based on doc for -feliminate-unused-debug* petalinux/microblaze may want
# stabs format
ifdef DEBUG
CMFLAGS += -gdwarf-2
CMFLAGS += -O0
# compile for normal build
#else
CMFLAGS += -O2
CMFLAGS += -feliminate-unused-debug-types
endif
# NOTE: I used to use "#" on commands, but now I leave it off -- debug or not
# sure it's "ugly" but you can get used to it pretty quickly--YMMV
ifndef VERBOSE
Q :=
else
###Q := #
Q :=
endif
# let compiler/linker tell you _everything_:
# (1) configure options when tool was built
# (2) library search paths
# (3) linker scripts being used
ifdef VERBOSE
CMFLAGS += -v
LDFLAGS += -Wl,--verbose=2
endif
CMFLAGS += -fno-builtin
# NOTE: I'd _really_ leave this off as it may confuse c++ std as "<<" calls
# _M_insert (which is in the library, which is almost certainly _not_ using
# -fno-common)
###CMFLAGS += -fno-common
# NOTE: I'm also suspicious of this a little bit because the c++ lib may have
# some "weak" symbols that the c library doesn't
###LDFLAGS += -Wl,--as-needed
# NOTE: this seems harmless enough, but you can comment it out to see if it
# helps
LDFLAGS += -Wl,--hash-style=gnu
# NOTE: an optimization only
ifndef DEBUG
LDFLAGS += -Wl,-O1
endif
CFLAGS += $(CMFLAGS)
CXXFLAGS += $(CMFLAGS)
# NOTES:
# (1) leave this off for now -- doesn't save _that_ much and adds complexity
# to the build
# (2) IMO, I _never_ use it and I erase/uninstall it on any system I
# administrate (or just ensure the build doesn't use it by removing it
# from $PATH)--YMMV
###XCCACHE = $(CCACHE)
# to compile
$(Q)$(XCCACHE) $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(CFLAGS) $< -o "$#"
# to link
$(Q)$(CXX) $(RELOBJECTS) $(LDFLAGS) $(EXT_LIBS) -o $(RELBINARY)
I have bunch of source code which I compiled using -ggdb3 flag.
I have copied the source code and executable to an another machine.
When I run the exe in gdb it does not show the statements at the line numbers when it breaks.
This is what I see
Breakpoint 1, TestCode (handler=0x806e110, args=0xffffd2b0)
at ../myfile.c:1080
1080 ../myfile.c: No such file or directory.
(gdb) n
1083 in ../myfile.c
(gdb)
1084 in ../myfile.c
(gdb)
1085 in ../myfile.c
I even tried setting the dir path using gdb dir command by giving the name of the topmost directory of the source code but no help.
Example my source code directory structure is like
C
|
--------------
| |
D E
|
F
|
-----------
| |
S T
The file I am debugging may be in some inner folder say F.
While I gave the path of folder C in gdb dir
dir /home/C
Any way to resolve this issue?
More details are:
> OS SUSE Linux Enterprise Server 11 (x86_64)
> gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux)
> GNU gdb (GDB) SUSE (7.5.1-0.7.29)
Here are the Makefile details
#
# Makefile for building demo code on SUSE Linux
all : SLIBINSTALLDIR = $(SDESTDIR)$(SLIBDIR)
###########################################
# Defines #
###########################################
CC = --mode=compile gcc
LINK =$(DESTDIR)libtool --mode=link gcc
INDEPSDIR = ../../../../../dependencies/internal
MODULE = TestCode
INCLUDE = -I../ -I$(INDEPSDIR)/include
CFLAGS := $(CFLAGS) $(INCLUDE) -DN_PLAT_UNIX -DN_PLAT_GNU -DVERSION=0x00010002 -D_GNU_SOURCE -g -ggdb3
CSRC = ../myfile.c ../decode.c ../encode.c
COBJ = $(CSRC:.c=.o)
COBJ1 = $(CSRC:.c=.lo)
TestCode:$(COBJ)
$(LINK) $(CFLAGS) -o TestCode $(COBJ1) -all-static
DESRC = ../main.c
DEOBJ = $(DESRC:.c=.o)
You should define a source path substitution rule using command:
set substitute-path from to
It will substitute from part into to allowing to find sources in new location.
See https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html.
Also info sources command will be useful to remember from part in the command above in case you forgot where your sources were located before copying.
Is there any way to get the version and vendor of the compiler used by the user through qmake? What I need is to disable building some targets of my project when g++ 3.x is used and enable them when g++ 4.x is used.
Update: Most answers targeted the preprocessor. This is something that I want to avoid. I don't want a target to be build for a specific compiler version and I want this decision to be made by the build system.
In addition to ashcatch's answer, qmake allows you to query the command line and get the response back as a variable. So you could to something like this:
linux-g++ {
system( g++ --version | grep -e "\<4.[0-9]" ) {
message( "g++ version 4.x found" )
CONFIG += g++4
}
else system( g++ --version | grep -e "\<3.[0-9]" ) {
message( "g++ version 3.x found" )
CONFIG += g++3
}
else {
error( "Unknown system/compiler configuration" )
}
}
Then later, when you want to use it to specify targets, you can use the config scoping rules:
SOURCES += blah blah2 blah3
g++4: SOURCES += blah4 blah5
My answer based on Caleb Huitt - cjhuitt's. But his approach does not work for me.
*-g++ {
GCC_VERSION = $$system("g++ -dumpversion")
contains(GCC_VERSION, 6.[0-9]) {
message( "g++ version 6.x found" )
CONFIG += g++6
} else {
contains(GCC_VERSION, 5.[0-9]) {
message( "g++ version 5.x found" )
CONFIG += g++5
} else {
contains(GCC_VERSION, 4.[0-9]) {
message( "g++ version 4.x found" )
CONFIG += g++4
} else {
message( "Unknown GCC configuration" )
}
}
}
}
As you see you can get version from GCC and then compare it with regex expression.
The way how to use is the same:
SOURCES += blah blah2 blah3
g++4: SOURCES += blah4 blah5
As a start, I would look at the scoping feature that qmake supports:
Scopes and Conditions
But while I read about it, it seems that by default you can use general platform conditions like win32 or unix or you can use the name of the qmake spec like linux-g++. You could test the Visual Studio version like this (since the different Visual Studio versions use different qmake specs), but I don't think that you can test the gcc version like this (at least I don't know how).
My answer is based on dismine's answer
We can simply extract the major version number using $$str_member
gcc | clang {
COMPILER_VERSION = $$system($$QMAKE_CXX " -dumpversion")
COMPILER_MAJOR_VERSION = $$str_member($$COMPILER_VERSION)
greaterThan(COMPILER_MAJOR_VERSION, 3): message("gcc 4 or later")
greaterThan(COMPILER_MAJOR_VERSION, 4): message("gcc 5 or later")
greaterThan(COMPILER_MAJOR_VERSION, 5): message("gcc 6 or later")
greaterThan(COMPILER_MAJOR_VERSION, 6): message("gcc 7 or later")
}
I do
isEmpty(MGWVER) {
MGW_MAJ = $$system(echo | gcc -dM -E - | fgrep __GNUC__ | cut -d\" \" -f 3)
MGW_MIN = $$system(echo | gcc -dM -E - | fgrep __GNUC_MINOR__ | cut -d\" \" -f 3)
MGWVER =$$MGW_MAJ$$MGW_MIN
message(MGWVER $$MGWVER)
}
It returns "48".
I use it for linking proper boost libraries:
USER_BOOST_CFG=mgw$${MGWVER}-mt-s-$$(BOOST_VER)
message($$USER_BOOST_CFG)
LIBS *= -L$$(BOOST_ROOT)/lib
LIBS *= -L$$(BOOST_ROOT)/stage/lib
LIBS *= -lboost_system-$$USER_BOOST_CFG
LIBS *= -lboost_filesystem-$$USER_BOOST_CFG
LIBS *= -lboost_date_time-$$USER_BOOST_CFG
effectively giving:
-lboost_system-mgw48-mt-s-1_54
I am on mingw.
Another idea is to look at QMAKESPEC vaariable and parse from it, hint:
message(QMAKESPEC $$QMAKESPEC)
SPLITED=$$section(QMAKESPEC, "/", 0, -3)
message(SPLITED $$SPLITED)
Each compiler vendor use to define some specific symbols that identify the compiler and version. You could make the check using those symbols.
I know, for example, that _MSC_VER gives the version of Microsoft C++ Compiler.
What I also know is that Boost Libraries use this kind of feature selection and adaptation.
You can take a look to Boost Config headers, found in include folder, at path: boost/config/* , specially at select_compiler_config.hpp.
By using those compiler specific symbols, you can make feature selection at preprocessing phase of building the code.
The following macros are defined in my version of gcc and g++
#define __GNUC__ 4
#define __GNUC_MINOR__ 0
#define __GNUC_PATCHLEVEL__ 1
Additionaly the g++ defines:
#define __GNUG__ 4
Is there any way to get the version and vendor of the compiler used by the user through qmake? What I need is to disable building some targets of my project when g++ 3.x is used and enable them when g++ 4.x is used.
Update: Most answers targeted the preprocessor. This is something that I want to avoid. I don't want a target to be build for a specific compiler version and I want this decision to be made by the build system.
In addition to ashcatch's answer, qmake allows you to query the command line and get the response back as a variable. So you could to something like this:
linux-g++ {
system( g++ --version | grep -e "\<4.[0-9]" ) {
message( "g++ version 4.x found" )
CONFIG += g++4
}
else system( g++ --version | grep -e "\<3.[0-9]" ) {
message( "g++ version 3.x found" )
CONFIG += g++3
}
else {
error( "Unknown system/compiler configuration" )
}
}
Then later, when you want to use it to specify targets, you can use the config scoping rules:
SOURCES += blah blah2 blah3
g++4: SOURCES += blah4 blah5
My answer based on Caleb Huitt - cjhuitt's. But his approach does not work for me.
*-g++ {
GCC_VERSION = $$system("g++ -dumpversion")
contains(GCC_VERSION, 6.[0-9]) {
message( "g++ version 6.x found" )
CONFIG += g++6
} else {
contains(GCC_VERSION, 5.[0-9]) {
message( "g++ version 5.x found" )
CONFIG += g++5
} else {
contains(GCC_VERSION, 4.[0-9]) {
message( "g++ version 4.x found" )
CONFIG += g++4
} else {
message( "Unknown GCC configuration" )
}
}
}
}
As you see you can get version from GCC and then compare it with regex expression.
The way how to use is the same:
SOURCES += blah blah2 blah3
g++4: SOURCES += blah4 blah5
As a start, I would look at the scoping feature that qmake supports:
Scopes and Conditions
But while I read about it, it seems that by default you can use general platform conditions like win32 or unix or you can use the name of the qmake spec like linux-g++. You could test the Visual Studio version like this (since the different Visual Studio versions use different qmake specs), but I don't think that you can test the gcc version like this (at least I don't know how).
My answer is based on dismine's answer
We can simply extract the major version number using $$str_member
gcc | clang {
COMPILER_VERSION = $$system($$QMAKE_CXX " -dumpversion")
COMPILER_MAJOR_VERSION = $$str_member($$COMPILER_VERSION)
greaterThan(COMPILER_MAJOR_VERSION, 3): message("gcc 4 or later")
greaterThan(COMPILER_MAJOR_VERSION, 4): message("gcc 5 or later")
greaterThan(COMPILER_MAJOR_VERSION, 5): message("gcc 6 or later")
greaterThan(COMPILER_MAJOR_VERSION, 6): message("gcc 7 or later")
}
I do
isEmpty(MGWVER) {
MGW_MAJ = $$system(echo | gcc -dM -E - | fgrep __GNUC__ | cut -d\" \" -f 3)
MGW_MIN = $$system(echo | gcc -dM -E - | fgrep __GNUC_MINOR__ | cut -d\" \" -f 3)
MGWVER =$$MGW_MAJ$$MGW_MIN
message(MGWVER $$MGWVER)
}
It returns "48".
I use it for linking proper boost libraries:
USER_BOOST_CFG=mgw$${MGWVER}-mt-s-$$(BOOST_VER)
message($$USER_BOOST_CFG)
LIBS *= -L$$(BOOST_ROOT)/lib
LIBS *= -L$$(BOOST_ROOT)/stage/lib
LIBS *= -lboost_system-$$USER_BOOST_CFG
LIBS *= -lboost_filesystem-$$USER_BOOST_CFG
LIBS *= -lboost_date_time-$$USER_BOOST_CFG
effectively giving:
-lboost_system-mgw48-mt-s-1_54
I am on mingw.
Another idea is to look at QMAKESPEC vaariable and parse from it, hint:
message(QMAKESPEC $$QMAKESPEC)
SPLITED=$$section(QMAKESPEC, "/", 0, -3)
message(SPLITED $$SPLITED)
Each compiler vendor use to define some specific symbols that identify the compiler and version. You could make the check using those symbols.
I know, for example, that _MSC_VER gives the version of Microsoft C++ Compiler.
What I also know is that Boost Libraries use this kind of feature selection and adaptation.
You can take a look to Boost Config headers, found in include folder, at path: boost/config/* , specially at select_compiler_config.hpp.
By using those compiler specific symbols, you can make feature selection at preprocessing phase of building the code.
The following macros are defined in my version of gcc and g++
#define __GNUC__ 4
#define __GNUC_MINOR__ 0
#define __GNUC_PATCHLEVEL__ 1
Additionaly the g++ defines:
#define __GNUG__ 4