Re: [MiNT] gcc2.9.3/4.5.0 building using mintlib-19082010

> Date: Sat, 21 Aug 2010 19:59:11 +0200
> From: vincent.riviere@freesbee.fr
> To: mint@lists.fishpool.fi
> Subject: 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
>
>