Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

debug: make valgrind optional, disabled by default, not available for… #924

Merged
merged 2 commits into from
Nov 10, 2016
Merged

debug: make valgrind optional, disabled by default, not available for… #924

merged 2 commits into from
Nov 10, 2016

Conversation

MilhouseVH
Copy link
Contributor

@MilhouseVH MilhouseVH commented Nov 7, 2016

… armv6

Couple of issues now that valgrind is being built by default whenever DEBUG=yes (see #884):

  1. valgrind isn't available for armv6 so RPi1 debug builds will fail: http://sprunge.us/DVQH:
checking for gdb... /usr/bin/gdb
checking dependency style of /home/neil/projects/LibreELEC.tv/build.LibreELEC-RPi.arm-8.0-devel-debug/toolchain/bin/armv6zk-libreelec-linux-gnueabi-gcc... gcc3
checking for diff -u... yes
checking for a supported version of gcc... ok (5.4.0)
checking build system type... x86_64-pc-linux-gnu
checking host system type... armv6zk-libreelec-linux-gnueabi
checking for a supported CPU... no (armv6zk)
configure: error: Unsupported host architecture. Sorry

Building and running valgrind on armv6 probably wouldn't make any sense even if it was supported.

  1. x86 debug builds with valgrind are enormous - too large to install on a standard 512MB FAT system:
-rw-r--r-- 1 neil neil 421052416 Sep 23 23:10 x86-debug/LibreELEC-Generic.x86_64-8.0-devel-20160923224217-#0923g-g8a3b79d.system
-rw-r--r-- 1 neil neil 654532608 Nov  7 21:57 x86-debug/LibreELEC-Generic.x86_64-8.0-devel-20161107194901-#1107-g3f30170.system

We definitely don't want to build with valgrind by default, it should be enabled only when required.

Building valgrind for RPi2 adds about 30MB, which isn't too bad, but should still be included only when required...

-rw-rw-r-- 1 neil neil 334888960 Sep 23 22:44 pi2-debug/LibreELEC-RPi2.arm-8.0-devel-20160923224217-#0923g-g8a3b79d.tar
-rw-rw-r-- 1 neil neil 363704320 Nov  7 21:54 pi2-debug/LibreELEC-RPi2.arm-8.0-devel-20161107194901-#1107-g3f30170.tar

Adding VALGRIND option solves both #1 and #2.

@MilhouseVH
Copy link
Contributor Author

Further investigation suggests the enormous size of Generic debug builds isn't entirely due to valgrind - something else is now causing this. Without valgrind, the debug build reduces in size as follows:

#0923g - last "normal" sized DEBUG=yes build (pre-dates valgrind)
#1107b - DEBUG=yes + VALGRIND=yes
#1107c - DEBUG=yes + VALGRIND=no - shows that valgrind accounts for about 30MB

-rw-r--r-- 1 neil neil 421052416 Sep 23 23:10 LibreELEC-Generic.x86_64-8.0-devel-20160923224217-#0923g-g8a3b79d.system
-rw-r--r-- 1 neil neil 654532608 Nov  7 21:57 LibreELEC-Generic.x86_64-8.0-devel-20161107231103-#1107b-g3f30170.system
-rw-r--r-- 1 neil neil 623652864 Nov  7 23:26 LibreELEC-Generic.x86_64-8.0-devel-20161107232417-#1107c-g3f30170.system

This change is still valid IMHO, however the reason for the huge size increase of Generic debug builds is a cause for concern.

@MilhouseVH
Copy link
Contributor Author

The cause of the bloat when building Generic with debug is libLLVM.so - it's over 0.5GB in debug builds, but only 16MB in non-debug builds.

Debug build (without valgrind):

-rw-r--r-- 1 root root 551419136 Nov  7 23:24 /usr/lib/libLLVM-3.9.so

Non-debug build:

-rw-r--r-- 1 root root 16722176 Nov  7 22:04 /usr/lib/libLLVM-3.9.so

@MilhouseVH
Copy link
Contributor Author

MilhouseVH commented Nov 8, 2016

Added llvm commit to only build llvm with MinSizeRel - this avoids the insane file size:

-rw-r--r-- 1 neil neil 21816704 Nov  8 19:52 libLLVM-3.9.so

@lrusak lrusak merged commit ded08c8 into LibreELEC:master Nov 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants