Re: [blfs-dev] About thunderbird build size

2020-04-09 Thread Tim Tassonis via blfs-dev



On 4/9/20 8:08 PM, Bruce Dubbs via blfs-dev wrote:

On 4/9/20 12:46 PM, Tim Tassonis via blfs-dev wrote:



On 4/9/20 7:07 PM, Ken Moffat via blfs-dev wrote:
On Thu, Apr 09, 2020 at 01:23:24PM +0200, Tim Tassonis via blfs-dev 
wrote:

Hi all

I noticed that I do get quite different build sizes for thunderbird 
than
other maintainers, so I thought I will give a few infos about how I 
build

thunderbird. Maybe this helps to find out what's going on here.


Hi Tim,

thanks for providing this information.



du -hs /lgl-bld/thunderbird-68.7.0/


reports

4.2G    /lgl-bld/thunderbird-68.7.0/


So, as I'm doing this with all other packages and never get a 
significant
difference to what's in the book with other packages, I'm pretty 
sure that

my counting isn't the problem.

In my mozconfig, I think I'm doing pretty standard stuff, too. These 
are my

active ac_add_options:


Just for the record, on firefox my own builds use harder CFLAGS etc,
potentially different optimizations, and (while 68-esr lasts) the
patch for system graphite2 and harfbuzz.  But when I measure for the
book I match the book's settings (without the optional patch) and
without my own CFLAGS etc.

So, I don't think that any differences in the mozconfig you are
using will be the cause of this enormous difference in size.


ac_add_options --enable-startup-notification
ac_add_options --disable-pulseaudio
ac_add_options --enable-calendar
ac_add_options --enable-system-sqlite
ac_add_options --with-system-libevent
ac_add_options --with-system-nspr
ac_add_options --with-system-nss
ac_add_options --with-system-icu
ac_add_options --prefix=/opt/thunderbird
ac_add_options --enable-application=comm/mail
ac_add_options --disable-crashreporter
ac_add_options --disable-updater
ac_add_options --disable-debug
ac_add_options --disable-debug-symbols
ac_add_options --disable-tests
ac_add_options --enable-optimize=-O2
ac_add_options --enable-strip
ac_add_options --enable-install-strip
ac_add_options --enable-official-branding
ac_add_options --enable-system-ffi
ac_add_options --enable-system-pixman
ac_add_options --with-system-bz2
ac_add_options --with-system-jpeg
ac_add_options --with-system-png
ac_add_options --with-system-zlib



So, what's left maybe is my toolchain, which might be a bit outdated:

Name : rustc
Version  : 1.42.0-1



I had thought you must be using an older version (back to 1.35 is
probably still usable with 68).


Name : gcc
Version  : 7.3.0-1

Name : clang
Version  : 5.0.1-1



I'm shocked that your versions are so old.



I can of course stop taking tickets for blfs if my toolchain is too 
old for you. I do keep most "upper" stuff quite recent, but I'm quite 
hesitant in updating core stuff such as binutils, compilers and xorg 
libs underneath a whole system, and I don't have the time to fully 
upgrade all my systems every 6 months to keep in sync. So, while all 
"applications" and higher-level libraries are quite new, my core still 
runs on lfs 8.2.


I'm planning to do a full rebuild this year, if time permits, shall I 
refrain from updating stuff until then?


Yes, I think you probably should do that.  I do not update my day-to-day 
system that oftern (maybe once a year), but I think most editors have 
separate development systems that have the latest packages.


Ok. I just bought another 16 GB of RAM for my development server, after 
putting it in I should be able to start a new full build while leaving 
my current system up and running.


Bye
Tim
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


Re: [blfs-dev] About thunderbird build size

2020-04-09 Thread Bruce Dubbs via blfs-dev

On 4/9/20 12:46 PM, Tim Tassonis via blfs-dev wrote:



On 4/9/20 7:07 PM, Ken Moffat via blfs-dev wrote:
On Thu, Apr 09, 2020 at 01:23:24PM +0200, Tim Tassonis via blfs-dev 
wrote:

Hi all

I noticed that I do get quite different build sizes for thunderbird than
other maintainers, so I thought I will give a few infos about how I 
build

thunderbird. Maybe this helps to find out what's going on here.


Hi Tim,

thanks for providing this information.



du -hs /lgl-bld/thunderbird-68.7.0/


reports

4.2G    /lgl-bld/thunderbird-68.7.0/


So, as I'm doing this with all other packages and never get a 
significant
difference to what's in the book with other packages, I'm pretty sure 
that

my counting isn't the problem.

In my mozconfig, I think I'm doing pretty standard stuff, too. These 
are my

active ac_add_options:


Just for the record, on firefox my own builds use harder CFLAGS etc,
potentially different optimizations, and (while 68-esr lasts) the
patch for system graphite2 and harfbuzz.  But when I measure for the
book I match the book's settings (without the optional patch) and
without my own CFLAGS etc.

So, I don't think that any differences in the mozconfig you are
using will be the cause of this enormous difference in size.


ac_add_options --enable-startup-notification
ac_add_options --disable-pulseaudio
ac_add_options --enable-calendar
ac_add_options --enable-system-sqlite
ac_add_options --with-system-libevent
ac_add_options --with-system-nspr
ac_add_options --with-system-nss
ac_add_options --with-system-icu
ac_add_options --prefix=/opt/thunderbird
ac_add_options --enable-application=comm/mail
ac_add_options --disable-crashreporter
ac_add_options --disable-updater
ac_add_options --disable-debug
ac_add_options --disable-debug-symbols
ac_add_options --disable-tests
ac_add_options --enable-optimize=-O2
ac_add_options --enable-strip
ac_add_options --enable-install-strip
ac_add_options --enable-official-branding
ac_add_options --enable-system-ffi
ac_add_options --enable-system-pixman
ac_add_options --with-system-bz2
ac_add_options --with-system-jpeg
ac_add_options --with-system-png
ac_add_options --with-system-zlib



So, what's left maybe is my toolchain, which might be a bit outdated:

Name : rustc
Version  : 1.42.0-1



I had thought you must be using an older version (back to 1.35 is
probably still usable with 68).


Name : gcc
Version  : 7.3.0-1

Name : clang
Version  : 5.0.1-1



I'm shocked that your versions are so old.



I can of course stop taking tickets for blfs if my toolchain is too old 
for you. I do keep most "upper" stuff quite recent, but I'm quite 
hesitant in updating core stuff such as binutils, compilers and xorg 
libs underneath a whole system, and I don't have the time to fully 
upgrade all my systems every 6 months to keep in sync. So, while all 
"applications" and higher-level libraries are quite new, my core still 
runs on lfs 8.2.


I'm planning to do a full rebuild this year, if time permits, shall I 
refrain from updating stuff until then?


Yes, I think you probably should do that.  I do not update my day-to-day 
system that oftern (maybe once a year), but I think most editors have 
separate development systems that have the latest packages.


  -- Bruce

--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


Re: [blfs-dev] About thunderbird build size

2020-04-09 Thread Tim Tassonis via blfs-dev



On 4/9/20 7:07 PM, Ken Moffat via blfs-dev wrote:

On Thu, Apr 09, 2020 at 01:23:24PM +0200, Tim Tassonis via blfs-dev wrote:

Hi all

I noticed that I do get quite different build sizes for thunderbird than
other maintainers, so I thought I will give a few infos about how I build
thunderbird. Maybe this helps to find out what's going on here.


Hi Tim,

thanks for providing this information.



du -hs /lgl-bld/thunderbird-68.7.0/


reports

4.2G/lgl-bld/thunderbird-68.7.0/


So, as I'm doing this with all other packages and never get a significant
difference to what's in the book with other packages, I'm pretty sure that
my counting isn't the problem.

In my mozconfig, I think I'm doing pretty standard stuff, too. These are my
active ac_add_options:


Just for the record, on firefox my own builds use harder CFLAGS etc,
potentially different optimizations, and (while 68-esr lasts) the
patch for system graphite2 and harfbuzz.  But when I measure for the
book I match the book's settings (without the optional patch) and
without my own CFLAGS etc.

So, I don't think that any differences in the mozconfig you are
using will be the cause of this enormous difference in size.


ac_add_options --enable-startup-notification
ac_add_options --disable-pulseaudio
ac_add_options --enable-calendar
ac_add_options --enable-system-sqlite
ac_add_options --with-system-libevent
ac_add_options --with-system-nspr
ac_add_options --with-system-nss
ac_add_options --with-system-icu
ac_add_options --prefix=/opt/thunderbird
ac_add_options --enable-application=comm/mail
ac_add_options --disable-crashreporter
ac_add_options --disable-updater
ac_add_options --disable-debug
ac_add_options --disable-debug-symbols
ac_add_options --disable-tests
ac_add_options --enable-optimize=-O2
ac_add_options --enable-strip
ac_add_options --enable-install-strip
ac_add_options --enable-official-branding
ac_add_options --enable-system-ffi
ac_add_options --enable-system-pixman
ac_add_options --with-system-bz2
ac_add_options --with-system-jpeg
ac_add_options --with-system-png
ac_add_options --with-system-zlib



So, what's left maybe is my toolchain, which might be a bit outdated:

Name : rustc
Version  : 1.42.0-1



I had thought you must be using an older version (back to 1.35 is
probably still usable with 68).


Name : gcc
Version  : 7.3.0-1

Name : clang
Version  : 5.0.1-1



I'm shocked that your versions are so old.



I can of course stop taking tickets for blfs if my toolchain is too old 
for you. I do keep most "upper" stuff quite recent, but I'm quite 
hesitant in updating core stuff such as binutils, compilers and xorg 
libs underneath a whole system, and I don't have the time to fully 
upgrade all my systems every 6 months to keep in sync. So, while all 
"applications" and higher-level libraries are quite new, my core still 
runs on lfs 8.2.


I'm planning to do a full rebuild this year, if time permits, shall I 
refrain from updating stuff until then?



Bye
Tim
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


Re: [blfs-dev] About thunderbird build size

2020-04-09 Thread Ken Moffat via blfs-dev
On Thu, Apr 09, 2020 at 10:58:56AM -0500, Douglas R. Reno via blfs-dev wrote:
> 
> On 4/9/20 6:23 AM, Tim Tassonis via blfs-dev wrote:
> > Hi all
> > 
> > I noticed that I do get quite different build sizes for thunderbird than
> > other maintainers, so I thought I will give a few infos about how I
> > build thunderbird. Maybe this helps to find out what's going on here.
> > 
> > 
> > 
> > du -hs /lgl-bld/thunderbird-68.7.0/
> > 
> > 
> > reports
> > 
> > 4.2G    /lgl-bld/thunderbird-68.7.0/
> > 
> > 
> > So, as I'm doing this with all other packages and never get a
> > significant difference to what's in the book with other packages, I'm
> > pretty sure that my counting isn't the problem.
> > 
> Hi Tim,
> 
> I noticed that you're measuring the install via a DESTDIR (otherwise you
> wouldn't know what the installed files size is - although if you installed
> it in /opt/thunderbird like I see below, it'd be easy to measure it the same
> way). I know that cargo puts files in ~/.cargo, but I'm not sure how much of
> a difference that makes and looking at my script, I normally don't measure
> that either. See below on your package versions
> 

Just a side note that even after wiping ~/.cargo for a 1.42.0 rust
build, and then building the current firefox-68 I didn't see any
change in the overall size of ~/.cargo (measured with du -sch).

> > In my mozconfig, I think I'm doing pretty standard stuff, too. These are
> > my active ac_add_options:
> > 
> > ac_add_options --enable-startup-notification
> > ac_add_options --disable-pulseaudio
> > ac_add_options --enable-calendar
> > ac_add_options --enable-system-sqlite
> > ac_add_options --with-system-libevent
> > ac_add_options --with-system-nspr
> > ac_add_options --with-system-nss
> > ac_add_options --with-system-icu
> > ac_add_options --prefix=/opt/thunderbird
> > ac_add_options --enable-application=comm/mail
> > ac_add_options --disable-crashreporter
> > ac_add_options --disable-updater
> > ac_add_options --disable-debug
> > ac_add_options --disable-debug-symbols
> > ac_add_options --disable-tests
> > ac_add_options --enable-optimize=-O2
> > ac_add_options --enable-strip
> > ac_add_options --enable-install-strip
> > ac_add_options --enable-official-branding
> > ac_add_options --enable-system-ffi
> > ac_add_options --enable-system-pixman
> > ac_add_options --with-system-bz2
> > ac_add_options --with-system-jpeg
> > ac_add_options --with-system-png
> > ac_add_options --with-system-zlib
> > 
> > 
> > 
> > So, what's left maybe is my toolchain, which might be a bit outdated:
> > 
> > Name : rustc
> > Version  : 1.42.0-1
> > 
> > Name : gcc
> > Version  : 7.3.0-1
> > 
> > Name : clang
> > Version  : 5.0.1-1
> > 
> > I suppose I'm building with gcc and not clang, might that make such a
> > huge difference in buildsize?
> > 
> Although that might not make a difference in build size, what might is your
> older package versions. What version of LFS are you building this on? The
> rest of us use 9.1/SVN, and in our case, that means:
> 
> 
> rustc-1.42.0
> 
> gcc-9.3.0
> 
> llvm-10.0.0
> 
> 
> Those packages can all contribute to a large difference in build size. Any
> mismatches in node.js or cbindgen can cause limited problems as well. We've
> been doing updates with GCC-9.3 and LLVM-10 in case we encounter any
> compilation or runtime errors caused by newer compilers. We try to keep all
> of the dependencies for a package on our system up to date before we update
> a package as well.
> 
For firefox-esr I've put the minimal required versions in the wiki
because I know not everyone wants to do major updates every 4 or 6
weeks.  They probably match the minimum versions in thunderbird.
But I assumed everyone was using recent gcc and recent llvm.

ĸen
-- 
The beauty of reading a page of de Selby is that it leads one
inescapably to the conclusion that one is not, of all nincompoops,
the greatest.-- du Garbandier
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


Re: [blfs-dev] About thunderbird build size

2020-04-09 Thread Ken Moffat via blfs-dev
On Thu, Apr 09, 2020 at 01:23:24PM +0200, Tim Tassonis via blfs-dev wrote:
> Hi all
> 
> I noticed that I do get quite different build sizes for thunderbird than
> other maintainers, so I thought I will give a few infos about how I build
> thunderbird. Maybe this helps to find out what's going on here.
> 
Hi Tim,

thanks for providing this information.
> 
> 
> du -hs /lgl-bld/thunderbird-68.7.0/
> 
> 
> reports
> 
> 4.2G  /lgl-bld/thunderbird-68.7.0/
> 
> 
> So, as I'm doing this with all other packages and never get a significant
> difference to what's in the book with other packages, I'm pretty sure that
> my counting isn't the problem.
> 
> In my mozconfig, I think I'm doing pretty standard stuff, too. These are my
> active ac_add_options:

Just for the record, on firefox my own builds use harder CFLAGS etc,
potentially different optimizations, and (while 68-esr lasts) the
patch for system graphite2 and harfbuzz.  But when I measure for the
book I match the book's settings (without the optional patch) and
without my own CFLAGS etc.

So, I don't think that any differences in the mozconfig you are
using will be the cause of this enormous difference in size.
> 
> ac_add_options --enable-startup-notification
> ac_add_options --disable-pulseaudio
> ac_add_options --enable-calendar
> ac_add_options --enable-system-sqlite
> ac_add_options --with-system-libevent
> ac_add_options --with-system-nspr
> ac_add_options --with-system-nss
> ac_add_options --with-system-icu
> ac_add_options --prefix=/opt/thunderbird
> ac_add_options --enable-application=comm/mail
> ac_add_options --disable-crashreporter
> ac_add_options --disable-updater
> ac_add_options --disable-debug
> ac_add_options --disable-debug-symbols
> ac_add_options --disable-tests
> ac_add_options --enable-optimize=-O2
> ac_add_options --enable-strip
> ac_add_options --enable-install-strip
> ac_add_options --enable-official-branding
> ac_add_options --enable-system-ffi
> ac_add_options --enable-system-pixman
> ac_add_options --with-system-bz2
> ac_add_options --with-system-jpeg
> ac_add_options --with-system-png
> ac_add_options --with-system-zlib
> 
> 
> 
> So, what's left maybe is my toolchain, which might be a bit outdated:
> 
> Name : rustc
> Version  : 1.42.0-1
> 

I had thought you must be using an older version (back to 1.35 is
probably still usable with 68).

> Name : gcc
> Version  : 7.3.0-1
> 
> Name : clang
> Version  : 5.0.1-1
> 

I'm shocked that your versions are so old.

> I suppose I'm building with gcc and not clang, might that make such a huge
> difference in buildsize?
> 

In firefox there were past variations, issues with gold, etc and
eventually I got to a point where building with the current gcc
saved a lot of space in the build.

If I used thunderbird other than for testing if we can upgrade rust,
I would have pressed to try moving it to gcc in the belief that
space would be saved.

But I don't think that either gcc-7 or clang-5 are viable choices
nowadays.  Re clang I was going to remove some old coments from my
firefox upgrade script the other day, but decided to keep them. In
the section about upgrading rustc if it was too old (for old LFS
releases I try to keep usable) I note:

 clang-5 was too old to build some past version of rust with
 sysllvm.

 clang-6 and -7 were unreliable with firefox (particularly on my
 4-core ryzen, they tended to fall back to 1 core)

 But all of that is now, for me, ancient history - my oldest system
 is based on LFS-8.3.

 And from that I have scripts to build rustc either with sysllvm or
 with its own shipped llvm.

For your 1.42.0 I assume you are using the shipped llvm.

Overall, I think your main toolchains are the problem.

> 
> Bye
> Tim

ĸen
-- 
The beauty of reading a page of de Selby is that it leads one
inescapably to the conclusion that one is not, of all nincompoops,
the greatest.-- du Garbandier
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


Re: [blfs-dev] About thunderbird build size

2020-04-09 Thread Douglas R. Reno via blfs-dev


On 4/9/20 6:23 AM, Tim Tassonis via blfs-dev wrote:

Hi all

I noticed that I do get quite different build sizes for thunderbird 
than other maintainers, so I thought I will give a few infos about how 
I build thunderbird. Maybe this helps to find out what's going on here.




du -hs /lgl-bld/thunderbird-68.7.0/


reports

4.2G    /lgl-bld/thunderbird-68.7.0/


So, as I'm doing this with all other packages and never get a 
significant difference to what's in the book with other packages, I'm 
pretty sure that my counting isn't the problem.



Hi Tim,

I noticed that you're measuring the install via a DESTDIR (otherwise you 
wouldn't know what the installed files size is - although if you 
installed it in /opt/thunderbird like I see below, it'd be easy to 
measure it the same way). I know that cargo puts files in ~/.cargo, but 
I'm not sure how much of a difference that makes and looking at my 
script, I normally don't measure that either. See below on your package 
versions


In my mozconfig, I think I'm doing pretty standard stuff, too. These 
are my active ac_add_options:


ac_add_options --enable-startup-notification
ac_add_options --disable-pulseaudio
ac_add_options --enable-calendar
ac_add_options --enable-system-sqlite
ac_add_options --with-system-libevent
ac_add_options --with-system-nspr
ac_add_options --with-system-nss
ac_add_options --with-system-icu
ac_add_options --prefix=/opt/thunderbird
ac_add_options --enable-application=comm/mail
ac_add_options --disable-crashreporter
ac_add_options --disable-updater
ac_add_options --disable-debug
ac_add_options --disable-debug-symbols
ac_add_options --disable-tests
ac_add_options --enable-optimize=-O2
ac_add_options --enable-strip
ac_add_options --enable-install-strip
ac_add_options --enable-official-branding
ac_add_options --enable-system-ffi
ac_add_options --enable-system-pixman
ac_add_options --with-system-bz2
ac_add_options --with-system-jpeg
ac_add_options --with-system-png
ac_add_options --with-system-zlib



So, what's left maybe is my toolchain, which might be a bit outdated:

Name : rustc
Version  : 1.42.0-1

Name : gcc
Version  : 7.3.0-1

Name : clang
Version  : 5.0.1-1

I suppose I'm building with gcc and not clang, might that make such a 
huge difference in buildsize?


Although that might not make a difference in build size, what might is 
your older package versions. What version of LFS are you building this 
on? The rest of us use 9.1/SVN, and in our case, that means:



rustc-1.42.0

gcc-9.3.0

llvm-10.0.0


Those packages can all contribute to a large difference in build size. 
Any mismatches in node.js or cbindgen can cause limited problems as 
well. We've been doing updates with GCC-9.3 and LLVM-10 in case we 
encounter any compilation or runtime errors caused by newer compilers. 
We try to keep all of the dependencies for a package on our system up to 
date before we update a package as well.


--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page