I think adding a printf() clone to libiberty is WAY overkill just to
silence one failing test.
This is a special case because all the logic has to be done in md5.c
as preprocessor macros. You'd need someone familiar with the platform
(Chris, Danny, Kai) to specify a reliable way to detect that platform
and/or define the types accordingly. If it can typedef md5_uintptr
directly, or use the
> I am on Fedora 7 with autoconf 2.61 with a checkout from
> yesterday off the trunk. So I shouldn't have see it based
> upon that requirement. What else could it be?
Did you re-generate all the configure's from all the configure.ac's?
The ones in CVS are all built with 2.59.
> http://sourceware.org/ml/newlib/2006/msg00472.html
>
> Shouldn't this patch already be in the top level
> gcc/Makefile.in?
The right fix is to use autoconf 2.60 or later.
The patch you link to requires GNU make, and thus was rejected.
> What is the recommended procedure to regenerate them?
Not sure there is one.
> Shouldn't they be regenerated and committed in CVS?
No, because that changes the base requirements for all those packages.
Libiberty should not even try to compile psignal() on djgpp as djgpp
already has one. This is noted in libiberty/configure.ac.
> I found the following patch necessary to build libiberty with newlib
> headers. Although, glibc seems to use the same signature now.
While I'm generally OK with this...
1. The patch is incomplete, as you don't update the documentation to
match the new prototype.
2. GCC patches go to [EMAIL
"olegendo at gcc dot gnu.org" writes:
> I don't know why it was decided to use this ABI. Maybe some legacy
> stuff.
Compatibility with Renesas's compiler.
When reporting DJGPP bugs, please run your app under gdb and use
"where" to get a traceback, or use djgpp's symify (or bfdsymify) to
replace these hex numbers with file/line information. You may need to
compile your application with -g to get symbolic debugging
information.
> Call frame tracebac
> Hello to everyone,
Wrong list. The R8C link scripts are part of newlib (libgloss), not
gcc.
> RESETVEC (r) : ORIGIN = 0xfffc, LENGTH = 4
>
> But this is wrong. The Resetvektor for R8C is only 16Bit and not
> 32bit.
The REJ09B0169-0100 page 61 shows the reset vector as being "0FFFCh to
0FF
10 matches
Mail list logo
