I used to use -frecord-gcc-switches to embed a version string in a binary.
With gcc 10.4, when compiling some c code with -Wall -Werror -O3 -frecord-gcc-switches -DVERSION_THING=123hello, I'd get the following output from readelf -p .GCC.command.line
String dump of section '.GCC.command.line':
[ 0] -fdiagnostics-color=always
[ 1b] -imultiarch x86_64-linux-gnu
[ 38] -iprefix /opt/compiler-explorer/gcc-10.4.0/bin/../lib/gcc/x86_64-linux-gnu/10.4.0/
[ 8b] -D VERSION_THING=123hello
[ a5] /app/example.c
[ b4] -mtune=generic
[ c3] -march=x86-64
[ d1] -g
[ d4] -O3
[ d8] -Wall
[ de] -Werror
[ e6] -frecord-gcc-switches
However, with gcc 11.1 and later, I get this
String dump of section '.GCC.command.line':
[ 0] GNU C17 11.1.0 -mtune=generic -march=x86-64 -g -O3
Does anybody know where I should be looking to see what's changed between versions and why with regard to -frecord-gcc-switches and if it's possible to get the old behaviour back?
Related
Trying to compile C++ program using developerstudio12.6 CC on Solaris intel i386.
compiler do not show errors or warnings but fails.
Possible to figure why CC do not show any warnings or errors - what is possibly going wrong?
developerstudio12.6/bin/CC -mt -xtarget=native -m32 -g -errwarn=%all -O -DNDEBUG -c xml_test.cc -I<some include> -I<some other include> -o xml_test.o
echo $?
2
Using -verbose=template => similar output, no debug lines
Using -# or verbose=diags=> Huge amount of output but no error lines
### CC: Note: NLSPATH = `/opt/developerstudio12.6/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/developerstudio12.6/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat`
### command line files and options (expanded):
### -mt=yes -xtarget=native -xchip=broadwell -xcache=32/64/8/2:256/64/8/2:30720/64/20/24 -xarch=avx2_i -m32 -xdebuginfo=line,param,variable,tagtype,codetag,decl -xglobalize=yes -xpatchpadding=fix -Qoption driver -dconditional=yes -xkeep_unref=funcs,vars -verbose=diags -O3 -DNDEBUG -c xml_test.cc -I<some include> -I<some include> -oxml_test.o
/opt/developerstudio12.6/lib/compilers/bin/ccfe -D__SunOS_5_11 -D__SunOS_RELEASE=0x051100 -D__SUNPRO_CC=0x5150 -D__unix -D__SVR4__ -D__svr4__ -D__SVR4 -D__sun -D__sun__ -D__SunOS -D__i386 -D__i386__ -D__ORDER_LITTLE_ENDIAN__=1234 -D__ORDER_BIG_ENDIAN__=4321 -D__BYTE_ORDER__=__ORDER_LITTLE_ENDIAN__ -D__BUILTIN_VA_ARG_INCR -Dunix -Dsun -Di386 -D__FP_FAST_FMA__ -D__FP_FAST_FMAF__ -D_REENTRANT -D__SUN_PREFETCH -D__SUNPRO_CC_COMPAT=5 -I<some include> -I<some include> -I-xbuiltin -I/opt/developerstudio12.6/lib/compilers/include/CC/Cstd -I/opt/developerstudio12.6/lib/compilers/include/CC -I/opt/developerstudio12.6/lib/compilers/include/cc -DNDEBUG -ptf /tmp/ccfe.1620226479.15666.03.%1.%2 -ptx /opt/developerstudio12.6/bin/CC -ptk "-mt=yes -xtarget=native -m32 -xdebuginfo=line,param,decl,variable,tagtype,codetag -xglobalize=yes -xpatchpadding=fix -xkeep_unref=funcs,vars -verbose=diags -O3 -DNDEBUG -c -I<some include> -I<some include> " -compat=5 -xglobalize=yes -xdebuginfo=line,param,variable,tagtype,codetag,decl -instlib=/opt/developerstudio12.6/lib/compilers/libCstd.a -xdbggen=dwarf+usedonly+incl+line+param+variable+tagtype+codetag+decl -xF=%none -xbuiltin=%default -xldscope=global -xivdep=loop -xdepend -O3 -xarrayloc xml_test.cc -ptb xml_test.o -o /tmp/ccfe.1620226479.15666.01.ir 2> /tmp/ccfe.1620226479.15666.02.err
/opt/developerstudio12.6/lib/compilers/stdlibfilt -stderr < /tmp/ccfe.1620226479.15666.02.err
Your NLSPATH environment variable is incorrect.
/opt/developerstudio12.6/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat refers to /opt/lib/locale/%L/LC_MESSAGES/%N.cat instead of /opt/developerstudio12.6/lib/locale/%L/LC_MESSAGES/%N.cat because you have an extra .. element in it.
I fixed the issue just a while back by adding -filt=%none to the compiler options:
-mt -xtarget=native -m32 -filt=%none -g2 -verbose=template -errtags -library=iostream
Based on several postings in stackoverflow, in OSX 10.15, I can suppress warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness] from conftest.c by clang -Wno-nullability-completeness -o conftest -g -O2 -I/usr/local/opt/gettext/include -I/usr/local/opt/readline/include -I/usr/local/include conftest.c or gcc -Wno-nullability-completeness conftest.c. But how can I implement this for compiling a whole R pacakge from the source ? I added -Wno-nullability-completeness in R Makevers like this :
CC=clang -Wno-nullability-completeness
CXX=clang++ -Wno-nullability-completeness
CFLAGS=-Wno-nullability-completeness -g -O3 -Wall -pedantic -std=gnu99 -mtune=native -pipe
CXXFLAGS=-Wno-nullability-completeness -g -O3 -Wall -pedantic -std=c++11 -mtune=native
LDFLAGS=-L/usr/local/opt/gettext/lib -L$(LLVM_LOC)/lib -Wl,-rpath,$(LLVM_LOC)/lib
CPPFLAGS=-I/usr/local/opt/gettext/include -I$(LLVM_LOC)/include
but it did not work. Any suggestions or pointers will be seriously appreciated.
My system;
sw_vers
ProductName: Mac OS X
ProductVersion: 10.15.2
BuildVersion: 19C57
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/9.2.0_2/libexec/gcc/x86_64-apple-darwin19/9.2.0/lto-wrapper
Target: x86_64-apple-darwin19
Configured with: ../configure --build=x86_64-apple-darwin19 --prefix=/usr/local/Cellar/gcc/9.2.0_2 --libdir=/usr/local/Cellar/gcc/9.2.0_2/lib/gcc/9 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-9 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew GCC 9.2.0_2' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
Thread model: posix
gcc version 9.2.0 (Homebrew GCC 9.2.0_2)
clang -v
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-apple-darwin19.2.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin
brew info R
R: stable 3.6.2 (bottled)
Software environment for statistical computing
https://www.r-project.org/
/usr/local/Cellar/R/3.6.2 (2,123 files, 58.5MB)
Poured from bottle on 2019-12-14 at 09:37:12
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/r.rb
==> Dependencies
Build: pkg-config ✔
Required: gcc ✔, gettext ✔, jpeg ✔, libpng ✔, openblas ✔, pcre ✔, readline ✔, xz ✔
Flags:
CPATH=/usr/local/include
LDFLAGS=-L/usr/local/opt/llvm/lib
CPPFLAGS=-I/usr/local/opt/llvm/include
SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
Edit 1
From a suggestion by Ralf Stubner, I looked at an installer output generated by install.package("e1071", keep_outputs=T) ;
All my packages loaded Tue Dec 31 16:23:24 2019* installing *source* package ‘e1071’ ...
** package ‘e1071’ successfully unpacked and MD5 sums checked
** using staged installation
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether clang++ -std=gnu++11 accepts -g... yes
** libs
clang -I"/usr/local/Cellar/r/3.6.2/lib/R/include" -DNDEBUG -I/usr/local/opt/gettext/include -I/usr/local/opt/readline/include -I/usr/local/include **-fPIC -g -O2** -c Rsvm.c -o Rsvm.o
In file included from Rsvm.c:2:
/usr/local/include/stdio.h:67:13: warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness]
extern FILE *__stdinp ........;
and I realized that CXXFLAGs in my Makevars may not be read by clang at all. A following is my current Makevars;
LLVM_LOC = /usr/local/opt/llvm
CC=clang
CXX=clang++
CXX11=clang++
CFLAGS = -g -O3 -Wall -pipe -pedantic -Wno-nonnull -std=gnu99 -mtune=native
CXXFLAGS = -g -O3 -Wall -pipe -Wno-nonnull -pedantic -std=c++11 -mtune=native
CXX11FLAGS = -g -O3 -Wall -pipe -Wno-nonnull -pedantic -std=c++11 -mtune=native
LDFLAGS=-L/usr/local/opt/gettext/lib -L$(LLVM_LOC)/lib -Wl,-rpath,$(LLVM_LOC)/lib
CPPFLAGS=-I/usr/local/opt/gettext/include -I$(LLVM_LOC)/include
Ok I figured this out. Thanks to the help from RalfStubner. I realized that I was not putting Makevars in the right location. A default location of Makevars should be ~/.R/Makevars. Now, CXXFLAGS in the Makevars is read and -Wno-nonnull is applied. My latest Makevars is as follows;
LLVM_LOC = /usr/local/opt/llvm
CC=$(LLVM_LOC)/bin/clang -fopenmp
CXX=$(LLVM_LOC)/bin/clang++ -fopenmp
CC=clang
CXX=clang++
CXX11=clang++
CFLAGS = -g -O3 -Wall -pipe -pedantic -Wno-nonnull -std=gnu99 -mtune=native -pipe
CXXFLAGS = -g -O3 -Wall -pipe -Wno-nonnull -pedantic -std=c++11 -mtune=native
CXX11FLAGS = -g -O3 -Wall -pipe -Wno-nonnull -pedantic -std=c++11 -mtune=native
LDFLAGS=-L/usr/local/opt/gettext/lib -L$(LLVM_LOC)/lib -Wl,-rpath,$(LLVM_LOC)/lib
CPPFLAGS=-I/usr/local/opt/gettext/include -I$(LLVM_LOC)/include
I have a large program and library written in C++ and built with make. About a dozen options that are set in the makefile turn into preprocessor directives that change the implementation (with ifdefs, etc.). Right now I'm brute-forcing my build process by make cleaning when I change these compiler options before I run the code. I'd like to set up the system so that the binary's name changes based on the options. But, I'm worried that I'm going to miss one or add one in the future and forget to change the name, etc. Is there a clean way to handle this problem?
Some options I've considered:
manually create a binary name, such as APP.#{OPT_1}.#{OPT_2}.#{OPT_3}.#{OPT_4} when I build, and then run that one
create a hash (e.g., SHA1) from all of the compiler flags (CXXFLAGS) and put that hash into the name of my binary, such as APP.#{SHA1(CXXFLAGS)}. This has the value of extensibility in the future.
Any better approaches / recommendations?
Any better approaches / recommendations?
If I understand correctly, your GNU Make build system can build several variants of
your executable, differentiated by preprocessor macros that are defined (or not)
in the compilation commands depending on conditions that are tested in your Makefile
and/or on the arguments that you pass to make. And you want to be able to build
any of these variants independently, without needing a make clean to remove the
artifacts of the previous build, which might well have been a build of a different
variant.
This is one of the basic needs of build systems. The conventional solution is not the
one you're thinking about - to somehow encode differentiations into the name of
the executable. That won't work anyway, unless you do the same thing with the names of
the object files that are linked into the executable. If you don't, then when
you switch from variant X to variant Y, a variant-X object file foo.o
that is not older than foo.cpp, will not need to be recompiled,
even if should be for variant-Y, and that variant-X foo.o will be linked into the
variant Y executable, no matter what it is called.
The conventional solution is to differentiate, per variant, the place where the compiler
will output the object files and correspondingly the place where the linker
outputs the executable. No doubt all of the C/C++ IDEs you have ever used allow you
to build either a debug variant or a release variant of your project, and
they differentiate the debug object files and executable from the release object
files and executables by generating them in different subdirectories of the
project directory, e.g.
<projdir>/Debug/{obj|bin}
<projdir>/Release/{obj|bin}
or maybe:
<projdir>/obj/{debug|release}
<projdir>/bin/{debug|release}
This approach automatically encodes the variant of an object file or executable
into its absolute pathname,e.g.
<projdir>/Debug/obj/foo.o
<projdir>/bin/release/prog
without any further ado, and the variants can be built independently.
It's straightforward to implement this scheme in a makefile. Most of the IDEs
that use it do implement it in the makefiles that they generate behind the scenes.
And it's also straightforward to extend the scheme to more variants than just debug
and release (although whatever variants you want, you'll certainly want debug
and release variants of those variants).
Here's an illustration for a toy program that we want to build in any of the
variants that we get for combinations of two build-properties that we'll call
TRAIT_A and TRAIT_B:
| TRAIT_A | TRAIT_B |
|---------|---------|
| Y | Y |
|---------|---------|
| Y | N |
|---------|---------|
| N | Y |
|---------|---------|
| N | N |
And we want to be able to build any of those variants in debug mode or release
mode. TRAIT_{A|B} might map directly to a preprocessor macro, or to an
arbitrary combination of preprocessor flags, compiler options and/or linkage options.
Our program, prog, is built from just one source file:
main.cpp
#include <string>
#include <cstdlib>
int main(int atgc, char * argv[])
{
std::string cmd{"readelf -p .GCC.command.line "};
cmd += argv[0];
return system(cmd.c_str());
}
And all it does is invoke readelf to dump the linkage section .GCC.command.line
within its own executable. That linkage section only exists when we compile or
link with the GCC option -frecord-gcc-switches.
So purely for the purpose of the demo we'll always compile and link with that option.
Here's a makefile that adopts one way of differentiating all the variants:
object files are compiled in ./obj[/trait...]; executables are linked in
./bin[/trait...]:
Makefile
CXX = g++
CXXFLAGS := -frecord-gcc-switches
BINDIR := ./bin
OBJDIR := ./obj
ifdef RELEASE
ifdef DEBUG
$(error RELEASE and DEBUG are mutually exclusive)
endif
CPPFLAGS := -DNDEBUG
CXXFLAGS += -O3
BINDIR := $(BINDIR)/release
OBJDIR := $(OBJDIR)/release
endif
ifdef DEBUG
ifdef RELEASE
$(error RELEASE and DEBUG are mutually exclusive)
endif
CXXFLAGS += -O0 -g
BINDIR := $(BINDIR)/debug
OBJDIR := $(OBJDIR)/debug
endif
ifdef TRAIT_A
CPPFLAGS += -DTRAIT_A # or whatever
BINDIR := $(BINDIR)/TRAIT_A
OBJDIR := $(OBJDIR)/TRAIT_A
endif
ifdef TRAIT_B
CPPFLAGS += -DTRAIT_B # or whatever
BINDIR := $(BINDIR)/TRAIT_B
OBJDIR := $(OBJDIR)/TRAIT_B
endif
SRCS := main.cpp
OBJS := $(OBJDIR)/$(SRCS:.cpp=.o)
EXE := $(BINDIR)/prog
.PHONY: all clean
all: $(EXE)
$(EXE): $(OBJS) | $(BINDIR)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -o $# $(LDFLAGS) $^ $(LIBS)
$(OBJDIR)/%.o: %.cpp | $(OBJDIR)
$(CXX) -c -o $# $(CPPFLAGS) $(CXXFLAGS) $<
$(BINDIR) $(OBJDIR):
mkdir -p $#
clean:
$(RM) $(EXE) $(OBJS)
Now let's build, say, two variants in debug mode and two other variants in
release mode, one after the other
$ make DEBUG=1 TRAIT_A=1
mkdir -p obj/debug/TRAIT_A
g++ -c -o obj/debug/TRAIT_A/main.o -DTRAIT_A -frecord-gcc-switches -O0 -g main.cpp
mkdir -p bin/debug/TRAIT_A
g++ -DTRAIT_A -frecord-gcc-switches -O0 -g -o bin/debug/TRAIT_A/prog obj/debug/TRAIT_A/main.o
$ make DEBUG=1 TRAIT_B=1
mkdir -p obj/debug/TRAIT_B
g++ -c -o obj/debug/TRAIT_B/main.o -DTRAIT_B -frecord-gcc-switches -O0 -g main.cpp
mkdir -p bin/debug/TRAIT_B
g++ -DTRAIT_B -frecord-gcc-switches -O0 -g -o bin/debug/TRAIT_B/prog obj/debug/TRAIT_B/main.o
$ make RELEASE=1 TRAIT_A=1 TRAIT_B=1
mkdir -p obj/release/TRAIT_A/TRAIT_B
g++ -c -o obj/release/TRAIT_A/TRAIT_B/main.o -DNDEBUG -DTRAIT_A -DTRAIT_B -frecord-gcc-switches -O3 main.cpp
mkdir -p bin/release/TRAIT_A/TRAIT_B
g++ -DNDEBUG -DTRAIT_A -DTRAIT_B -frecord-gcc-switches -O3 -o bin/release/TRAIT_A/TRAIT_B/prog obj/release/TRAIT_A/TRAIT_B/main.o
$ make RELEASE=1
g++ -c -o obj/release/main.o -DNDEBUG -frecord-gcc-switches -O3 main.cpp
g++ -DNDEBUG -frecord-gcc-switches -O3 -o bin/release/prog obj/release/main.o
That last one is the release variant with neither TRAIT_A nor TRAIT_B.
We've now built four versions of program prog in different ./bin[/...] subdirectories
of the project, from different object files that are in different ./obj[/...] subdirectories,
and those versions will all tell us how they were differently built. Running in the order
we built them:-
$ bin/debug/TRAIT_A/prog
String dump of section '.GCC.command.line':
[ 0] -imultiarch x86_64-linux-gnu
[ 1d] -D_GNU_SOURCE
[ 2b] -D TRAIT_A
[ 36] main.cpp
[ 3f] -mtune=generic
[ 4e] -march=x86-64
[ 5c] -auxbase-strip obj/debug/TRAIT_A/main.o
[ 84] -g
[ 87] -O0
[ 8b] -frecord-gcc-switches
[ a1] -fstack-protector-strong
[ ba] -Wformat
[ c3] -Wformat-security
$ bin/debug/TRAIT_B/prog
String dump of section '.GCC.command.line':
[ 0] -imultiarch x86_64-linux-gnu
[ 1d] -D_GNU_SOURCE
[ 2b] -D TRAIT_B
[ 36] main.cpp
[ 3f] -mtune=generic
[ 4e] -march=x86-64
[ 5c] -auxbase-strip obj/debug/TRAIT_B/main.o
[ 84] -g
[ 87] -O0
[ 8b] -frecord-gcc-switches
[ a1] -fstack-protector-strong
[ ba] -Wformat
[ c3] -Wformat-security
$ bin/release/TRAIT_A/TRAIT_B/prog
String dump of section '.GCC.command.line':
[ 0] -imultiarch x86_64-linux-gnu
[ 1d] -D_GNU_SOURCE
[ 2b] -D NDEBUG
[ 35] -D TRAIT_A
[ 40] -D TRAIT_B
[ 4b] main.cpp
[ 54] -mtune=generic
[ 63] -march=x86-64
[ 71] -auxbase-strip obj/release/TRAIT_A/TRAIT_B/main.o
[ a3] -O3
[ a7] -frecord-gcc-switches
[ bd] -fstack-protector-strong
[ d6] -Wformat
[ df] -Wformat-security
$ bin/release/prog
String dump of section '.GCC.command.line':
[ 0] -imultiarch x86_64-linux-gnu
[ 1d] -D_GNU_SOURCE
[ 2b] -D NDEBUG
[ 35] main.cpp
[ 3e] -mtune=generic
[ 4d] -march=x86-64
[ 5b] -auxbase-strip obj/release/main.o
[ 7d] -O3
[ 81] -frecord-gcc-switches
[ 97] -fstack-protector-strong
[ b0] -Wformat
[ b9] -Wformat-security
We can clean the first one:
$ make DEBUG=1 TRAIT_A=1 clean
rm -f ./bin/debug/TRAIT_A/prog ./obj/debug/TRAIT_A/main.o
And the last one:
$ make RELEASE=1 clean
rm -f ./bin/release/prog ./obj/release/main.o
The second and third are still there and up to date:
$ make DEBUG=1 TRAIT_B=1
make: Nothing to be done for 'all'.
$ make RELEASE=1 TRAIT_A=1 TRAIT_B=1
make: Nothing to be done for 'all'.
For the exercise, you might consider refining the makefile to let you build, or clean,
all the variants at the same time. Or to default to DEBUG if RELEASE not is defined, or vice versa. Or to fail if no valid combination of traits is selected, for some definition of valid.
BTW, note that preprocessor options are conventionally assigned in the make variable
CPPFLAGS, for either C or C++ compilation; C compiler options are assigned
in CFLAGS and C++ compiler options in CXXFLAGS. GNU Make's built-in
rules assume that you follow these conventions.
I'm not sure it is a good idea to just use the binary name to separate different build configurations. Won't a change in the compiler options still cause the object files to be stomped on since I presume they will be named the same as the source files, and it will still effectively be a full rebuild anyway?
This looks to me as a prime candidate for out-of-source builds. Configure your build scripts to create all intermediate and output files in a separate directory outside the source directory. Each different set of build options will use a different build directory, perhaps choosing a directory name dynamically based on the hash of the compiler flags as you suggested.
This will give you a clean source tree, and by changing the compiler options in the makefile/build scripts you will change to which directory the intermediate and output files will be placed.
How can I tell if a certain c++ library was linked using
c++11 standard?
An elf binary would by default contain the signature of compiler version used.
Now, with regards to compiler flags used, If -frecord-gcc-switches is used at compile time, then, you can find the signature in ELF executable.
g++ -frecord-gcc-switches -std=c++0x trial.cpp
readelf -p .GCC.command.line a.out
String dump of section '.GCC.command.line':
[ 0] -imultilib . [ d] -imultiarch x86_64-linux-gnu [ 2a] -D_GNU_SOURCE [ 38] trial.cpp [ 42] -mtune=generic [ 51] -march=x86-64 [ 5f] -std=c++0x [ 6a] -frecord-gcc-switches [ 80]
-fstack-protector
I am cross-compiling using the CodeSourcery toolchain for arm (arm-none-linux-gnueabi). I use -isysroot to point at the /usr/include folder on a rootfs folder, but run into trouble when compiling. I have verified that the include folder is accessible.
Below is the gcc call and the output. Some of the output was removed because I don't think it is relevant.
The preprocessor comes up with an include path that is correct except for the "=" character that it starts with, and indicates that the path does not exist. It then fails to find the header files.
How can I make this work?
willem#jacta:~/Projects/button/Debug$ arm-none-linux-gnueabi-gcc -isysroot=/home/willem/Projects/rootfs -nostdinc -I=/usr/include -O0 -g3 -Wall -c -fmessage-length=0 -v -o src/smd/button/button.o ../src/smd/button/button.c -H
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with: [ ... stuff omitted ... ]
Thread model: posix
gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202)
COLLECT_GCC_OPTIONS='-isysroot=/home/willem/Projects/rootfs' '-nostdinc' '-I' '=/usr/include' '-O0' '-g3' '-Wall' '-c' '-fmessage-length=0' '-v' '-o' 'src/smd/button/button.o' '-H' '-march=armv5te' '-funwind-tables'
/home/willem/Tools/CodeSourcery/Sourcery_G++_Lite/bin/../libexec/gcc/arm-none-linux-gnueabi/4.4.1/cc1 -quiet -nostdinc -v -I =/usr/include -iprefix /home/willem/Tools/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/ -isysroot /home/willem/Tools/CodeSourcery/Sourcery_G++_Lite/bin/../arm-none-linux-gnueabi/libc -dD -H -isysroot=/home/willem/Projects/rootfs ../src/smd/button/button.c -quiet -dumpbase button.c -march=armv5te -auxbase-strip src/smd/button/button.o -g3 -O0 -Wall -version -fmessage-length=0 -funwind-tables -o /tmp/ccWnd3Xk.s
ignoring nonexistent directory "=/home/willem/Projects/rootfs/usr/include"
#include "..." search starts here:
#include <...> search starts here:
End of search list.
GNU C (Sourcery G++ Lite 2010q1-202) version 4.4.1 (arm-none-linux-gnueabi)
compiled by GNU C version 4.3.2, GMP version 4.3.1, MPFR version 2.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 250bf78701f747da89e730786c466148
. ../src/smd/button/button.h
../src/smd/button/button.c:2: error: no include path in which to search for pthread.h
[ ... etc. ... ]
Thanks!
W
The answer is that the -isysroot option does not need/want an "=" in the path specification, so the correct command is:
arm-none-linux-gnueabi-gcc -isysroot /home/willem/Projects/rootfs -nostdinc -I=/usr/include -O0 -g3 -Wall -c -fmessage-length=0 -v -o src/smd/button/button.o ../src/smd/button/button.c -H
Cheers,
W