This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: generating debug info for SingleStep Debugger


Peter Steiner wrote:
> 
> On Sat, 04 May 2002 10:04:16 +0300, Kai Ruottu wrote:
> 
> > Peter Steiner wrote:
> >>
> >> I have built a m68k-elf-gcc 2.95.3 (from David Fiddes' patches) and
> >> managed to compile and link a short test program.
> 
> [rest skipped]
> 
> >  Simply don't use Cygwin at all...
> 
> >  The alternative for Cygwin on Win32 hosts is Mingw, which behaves natively
> > using 'd:/directory' in the pathnames. Please see: 'http://www.mingw.org'
> 
> So, if i understood you correctly, i have to build my m68k-elf-gcc using
> mingw and MSYS?

 Using a real Unix or a Unix-like system like Linux, FreeBSD, NetBSD etc. is the
recommendation when trying to build GNU tools because all kind of Unix-tools will
be used during the build. A cross-GCC can produce executables for something else
than the build host, so first having cross-tools (binutils, GCC) for the another
host, one can produce GCCs and binutils to run on the another host... So you can
produce Mingw-hosted tools on any sane Unix-like host.
 
 I myself use Linux (RedHat 7.1 now) with Mingw-target cross-tools for the builds,
because I always want to build the tools for Linux-host too. The Mingw, Solaris2,
DOS/DJGPP2 etc. hosts for which I have cross-tools, are then extra hosts after the
primary Linux...

 Besides the 'native' Windows-hosted Mingw-tools, there should be Linux-hosted
equivalents for download, but most Linux'ists use the Mingw-target as an practice
before building a cross-toolset for Linux and Mingw hosts. Builds on Linux are
easy when compared to builds on Windows, so the need for a prebuilt Linux-x-Mingw
toolset has always been very low... Building tools for the Mingw-target first forces
one to find out its target oddities and later its host oddities, one thing in its
turn...

> I have tried that, could build and install binutils-2.10, but get an
> error while make is trying to link collect2.exe:
> 
>  gcc -DCROSS_COMPILE -DIN_GCC     -g -O2  -DHAVE_CONFIG_H  -o collect2.exe collect2.o tlink.o hash.o intl.o underscore.o version.o  obstack.o       -ladvapi32 ../libiberty/libiberty.a
>  collect2.o: In function `handler':
>  //c/l/gcc-m68k-ps/source/gcc-2.95.3/gcc/collect2.c:527: undefined reference to `kill'
>  collect2.o: In function `scan_prog_file':
>  //c/l/gcc-m68k-ps/source/gcc-2.95.3/gcc/collect2.c:2269: undefined reference to `pipe'
>  //c/l/gcc-m68k-ps/source/gcc-2.95.3/gcc/collect2.c:2292: undefined reference to `fork'
>  make[1]: *** [collect2.exe] Error 1
>  make[1]: Leaving directory `/c/l/gcc-m68k-ps/build/gcc-newlib/gcc'
>  make: *** [all-gcc] Error 2

 This problem has been known for years but not corrected in the FSF-sources... And the
Mingw-config stuff may be misleading...

 The 'collect2' utility hasn't yet fully ported to Mingw-host, but the Mingw-stuff disables
it in the 'gcc/config/i386/t-mingw32' target-makefile-fragment. The right place would
be to create a host-makefile-fragement, 'gcc/config/i386/x-mingw32', this is now missing,
and put the following stuff (in the 't-mingw32' now) there:

----------------------- clip --------------------------------------------
#
# collect2 doesn't work for i386-mingw32* yet.
#
USE_COLLECT2=
----------------------- clip --------------------------------------------

and define the 'x-mingw32' for the Mingw-host in the host/target template in 'gcc/configure'
(2.95.x) or in 'gcc/config.gcc' (3.x).

 Anyway the workaround now is to edit the 'collect2$(exeext)' away from the default lines:
'USE_COLLECT2=collect2$(exeext)' in the configure-produced '$build/gcc/Makefile', so the
lines being like the one in the previous 't-mingw32'...

 The section :

----------------------- clip --------------------------------------------
collect2

GNU CC uses a utility called collect2 on nearly all systems to arrange to call various
initialization functions at start time.

The program collect2 works by linking the program once and looking through the linker
output file for symbols with particular names indicating they are constructor functions.
If it finds any, it creates a new temporary .c file containing a table of them, compiles
it, and links the program a second time including that file.
----------------------- clip --------------------------------------------
(if the Mingw-target-fragment is the right choice, it means that the output from the Win32-
target linker cannot be read, but then also the Cygwin-target would have this same problem)

in the GCC-manual tells about what it does, and I know the '-frepo' for C++ using it,
but whether the Mingw-target will not need it, I'm not so sure... Producing it for the
Mingw-target tools, running on almost anywhere else than on the Mingw-host itself, is
possible, my Linux-hosted Mingw-tools have it after moving the disabling from target to
host... I would assume at least some targets needing it, so getting it working should
have much more importance than the MSYS, for instance... Mumit Khan posted some patches
for 'gcc/collect2.c' on this list a couple of years ago and I checked how the '-frepo'
worked on Mingw-host and it didn't... On Linux-host it seemed to work.

----------------------- clip --------------------------------------------
-frepo
	Enable automatic template instantiation.  This option also implies
	-fno-implicit-templates.  See Template Instantiation, for more information.
----------------------- clip --------------------------------------------

 I'm far from being expert in these C++ things, so someone else could tell us what it
means if the 'collect2' doesn't work and the '-frepo' doesn't work because of this...

> What am I missing?

 A better build-platform than Windoze perhaps.  Reports tell that a 180 MHz PPro with
Linux can be just as slow as a 700-1000 MHz P-III with Windoze/Cygwin in builds...

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]