[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