This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFD] New binutil 'objsplit'


"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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]