This is the mail archive of the binutils@sourceware.org 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: Should strip discard the .ctf section ?


Hello,

On Mon, 7 Oct 2019, Orlando Arias wrote:

> The second point is what is important to me. I do not care how small the
> .ctf section is, it is pointless to have in my targets. I do not need
> that information there.

Excellent.  So you won't use -gt to compile your stuff, et voila, no .ctf 
sections anywhere.  Without any changes on your part!

> So you are now forcing me to change my workflow because of what would be
> convenient to you.

Nope.  If you don't change anything in your workflow you never will see 
.ctf sections anywhere, no matter the behaviour of strip.

> And well, you can make the argument that I expect a different type of 
> behavior out of a tool because it is convenient/historical to me. I 
> accept that. However, I will raise my package manager point again. I 
> noted you have a @suse.de e-mail address. I do not mean to sound 
> demeaning/condescending in any way or form, but again, it looks to me 
> like inflexibilities in the way RPM operates may be swaying your 
> choices.

No, I can patch our build system or binutils to have whatever 
behaviour I want.  I merely happen to think that if a user uses -gt to 
compile their sources, and then strip nullifies the effects of -gt by 
default, that this will get me a "huh?" from my users and I prefer to not 
get such response.

> If your packaging tools do not let you choose how you build things, you 
> should probably look at making it more flexible, an action that directly 
> affects you, rather than changing how external tools work, an action 
> that affects everybody.

Noone not using -gt is affected.

In any case, let's see how many bug reports we get about .ctf remaining in 
final objects, we can always reconsider.


Ciao,
Michael.


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