coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] build: avoid name transformations on libstdbuf


From: Pádraig Brady
Subject: Re: [PATCH] build: avoid name transformations on libstdbuf
Date: Thu, 11 Sep 2014 00:05:43 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 09/10/2014 03:42 PM, Pádraig Brady wrote:
> On 09/10/2014 11:06 AM, Pádraig Brady wrote:
>> * src/local.mk (transform): Skip the transformation for libstdbuf
>> since that should not be subject to name clashes, and we need
>> to reference the name directly in LD_PRELOAD etc.
>> Issue reported at https://trac.macports.org/ticket/44922
>> ---
>>  src/local.mk |    9 ++++++++-
>>  1 files changed, 8 insertions(+), 1 deletions(-)
>>
>> diff --git a/src/local.mk b/src/local.mk
>> index c0d04d6..4ca67ff 100644
>> --- a/src/local.mk
>> +++ b/src/local.mk
>> @@ -340,7 +340,14 @@ copy_sources = \
>>  # confusion with the 'install' target.  The install rule transforms 
>> 'ginstall'
>>  # to install before applying any user-specified name transformations.
>>  
>> -transform = s/ginstall/install/; $(program_transform_name)
>> +# Don't apply prefix transformations to libstdbuf shared lib
>> +# as that's not generally needed, and we need to reference the
>> +# name directly in LD_PRELOAD etc.  In general it's surprising
>> +# that $(transform) is applied to libexec at all given that is
>> +# for internal package naming, not privy to $(transform).
>> +
>> +transform = s/ginstall/install/; /libstdbuf/!$(program_transform_name)
> 
> Nick Bowler suggested the following more robust solution:
> 
>   transform = /libstdbuf/q;s/ginstall/install/;$(program_transform_name)
> 
> Now pushed.

Though in retrospect less appropriate for this case,
as the Makefile uses $(transform) like:

  sed ....s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'

so we don't want transform to break out early
and mess up its other implicit transformations.

Original now pushed instead.

thanks,
Pádraig.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]