This is the mail archive of the
mailing list for the binutils project.
RE: [PATCH] Addition of new option '--rlib' in linker for Renesas SH targets
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Pedro Alves'" <pedro_alves at portugalmail dot pt>, "'Gina Verlekar'" <GinaV at KPITCummins dot com>
- Cc: <binutils at sourceware dot org>
- Date: Thu, 29 Jun 2006 11:36:36 +0100
- Subject: RE: [PATCH] Addition of new option '--rlib' in linker for Renesas SH targets
On 28 June 2006 13:34, Pedro Alves wrote:
> Pedro Alves wrote:
>> Gina Verlekar wrote:
>>> The patch attached herewith adds a new option '--rlib' to the linker.
>>> This patch converts the Renesas library file into a GNU archive with name
>>> <filename>.rlib. This file is created in the same directory as the Renesas
>>> library file. This created GNU archive is then passed to the Linker for
>>> further processing. This option can be used multiple times to link
>>> multiple Renesas SH library
>> If the Renesas library is fully converted into a GNU archive, why isn't
>> this implimented as a separate tool? One that converts the libs only once,
>> and be done with it so the user can use -l normally. You could even
>> integrate the tool into the build system, so it would be transparent like
>> your patches aims at being.
> I took a quick look at the patch, and can't see anything that would
> prevent you
> from splitting process_renesas_library_file into a seperate tool.
> As I understand the patch, process_renesas_library_file function
> extracts the object files of the renesas lib,
> and then you then call create_gnu_archive on the files mimicing what ar
> q does.
> You could instead have (simplified):
> rlibextract $(renesaslib) $(outputdir)
> ar q librenlib.a $(outputdir)/*
> ld $(objects) -lrenlib
> rlibextract being your new tool.
> It would reduce code duplication,
> you would be able to maintain it with a different release cycle from
> *and* it could be used with older binutils versions.
I agree. Cut-n-paste duplication of a huge chunk of ar.c is a bad idea.
Creating and deleting loads of temp files in your system's cross-libs dir is a
bad idea too; who says the user doing the compile would even have write perms
Can't think of a witty .sigline today....