I have to configure and make GitHub | MFOC, but when I run ./configure it says:
# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... gcc3
checking whether make supports nested variables... (cached) yes
#Here the error
./configure: line 3930: syntax error near unexpected token `libnfc,'
./configure: line 3930: `PKG_CHECK_MODULES(libnfc, libnfc >= $LIBNFC_REQUIRED_VERSION, , AC_MSG_ERROR([libnfc >= $LIBNFC_REQUIRED_VERSION is mandatory.]))'
I have thought at 3 possible cause for the error:
The error occurrs becouse there are differences between the path or name requested.
In fact, synaptic says that libnfc in my Kali Linux is:
library: libnfc5, 1.7.1-b4
binaries: libnfc-bin, 1.7.1-b4
So maybe the problem is that 5 ahead libnfc
The path expected is different
Libnfc 1.7.1 is not supported, as last update (line 16 of ChangeLog) is for 1.7.0.
Can you help me please?
I report the help for configure, maybe it is interesting
# ./configure -help
`configure' configures mfoc 0.10.7 to adapt to many kinds of systems.
Usage: ./configure [OPTION]... [VAR=VALUE]...
To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE. See below for descriptions of some of the useful variables.
Defaults for the options are specified in brackets.
Configuration:
-h, --help display this help and exit
--help=short display options specific to this package
--help=recursive display the short help of all the included packages
-V, --version display version information and exit
-q, --quiet, --silent do not print `checking ...' messages
--cache-file=FILE cache test results in FILE [disabled]
-C, --config-cache alias for `--cache-file=config.cache'
-n, --no-create do not create output files
--srcdir=DIR find the sources in DIR [configure dir or `..']
Installation directories:
--prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local]
--exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
[PREFIX]
By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc. You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.
For better control, use the options below.
Fine tuning of the installation directories:
--bindir=DIR user executables [EPREFIX/bin]
--sbindir=DIR system admin executables [EPREFIX/sbin]
--libexecdir=DIR program executables [EPREFIX/libexec]
--sysconfdir=DIR read-only single-machine data [PREFIX/etc]
--sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com]
--localstatedir=DIR modifiable single-machine data [PREFIX/var]
--runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run]
--libdir=DIR object code libraries [EPREFIX/lib]
--includedir=DIR C header files [PREFIX/include]
--oldincludedir=DIR C header files for non-gcc [/usr/include]
--datarootdir=DIR read-only arch.-independent data root [PREFIX/share]
--datadir=DIR read-only architecture-independent data [DATAROOTDIR]
--infodir=DIR info documentation [DATAROOTDIR/info]
--localedir=DIR locale-dependent data [DATAROOTDIR/locale]
--mandir=DIR man documentation [DATAROOTDIR/man]
--docdir=DIR documentation root [DATAROOTDIR/doc/mfoc]
--htmldir=DIR html documentation [DOCDIR]
--dvidir=DIR dvi documentation [DOCDIR]
--pdfdir=DIR pdf documentation [DOCDIR]
--psdir=DIR ps documentation [DOCDIR]
Program names:
--program-prefix=PREFIX prepend PREFIX to installed program names
--program-suffix=SUFFIX append SUFFIX to installed program names
--program-transform-name=PROGRAM run sed PROGRAM on installed program names
Optional Features:
--disable-option-checking ignore unrecognized --enable/--with options
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
--enable-silent-rules less verbose build output (undo: "make V=1")
--disable-silent-rules verbose build output (undo: "make V=0")
--enable-dependency-tracking
do not reject slow dependency extractors
--disable-dependency-tracking
speeds up one-time build
Some influential environment variables:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
LIBS libraries to pass to the linker, e.g. -l<library>
CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
you have headers in a nonstandard directory <include dir>
CPP C preprocessor
Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.
The error message does not mean that there would be something wrong with libnfc on your system. There is something wrong in the shell script configure.
The configure script did not perform a check for libnfc. The error message is about a syntax error in the shell script at a line that was intended to do this check.
./configure: line 3930: syntax error near unexpected token `libnfc,'
./configure: line 3930: `PKG_CHECK_MODULES(libnfc, libnfc >= $LIBNFC_REQUIRED_VERSION, , AC_MSG_ERROR([libnfc >= $LIBNFC_REQUIRED_VERSION is mandatory.]))'
This doesn't exactly match the line numbers in the script you show on pastebin.
Here the error is at line 3963.
Script snippet starting at line 3949
...
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $am_cv_make_support_nested_variables" >&5
$as_echo "$am_cv_make_support_nested_variables" >&6; }
if test $am_cv_make_support_nested_variables = yes; then
AM_V='$(V)'
AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)'
else
AM_V=$AM_DEFAULT_VERBOSITY
AM_DEFAULT_V=$AM_DEFAULT_VERBOSITY
fi
AM_BACKSLASH='\'
# Checks for pkg-config modules.
LIBNFC_REQUIRED_VERSION=1.7.0
PKG_CHECK_MODULES(libnfc, libnfc >= $LIBNFC_REQUIRED_VERSION, , AC_MSG_ERROR([libnfc >= $LIBNFC_REQUIRED_VERSION is mandatory.]))
PKG_CONFIG_REQUIRES="libnfc"
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for inline" >&5
$as_echo_n "checking for inline... " >&6; }
if ${ac_cv_c_inline+:} false; then :
$as_echo_n "(cached) " >&6
else
ac_cv_c_inline=no
for ac_kw in inline __inline__ __inline; do
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
...
Before the comment line # Checks for pkg-config modules. it looks like a normal configure script.
The line PKG_CHECK_MODULES(libnfc, libnfc >= $LIBNFC_REQUIRED_VERSION, , AC_MSG_ERROR([libnfc >= $LIBNFC_REQUIRED_VERSION is mandatory.])) is wrong. This is autotools M5 macro code, not shell script.
From { $as_echo "$as_me:${as_lineno-$LINENO}: checking for inline" >&5 it looks normal again.
The configure script is generated from configure.in or configure.ac. This source is a M5 macro script using special autotools macros. All text that is not a known macro is copied to the output unchanged.
The problematic line PKG_CHECK_MODULES(libnfc, libnfc >= $LIBNFC_REQUIRED_VERSION, , AC_MSG_ERROR([libnfc >= $LIBNFC_REQUIRED_VERSION is mandatory.])) is a M5 macro call PKG_CHECK_MODULES() with several parameters whereof the last one is another macro call AC_MSG_ERROR() with a quoted argument.
I don't know why this ended up in the configure script, but this is obviously wrong. Maybe there is a bug in the configure.ac script, maybe a wrong version of the autotools was used to generate the configure script.
Thank you #Bodo, I was simply cloning the wrong branch. I know I'm a great noob, but slowly I'm learning. Thank you very much again.
Related
I am trying to generate LLVM bytecode file from a C source file (hello.c) using CMake. And below is my CMakeLists file.
###### CMakelists.txt ############
cmake_minimum_required(VERSION 2.8.9)
set(CMAKE_C_COMPILER "clang")
set(CMAKE_C_FLAGS "-emit-llvm")
project (hello)
add_executable(hello hello.c)
I am new to CMake and not sure if this is the right way. I could not find any rules to make *.bc in the generated MakeFile
. Please correct me here. I also tried "-save-temps"
Considering this for a single .c file. It would be really helpful if you could give me some hints on generating the same for a complete C project.
I think what you ultimately want is to be able to build a C-program
project with CMake and clang in which source files are compiled to LLVM bitcode
and the executable is linked from the bitcode files.
With CMake, asking clang to to link bitcode files means asking it to link in LTO mode,
with the -flto linkage option.
And you can get clang to compile to LLVM bitcode with the -flto compilation
option, or with the -emit-llvm option.
For illustration here is a Hello World project comprising two source files and one header:
$ ls -R
.:
CMakeLists.txt hello.c hello.h main.c
Here is the:
CMakeLists.txt
cmake_minimum_required(VERSION 3.0.2)
project (hello)
set(CMAKE_C_COMPILER clang)
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} "-flto")
add_executable(hello main.c hello.c)
target_compile_options(hello PUBLIC ${CMAKE_C_FLAGS} -flto)
#target_compile_options(hello PUBLIC ${CMAKE_C_FLAGS} -emit-llvm)
It will work equally well with:
#target_compile_options(hello PUBLIC ${CMAKE_C_FLAGS} -flto)
target_compile_options(hello PUBLIC ${CMAKE_C_FLAGS} -emit-llvm)
Make a build directory for CMake and go there:
$ mkdir build
$ cd build
Generate the build system:
$ cmake ..
Build:
$ make
Scanning dependencies of target hello
[ 33%] Building C object CMakeFiles/hello.dir/main.c.o
[ 66%] Building C object CMakeFiles/hello.dir/hello.c.o
[100%] Linking C executable hello
[100%] Built target hello
You will not find any *.bc targets in the Makefiles, nor any *.bc files
generated:
$ egrep -r '.*\.bc'; echo Done
Done
$ find -name '*.bc'; echo Done
Done
because the compilation option -flto or -emit-llvm results in an output
file:
CMakeFiles/hello.dir/main.c.o
CMakeFiles/hello.dir/hello.c.o
that adheres to the usual CMake naming convention but is in fact not an object file
but an LLVM bitcode file, as you see:
$ file $(find -name '*.o')
./CMakeFiles/hello.dir/hello.c.o: LLVM IR bitcode
./CMakeFiles/hello.dir/main.c.o: LLVM IR bitcode
The program does the usual thing:
$ ./hello
Hello World!
Later
When I try " make hello.o " it should generate the object file right?
the cmd executes successfully but, could not find the generated object file. Am I doing it right?
You are doing it in one way that is right, though not the only way that is right, but
your expectations are wrong. Look again at:
$ file $(find -name '*.o')
./CMakeFiles/hello.dir/hello.c.o: LLVM IR bitcode
./CMakeFiles/hello.dir/main.c.o: LLVM IR bitcode
You can see there that the .o files that are made from hello.c and main.c
by the CMake-generated makefile are not called hello.o and main.o but hello.c.o
and main.c.o. CMake prefers a compiled filename to preserve the extension of the
source file, and append .o. That is a fairly common practice. So if you wanted
to use the makefile to compile hello.c, the most obviously right way would be
make hello.c.o.
Let's see what actually happens. In my CMake build directory:
$ make VERBOSE=1 hello.c.o
make -f CMakeFiles/hello.dir/build.make CMakeFiles/hello.dir/hello.c.o
make[1]: Entering directory '/home/imk/develop/so/scrap/build'
make[1]: 'CMakeFiles/hello.dir/hello.c.o' is up to date.
make[1]: Leaving directory '/home/imk/develop/so/scrap/build'
There was nothing to be done, because my hello.c.o was up to date. So I'll
delete it and repeat:
$ rm CMakeFiles/hello.dir/hello.c.o
$ make VERBOSE=1 hello.c.o
make -f CMakeFiles/hello.dir/build.make CMakeFiles/hello.dir/hello.c.o
make[1]: Entering directory '/home/imk/develop/so/scrap/build'
Building C object CMakeFiles/hello.dir/hello.c.o
clang -flto -o CMakeFiles/hello.dir/hello.c.o -c /home/imk/develop/so/scrap/hello.c
make[1]: Leaving directory '/home/imk/develop/so/scrap/build'
Now it has been recompiled.
However, because many people - like you - would expect hello.o to be compiled
from hello.c, CMake helpfully defines hello.o as a .PHONY target
that depends on hello.c.o:
$ egrep -A3 'hello.o.*:.*hello.c.o' Makefile
hello.o: hello.c.o
.PHONY : hello.o
So in fact I can do:
$ rm CMakeFiles/hello.dir/hello.c.o
$ make VERBOSE=1 hello.o
make -f CMakeFiles/hello.dir/build.make CMakeFiles/hello.dir/hello.c.o
make[1]: Entering directory '/home/imk/develop/so/scrap/build'
Building C object CMakeFiles/hello.dir/hello.c.o
clang -flto -o CMakeFiles/hello.dir/hello.c.o -c /home/imk/develop/so/scrap/hello.c
make[1]: Leaving directory '/home/imk/develop/so/scrap/build'
make hello.o is another way of making hello.c.o
The problem is that using the -emit-llvm flag does not produce a final binary and stops the configuration tests that CMake performs once that flag is used in them.
Apart from what's already been written about using the LTO infrastructure, you have 3 (or 2 and a half) other alternatives.
One is to use Whole-Program LLVM and use the commands provided to extract the relevant bitcode parts.
The other is to go the manual way of setting up custom targets (see add_custom_target and add_custom_command) on your CMake binary targets, that will get triggered on changes and will reproduce the desired outcome as if executed manually on the command line each time.
Now, on this last point, I had a similar need so I created a CMake project that provides that functionality (llvm-ir-cmake-utils), but allows you to hook up those custom targets on existing ones as you please and see fit without having to rewrite everything from scratch each time.
There are examples in the repo, but in short, it allows you to attach custom targets on already existing CMake targets, e.g.
[...]
add_executable(qux ${SOURCES})
[...]
# this will create a bitcode generating target
# and allow it to depend on the initial target in order to detect source code changes
llvmir_attach_bc_target(qux_bc qux)
add_dependencies(qux_bc qux)
[...]
After make,
$>file CMakeFiles/hello.dir/hello.c.o
CMakeFiles/hello.dir/hello.c.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
if
set(CMAKE_C_FLAGS "-emit-llvm")
written before
project (hello)
In order to obtain IR bitcode, I wrote:
###### CMakelists.txt ############
cmake_minimum_required(VERSION 2.8.9)
project (hello)
set(CMAKE_C_COMPILER "clang")
set(CMAKE_C_FLAGS "-flto")
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} "-flto")
add_executable(hello hello.c)
target_compile_options(hello PUBLIC ${CMAKE_C_FLAGS} -flto)
I worked several hours in order to have a Makefile working to compile from IR
code to native using lld, then with cmake it was much more faster.
Then reading at cmake generated Makefile, I was able to correct my Makefile:
clang -flto -flto <hello.c.o> ..
this worked but I do not know why -flto is written twice.
Thanl you very much for this post, showing clang as the centralized front end to various llvm provided commands.
I am new to linux programming and learning it from The Linux Programming Interface by Michael Kerrisk.
I have to compile my first program that has dependencies.
Directory structure:
--linux-programs
|--seek_io.c
|--lib
|--tlpi_hdr.h
|--error_functions.h
|--error_functions.c
|--get_num.h
|--ename.c.inc
I want to compile seek_io.c program with dependencies in the lib directory, so that I can see how the program works.
I tried a few things, absolutely clueless on how they work following this stackoverflow answer. I get all sorts of errors as I am an absolute beginner to Linux programming, not to programming, linux OS and C.
Trials:
gcc -I ./lib/ -c ./lib/error_functions.c and then gcc -o seek_io.c ./error_function.o gives error:
/usr/lib/gcc/x86_64-linux-gnu/crt1.o: In function _start:
(.text+0x20): undefined reference to main
collect2: error: ld returned 1 exit status
After this run, on ls I find that my seek_io.c is not listed.
Basically the author of the book says for tlpi_hdr.h file:
This header file includes various other header files used by many of the example programs, defines a Boolean data type, and defines macros for calculating the minimum and maximum of two numeric values. Using this header file allows us to make the example programs a bit shorter.
Link to codes for files mentioned above:
tlpi_hdr.h
error_functions.h
error_functions.c
get_num.h
get_num.c
seek_io.c
The problem is with your second gcc command, where you're using the -o file to specify the output file where to store the resulting executable file, but passing it the name of the C source file seek_io.c instead...
gcc -o seek_io.c ./error_function.o
This means link file error_function.o and store the executable in seek_io.c. This fails because there is no main function, which is needed for a standalone executable, so your C source file is not overwritten by the failing link command.
You can fix this easily by passing the -o option a proper output file name, which in the case (of this link command) should be the name of the executable that you want to create, such as seek_io:
gcc -o seek_io seek_io.c ./error_function.o
(But this will fail without a -I ./lib/, since seek_io.c includes tlpi_hdr.h which is in that directory. If you add it to that command, it should work.)
You can also decide to split the compile and link steps in two separate steps (the command above will both compile seek_io.c into an object file and then link the two object files into an executable) with:
$ gcc -I ./lib/ -c ./lib/error_functions.c
$ gcc -I ./lib/ -c seek_io.c
$ gcc -o seek_io seek_io.o error_function.o
One final nitpick is that for the -I flag to specify the directories where to search for the include files, the more common usage has no space between the flag itself and the directory name, so you'll most commonly see -I./lib or even -Ilib.
$ gcc -Ilib -c ./lib/error_functions.c
$ gcc -Ilib -c seek_io.c
$ gcc -o seek_io seek_io.o error_function.o
I have a .m4 file that appends some flags to the linker, one of which sets the rpath flag. This script was originally written for a GNU version of ld that uses -rpath=<value>, however, I'm trying to run the script on OSX, where the version of ld uses -rpath <value>. The end result is that I see this in my config.log:
ld: unknown option: -rpath=path/to/stuff
Is there a way to detect something about how ld expects flags to be passed in from within my .m4 file so I can output the right format depending on the version available?
You could try to detect if linking succeeds with given flag using AC_LINK_IFELSE macro in your script, for example:
AC_MSG_CHECKING([for rpath flag style])
saved_cflags="$CFLAGS"
CFLAGS="$CFLAGS -Wl,-rpath=."
AC_LINK_IFELSE([AC_LANG_SOURCE([int main(){ return 0;}])],
[RPATH_FLAG=gnu],
[RPATH_FLAG=none])
CFLAGS="$saved_cflags"
if test "x$RPATH_FLAG" = "xnone"; then
CFLAGS="$CFLAGS -Wl,-rpath,."
AC_LINK_IFELSE([AC_LANG_SOURCE([int main(){ return 0;}])],
[RPATH_FLAG=llvm],
[RPATH_FLAG=none])
CFLAGS="$saved_cflags"
fi
AC_MSG_RESULT([$RPATH_FLAG])
And set proper flag based on this detection.
I mean whether gcc can insert some source code version infor into ELF binary as section or something similar. I do not want to change my source file, but add some info with gcc option in Makefile.
If you don't mind changing your source file just once, add something like this:
const volatile static char version[] = VERSION;
and compile with:
gcc -c -DVERSION='"1.2.3"'
The volatile keeps gcc from removing the string at higher optimization levels.
As written, this won't compile if you forget the -D option, which may be either good or bad depending on your requirements.
You can emit your version info into a text file, then turn that text file into an object file which you then statically link into your executable.
The first step is simple but you have to write some code: a script or something to write your version info in any format you like as a plain text file. Then write a makefile rule to produce say version.o from version.txt, using objcopy. Now you'll have an object file with two useful symbols defined in it: the beginning and end of the textual version info. Add that generated object to your executable, and you'll be able to access the version two ways: by running strings on the binary, or by writing code in the application to print the version string (you'll need to declare the start and end symbols as variables in some header file).
Even if you don't have access to your source anymore, you can link the object with this option:
gcc -Wl,--defsym,VERSION_1_2_3=0 prog.o -o prog
You can check it with hexdump -C prog | less and look for VERSION
Add this to your makefile and be sure to always know when a program was compiled:
BUILD = $(shell date +"%Y%m%d_%H%M%S")
LDLIBS = -Wl,--defsym,BUILD_$(BUILD)=0
With the GNU linker ld You can use
--version-script=version-scriptfile
Read more about the command-line options at:
Using LD, the GNU linker - Options
Read more about creating version scripts at:
Using LD, the GNU linker - Version Script
Let me warn you though, that it is not for the weak-hearted!
Problem when compiling gcc 4.6.2:
checking for avr-gcc... /data/data6/soft/src_build/gcc-4.6.2/host-x86_64-unknown-linux-gnu/gcc/xgcc -B/data/data6/soft/src_build/gcc-4.6.2/host-x86_64-unknown-linux-gnu/gcc/ -B/data/data6/soft/programming/gcc-avr/avr/bin/ -B/data/data6/soft/programming/gcc-avr/avr/lib/ -isystem /data/data6/soft/programming/gcc-avr/avr/include -isystem /data/data6/soft/programming/gcc-avr/avr/sys-include
checking for suffix of object files... configure: error: in `/data/data6/soft/src_build/gcc-4.6.2/avr/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
In my gcc-4.6.2/avr/libgcc/config.log I found:
configure:3268: /data/data6/soft/src_build/gcc-4.6.2/host-x86_64-unknown-linux-gnu/gcc/xgcc -B/data/data6/soft/src_build/gcc-4.6.2/host-x86_64-unknown-linux-gnu/gcc/ -B/data/data6/soft/programming/gcc-avr/avr/bin/ -B/data/data6/soft/programming/gcc-avr/avr/lib/ -isystem /data/data6/soft/programming/gcc-avr/avr/include -isystem /data/data6/soft/programming/gcc-avr/avr/sys-include -c -g -O2 conftest.c >&5
exec: 89: -o: not found
configure:3272: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3286: error: in `/data/data6/soft/src_build/gcc-4.6.2/avr/libgcc':
configure:3289: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
If this command run directly (after creating conftest.c) output will be same.
What is exec: 89: -o: not found? Which program write it? Where is 89 line?
Solutions like exporting LD_CONFIG_PATH or adding lines in /etc/ld.so.conf with path to GMP, MPFR, MPC not work for me.
Where find solution for this problem?
Update. It seems is configuration problem. Gcc has very good option -v :-) And i see that is assembler call from gcc, which fails. With option -save-temps i saved assembler source, and run assembler, but it doesnn't matter.
Instead of calling real assembler it calls shell-script wrapper, in my case /data/data6/soft/src_build/avr-gcc/gcc/as, which begins from:
ORIGINAL_AS_FOR_TARGET=""
ORIGINAL_LD_FOR_TARGET=""
ORIGINAL_PLUGIN_LD_FOR_TARGET=""
ORIGINAL_NM_FOR_TARGET=""
And when it form command-line call, we have this:
exec -o conftest.o conftest.s
which fails as described above.
Where is necessary fix this? To get call like this:
exec as -o conftest.o conftest.s
Where good place to set variable ORIGINAL_AS_FOR_TARGET?
I had the same problem cross-compiling for mips.
Step one: Cross-compile the binutils for your target. Install them somewhere sane. I use /usr/local/[target]-gcc
Make sure you configure them with --program-prefix=[target]-
Something like (untested):
configure --prefix=/usr/local/avr-gcc --program-prefix=avr- --target=avr
Then you need to set up some environment variables so GCC can find them:
export AR_FOR_TARGET=/usr/local/avr-gcc/bin/avr-ar
export LD_FOR_TARGET=/usr/local/avr-gcc/bin/avr-ld
export OBJDUMP_FOR_TARGET=/usr/local/avr-gcc/bin/avr-objdump
export NM_FOR_TARGET=/usr/local/avr-gcc/bin/avr-nm
export RANLIB_FOR_TARGET=/usr/local/avr-gcc/bin/avr-ranlib
export READELF_FOR_TARGET=/usr/local/avr-gcc/bin/avr-readelf
export STRIP_FOR_TARGET=/usr/local/avr-gcc/bin/avr-strip
export AS_FOR_TARGET=/usr/local/avr-gcc/bin/avr-as
Now you can configure and compile GCC. Ensure you start from a completely empty build directory, otherwise gcc/as etc won't get recreated.
"*Building GCC is not trivial, but is not difficult if you follow the instructions carefully.
Many people rush into trying to build it without reading the installation docs properly and make one or more of these common mistakes:
1) do not run ./configure from gcc src dir (this is not supported) => you need to run configure from outside the gcc source directory
2) Note: if GCC links dynamically to the prerequisite libs (GMP/MPFR/MPC) then the shared libraries must be in the dynamic linker's path (LD_LIBRARY_PATH), both when building gcc and when using the installed compiler.*"
Simple example (without dynamic link to GMP/MPFR/MPC):
tar xzf gcc-4.8.0.tar.gz
cd gcc-4.8.0
./contrib/download_prerequisites
cd ..
mkdir objdir
cd objdir
$PWD/../gcc-4.8.0/configure --prefix=/opt/gcc-4.8.0
make
make install
Sources:
Advogato Doc -
GNU Doc