[Top][All Lists]
[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
- [avr-gcc-list] Reply to E. Weddington ... Building binutils with avr-coff patches,
Haase Bjoern (EW-BEU/PMT) * <=