ar script and bison errors

Nick Burrett nick at dsvr.net
Sun Feb 24 10:16:46 PST 2002


Peter Naulls <peter at chocky.org> writes:

> In message <m33czqddfn.fsf at nick.ws.noc.dsvr.net>
>           Nick Burrett <nick at dsvr.net> wrote:
> 
> > > By the same token, it would be nice if Drlink could understand the Unix
> > > archive format.
> > 
> > I'm not convinced we need this because our userland tools create
> > and work with ALF and AOF files.  If we want Unix archive support then
> > perhaps we should be using ELF objects.
> 
> Unix Archives don't immediately imply ELF format (at least, IMO).
> The point of this is to allow flexibility, and ease of porting.  In many
> cases, the AR tool is configurable, but in some cases it's hardwired to
> ar, which means changing the makefile.

OK. But I don't think we need to support Unix archives to support
`ar' since the majority of its functionality is already supported by
Libfile and it is merely an interface issue.

Creating a binary called `ar' that just takes different arguments to
libfile, but has the libfile backend should suffice, IMHO.
 
> 
> > > Additionally, I'd like to resuggest a patch of Alex's from sometime ago
> > > below.  I've been using this for quite some time, and I think the
> > > hassles of not having it are far more than any perceieved confusion
> > > about filetype naming.
> 
> > I still don't understand the merits of this patch, apart from perhaps
> > in a Unix environment.
> 
> And in the RISC OS enviroment.  In most cases (IME), the library
> filename extension is assumed to be .a, for better or worse in
> Makefiles.

OK. I'll commit it at some point in the near future.

Nick.



More information about the gcc mailing list