Updates on the -fpic bug:
Satoshi has been so kind to point me to the ports build logs. Out of
1672 files compiled with -fpic, 1033 of them with -O1, none triggered
the assembler warning message.
I would now feel reasonably comfortable to resolve the issue for
Release 4.0 by :
- committing Bruc
In <[EMAIL PROTECTED]>, Bruce Evans wrote:
> On Fri, 25 Feb 2000, Martin Cracauer wrote:
> > It is possible that we indroduced the bug by our profiling changes?
> > The line in i386.c that generates the code in question is from
> > revision 1.5, which is the profiling delta from the original gcc.
On Fri, 25 Feb 2000, Martin Cracauer wrote:
> It is also not clear to me that the new assembler really fixes the
> bug. While I cannot judge over the correctness of the syntax, I think
> it is possible that the new assembler still works on the same syntax,
> not recognizing the parameterless GOTO
In <[EMAIL PROTECTED]>, David O'Brien wrote:
> On Wed, Feb 23, 2000 at 02:31:01PM +0100, Martin Cracauer wrote:
> > Where's the bug, anyway? Do we need to fix the compiler or would it be
> > better to get a newer assembler?
>
> A new assembler (whole binutils) is on the way, probably around the
hi, there!
On Thu, 24 Feb 2000, David O'Brien wrote:
> On Wed, Feb 23, 2000 at 02:31:01PM +0100, Martin Cracauer wrote:
> > Where's the bug, anyway? Do we need to fix the compiler or would it be
> > better to get a newer assembler?
>
> A new assembler (whole binutils) is on the way, probably ar
On Wed, Feb 23, 2000 at 02:31:01PM +0100, Martin Cracauer wrote:
> Where's the bug, anyway? Do we need to fix the compiler or would it be
> better to get a newer assembler?
A new assembler (whole binutils) is on the way, probably around the end
of March.
--
-- David([EMAIL PROTECTED])
To
In <[EMAIL PROTECTED]>, Bruce Evans wrote:
> diff -c2 localtime.c~ localtime.c
> *** localtime.c~ Fri Jan 28 17:29:18 2000
> --- localtime.c Wed Feb 23 22:51:34 2000
> ***
> *** 220,224
> settzname P((void))
> {
> ! register struct state * const sp = lclptr;
On Wed, 23 Feb 2000, Martin Cracauer wrote:
> cc -fpic -DPIC -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include
>-D__DBINTERFACE_PRIVATE -DINET6 -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale
>-DBROKEN_DES -DYP -I/usr/obj/usr/src/i386/usr/include -c
>/usr/src/lib/libc/../libc/st
[CC'ed David, since the new compiler seems to cause the problems]
Sorry for the update bombing, but I found that the file where the
tzname symbol is being defined in triggers this error mesage in a
`make world`:
cc -fpic -DPIC -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include
-D__DB
Updates on the "moving" symbols problem:
The problem with gdb not finding out the type of tzname[] is caused by
the shared libs not being built with -g. It probably doesn't have to
do with the problem.
I appended a tarfile with some test cases. Case 1-3 show different
occasions of the error, all
I am trying to hunt the strptime(..., "%+", ...) bug down. It looks
like a showstopper dynamic linker bug in 4.0 now. I suspect that
extern variables located in shared variables are broken, either by a
ld.so or a mmap bug.
In a dynamically linked program, it looks like the address of the
symbol "
11 matches
Mail list logo
