avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] Reply to E. Weddington ... Building binutils with avr-co


From: Haase Bjoern (EW-BEU/PMT) *
Subject: [avr-gcc-list] Reply to E. Weddington ... Building binutils with avr-coff patches
Date: Fri, 16 Jan 2004 09:59:58 +0100

Hy,
The problem that I have observed building the patched binutils still persisted
with the patch that you (E. Weddington) have sent me. 
I have, however, figured out *why* I had difficulties to
build the patched binutils. The problem was related to some function
"bu_basename" that was missing when avr-objcopy.exe was supposed to be linked.
The problem with the patch to the 2.14 binutils seems to be related to the
following observations. I am using two seperate directories for the source code 
and for compiling
the code (say source directory and build directory). 
I found that seemingly my build directory contained a different version 
of the file bucomm.c in the binutils-2.14/binutils/ path.
This is what "diff buildirectory/bucomm.c sourcedirectory/bucomm.c"
replies:

470a471,496
> 
> /* Return the basename of "file", i. e. everything minus whatever
> directory part has been provided. Stolen from bfd/archive.c.
> Should we also handle the VMS case (as in bfd/archive.c)? */
> const char \
> *bu_basename (file) \
> const char *file;
> {
> const char *filename = strrchr (file, '/');
> 
> #ifdef HAVE_DOS_BASED_FILE_SYSTEM
> {
> /* We could have foo/bar\\baz, or foo\\bar, or d:bar. */
> char *bslash = strrchr (file, '\\');
> if (filename == NULL || (bslash != NULL && bslash > filename))
> filename = bslash;
> if (filename == NULL && file[0] != '\0' && file[1] == ':')
> filename = file + 1;
> }
> #endif
> if (filename != (char *) NULL)
> filename++;
> else
> filename = file;
> return filename;
> }

It seems that the entire function has been missing in the builddirectory 
version of bucomm.c .
After copying bucomm.c from the source path to the builddirectory
the source compiles without any problem.
It seems that the configure scripts did not correctly transfer 
the files from the source path to the build path. Might be some time
stamp problem existing only on WIN-machines.?.

What I have learned from this is:
After applying patches to the source directory it seems to be helpful
to remove the contents of the build directories completely and
again start the configure script within a virgin build directory.

BTW, the binaries that were generated on my cygwin box are about four times
larger than the files distributed with the WINAVR package! Did they build
the files for another target platform (I used i686-pc-cygwin) or what is
the reason?
Yours,
Björn 
______________________________________________________________________________
Erdbeben im Iran: Zehntausende Kinder brauchen Hilfe. UNICEF hilft den
Kindern - helfen Sie mit! https://www.unicef.de/spe/spe_03.php 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]