This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [RFD] New binutil 'objsplit'
- From: Ian Lance Taylor <ian at wasabisystems dot com>
- To: "E. Weddington" <eric at ecentral dot com>
- Cc: Zack Weinberg <zack at codesourcery dot com>, <binutils at sources dot redhat dot com>
- Date: 21 Apr 2004 16:23:28 -0400
- Subject: Re: [RFD] New binutil 'objsplit'
- References: <408680F8.21416.61CB22A1@localhost>
"E. Weddington" <eric@ecentral.com> writes:
> On 21 Apr 2004 at 12:12, Zack Weinberg wrote:
>
> >> Well, for purposes of building libgcc.a, it would be *so* much simpler
> > if it could be boiled down to
> >
> > ./xgcc -B./ -ffunction-sections -yada -yada libgcc2.c
> > ar cr --split-object libgcc.a libgcc2.o
> >
> > or similar. But this would require us to (a) support
> > -ffunction-sections on all targets, and (b) require binutils on all
> > targets, neither of which things will ever happen
>
> I'm sorry, I'm not familiar with the arguments for either of these.
>
> Could you explain a little further, why not (a), and if GCC is now requiring
> GNU Make, why not, *at some point in the future*, (b)?
(a) is not possible on all targets, since not all object file formats
support multiple sections. (Of course, since operating systems only
care about executables, it would technically be possible to sidestep
this by using a different object file format for object files and
executables, and have the GNU linker fix things up.)
(b) GNU make only has to be written once, and is reasonably portable
with few system dependencies (basically, "get file modification time"
and "execute program"). The binutils have to be written specially for
each supported target, and have many system dependencies. (Of course,
since the above only really requires ar to work, there are fewer
system dependencies than would be required for full assembler and
linker support.)
Ian