[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] gcc2.9.3/4.5.0 building using mintlib-19082010
Hello, Matt.
I'm not sure to understand your problems, but I will try to answer.
I'm trying to understand the gcc build process. I have been building sed
4.0.6 (with 1 fail) and sed 3.02 with no trouble, using mintlib-19082010.
The latest sed is 4.2.1. I have cross-built it for MiNT recently without
any trouble and without any additional patch.
Be sure to configure using:
configure --prefix=/usr CFLAGS="-O2 -fomit-frame-pointer -s"
Note the contents of the CFLAGS:
-O2 -fomit-frame-pointer are the best optimization flags for the MiNT
platform.
-s allows to build directly without any debug information (strip will be
unnecessary).
-g is *not* used: thus, the source-level debug info for for gdb will not
be generated, and the optimized MiNTLib will be linked, rather than the
debug one.
This configure command line should be the standard one for all packages
using autoconf/automake. Sometimes, because of imperfections in the
shipped configure files, it requires additional tweaking, especially if
you want to use a cross-compiler.
Does this seem ok that the compiler supplied libraries exist and are
used by compilation, as well as the latest mintlib supplied libraries?
- Can gcc run in a way that it doesn't need its default libraries.. or
am i crazy?
..<snip>..
(../intl/libintl.a)explodename.o <-- from sed
(/d/usr/bin/../lib/gcc/m68k-atari-mint/4.5.0/m68020-60/libgcc.a)__main.o
<-- from gcc 4.5.0
(/e/mintlib-19082010/lib/libc_g.a)globals.o <-- mintlib latest
..<snip>..
(/e/mintlib-19082010/lib/libc_g.a)gmtime.o
(/d/usr/bin/../lib/gcc/m68k-atari-mint/4.5.0/m68020-60/libgcc.a)_udivsi3.o
<-- from gcc 4.5.0 again.
(/d/usr/bin/../lib/gcc/m68k-atari-mint/4.5.0/m68020-60/libgcc.a)_umodsi3.o
(/d/usr/bin/../lib/gcc/m68k-atari-mint/4.5.0/m68020-60/libgcc.a)_mulsi3.o
(/d/usr/bin/../lib/gcc/m68k-atari-mint/4.5.0/m68020-60/libgcc.a)_divsi3.o
(/d/usr/bin/../lib/gcc/m68k-atari-mint/4.5.0/m68020-60/libgcc.a)_modsi3.o
(/d/usr/bin/../lib/gcc/m68k-atari-mint/4.5.0/m68020-60/libgcc.a)fpgnulib.o
(/d/usr/bin/../lib/gcc/m68k-atari-mint/4.5.0/m68020-60/libgcc.a)xfgnulib.o
(/d/usr/bin/../lib/gcc/m68k-atari-mint/4.5.0/m68020-60/libgcc.a)_ltdf2.o
(/d/usr/bin/../lib/gcc/m68k-atari-mint/4.5.0/m68020-60/libgcc.a)_double.o
(/d/usr/bin/../lib/gcc/m68k-atari-mint/4.5.0/m68020-60/libgcc.a)_floatex.o
First I see libc_g.a. Please do *not* link with the -g option if you are
building release software. Of course linking with -g is OK if you want
to compile a debug version and use GDB.
Also, using -g and -m68020-60 is not officially supported, because your
own code will be optimized for 68020-60 while the debug MiNTLib is
optimized for 68000. Mixing the CPU options should always be considered
as a very bad idea (however it should work in most cases - but don't
complain if it doesn't).
Except that, everything is OK.
If I understand well, you are not asking for information about GCC, but
about the linker (ld) behaviour. Basically, you use the gcc command to
link your final executable. You *don't* include the -c option, so it
will generate an executable (rather than a .o file). In this case, the
gcc frontend will not call the compiler (named cc1), it will directly
pass the arguments down to the linker.
Basically, *all* the .o files provided on the linker command line are
linked into the final executable, from left to right. You will always
see them first in the -Wl,-t output. Then there will be some unresolved
externals. The linker will search for the required functions in the
static libraries (.a files) provided on the command line (or implicitly)
from left to right starting *after* the object file having the
unresolved external. So the position of the .a files on the command line
is important. Normally, all the .a files should be located at the end,
sometimes it is necessary to put them several times on the command line
to solve circular reference. When a required symbol is defined in some
.o file inside a .a file, the inner .o file will be linked completely,
but not the other .o files found in the .a file, if they are
unnecessary. In short: when you put .o files on the command line, they
will always be linked into the final executable. When you put .a files
on the command line, they will be partially included in the final
executable: only the required part. Thus, you can link with huge .a
files, your program will not necessarily become huge.
In your example, the following objects are linked:
1) The .o file containing main() (not shown ?). With gcc, main() will
always call the hidden and implicit function __main() to initialize some
global data.
2) The .o files present on the linker command line
3) __main.o from libgcc.a because it contains the implementation of
__main().
4) Most unresolved externals are provided by the MiNTLib (printf(),
strcpy(), etc.)
5) The very low level functions for manipulating 32-bit integers
(udivsi3(), umodsi3(), used implicitly by your program or the MiNTLib)
are linked in.
6) And so on.
There is no mystery in the building process used by GCC.
Don't hesitate to ask if you have further questions.
--
Vincent Rivière