[patch] string cosmetics for SUSV3_LEGACY

[Bernhard Fischer]

On Thu, Jul 06, 2006 at 03:21:47PM +0200, Peter S. Mazinger wrote:
>On Thu, 6 Jul 2006, Bernhard Fischer wrote:
>
>> Hi,
>> 
>> The attached patch makes sure that we do not create empty object files
>> when SUSV3_LEGACY functions are turned off.
>
>We discussed this some time ago and a better/generic solution would be to 
>scan all the produced objects being empty and omit them from the archives.
>We have many other empty objects that depend on a specific syscall 
>being present for example

Do you mean looking at each object if it contained any symbol and else
remove it?
$(NM) $$i | grep -q "^.*$" && echo $$i
for the $^ used for cmd_ar

Perhaps it would be easier to patch ar to drop empty objects..
>> 
>> Ok?
>> 
>> Also, i'd like to know if it is a good idea to provide fallback defines
>> for the bcopy/bzero et al if SUSV3_LEGACY was explicitly turned off?
>
>it does not cost anything to have the macros in headers. the only problem 

I'm not concerned about cost but about ending with functionality
(backward compatibility) that i explicitely did turn off in the .config.

I want packages which still use these legacy funcs to break (or at
least emit a link_warning) if i did turn off legacy support.
E.g. gcc to just name one that i saw which is happy that bzero
and bcopy is still available and uses them due to the fallback defines
being there.

>until now I encountered was the index macro, because some c++ apps used 
>a "local" index and failed (gcc-libstdc++ is one of them)
>
>> I certainly would have expected that these (impls and fallback defines)
>> are _not_ available at all when i turned the option to support them off.
>> 
>> thanks,
>
>My idea was to get an update path that could be used from .28 (not really 
>done though), there are about 50 apps that needed a recompile to get rid 
>of these (and I was lazy to patch all of them)

You should set SUSV3_LEGACY if you don't want to break/patch them :)