Time to stop stripping binaries?

Andreas Tobler andreast-list at fgznet.ch
Sat Jun 19 20:06:41 UTC 2010


On 19.06.10 10:35, Garrett Cooper wrote:
> On Fri, Jun 18, 2010 at 6:17 AM, Kevin Lo<kevlo at freebsd.org>  wrote:
>> Tim Kientzle wrote:
>>> Max Laier wrote:
>>>> On Thursday 17 June 2010 22:33:34 M. Warner Losh wrote:
>>>>>
>>>>> Now that disks are big, can we stop stripping binaries by default?
>>>>>
>>>>> I've worked up a patch that lets you set WITH_BINARY_SYMBOLS or
>>>>> WITHOUT_BINARY_SYMBOLS as you see fit.  We should commit it regardless
>>>>> of the outcome of this discussion (well, defaulting to yes or no
>>>>> depending on the outcome).
>>>>
>>>> My vote is with symbols in current and stable, without in releases - by
>>>> default.  i.e. everything people build at home from an unknown repo state
>>>> should have symbols, everything we "ship" can be reproduced if needed.
>>>
>>> I was going to make this suggestion myself, but Max beat me to it.   ;-)
>>>
>>> Definitely -CURRENT should default to building with
>>> symbols.  I've spent too much time going back to
>>> re-build specific pieces with symbols in order
>>> to debug issues in -CURRENT.
>>>
>>> For releases, I think there's a good argument to
>>> leaving symbols off (CD space is still rather dear).
>>>
>>> For stable, I could go either way.
>>
>> +1. Agreed with Tim :-)
>
>      I agree as well, but I think it should be on for stable because of
> all of the bits being MFCed on a regular basis nowadays from CURRENT,
> and the potential issues that might arise due to less tested
> components (for bug triage purposes).

Fyi, a 8.1-RC1 upgrade to -CURRENT showcase:

I installed 8.1-RC1 image on a t60 with default layout, iow root got 512MB.

Now I tried to update to -CURRENT and failed with the message that / is 
full. (buildkernel/world from source)

I think this was pointed out already, we need to adjust the default 
layout(s)/size of partitions if we are going to do that. (I really like 
to see that happening)

Just my 2Rp.

Andreas


More information about the freebsd-arch mailing list