This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Binutils on 4.2
- To: Scott Cranston <scranston at ironstream dot com>
- Subject: Binutils on 4.2
- From: Steve Gonczi <Steve dot Gonczi at networkengines dot com>
- Date: Mon, 26 Feb 2001 11:40:58 -0500
- cc: "'binutils at sources dot redhat dot com'" <binutils at sources dot redhat dot com>
Greetings,
I have managed to compile binutils 2.10.1 on BSDI 4.2.
(I am after this, in the hope that I can get a working gprof out of it, that
would let me
profile forked processes).
If anyone is interested, I would be glad to post my patches.
I have ended up with a binutils package that only supports the i386bsd
format.
( The 2.9.1 binutils that comes with BSDI 4.2 supports elf_i386, i386bsdi
and i386coff).
Does anyone have a suggestion what configuration options to use for 2.10.1?
to get
elf and coff support?
Also: I am thinking about porting the "latest" glibc. This has some
debug/profiling hooks
that another profiling package needs. I am talking about __malloc_hook,
__realloc_hook
and __free_hook.
These are missing from all of the stock BSD 4.2 libraries. They are supposed
to be in
libc.
Is using a current, GNU glibc instead of the shipping BDSI libc a realistic
goal?
/sG
Greetings,
I have managed to
compile binutils 2.10.1 on BSDI 4.2.
(I am after this, in
the hope that I can get a working gprof out of it, that would let
me
profile forked
processes).
If anyone is
interested, I would be glad to post my patches.
I have ended up with
a binutils package that only supports the
i386bsd format.
( The 2.9.1 binutils
that comes with BSDI 4.2 supports elf_i386, i386bsdi and
i386coff).
Does anyone have a
suggestion what configuration options to use for 2.10.1? to
get
elf and coff
support?
Also: I am thinking
about porting the "latest" glibc. This has some debug/profiling
hooks
that another
profiling package needs. I am talking about __malloc_hook,
__realloc_hook
and
__free_hook.
These are missing
from all of the stock BSD 4.2 libraries. They are supposed to be
in
libc.
Is using a current,
GNU glibc instead of the shipping BDSI libc a realistic
goal?
/sG