Re: debug-packages for aarch64?

2020-04-05 Thread Stuart Henderson
On 2020/04/05 16:11, Jeremie Courreges-Anglas wrote:
> On Sat, Apr 04 2020, Stuart Henderson  wrote:
> > I think it would be useful to have debug packages on aarch64.
> > The main bulk build machines are powerful, and most of the machines
> > users are running this on are not, so rebuilding things locally with
> > symbols is quite a pain.
> 
> Indeed rebuilding stuff on a rpi3 or a pinebook looks painful.

exactly.

> Seems safe.  Another concern is the size increase on the mirrors, but
> giving this a try is the easiest way to know for sure.  ok jca@ fwiw

amd64 debug-* are about 2.6G at the moment (down from 2.7G in February;
since then more debug packages have been added but we also have dwz to
shrink them). It will be interesting to see how much bigger the non-debug
packages end up (due to the lack of handling for static libraries) as it
will give a clue how bad that is on amd64 too..

I've discussed offlist with phessler, after the current bulk he's planning
to give his a try with a local diff, and see how it goes before I commit
anything.



Re: debug-packages for aarch64?

2020-04-05 Thread Jeremie Courreges-Anglas
On Sat, Apr 04 2020, Stuart Henderson  wrote:
> I think it would be useful to have debug packages on aarch64.
> The main bulk build machines are powerful, and most of the machines
> users are running this on are not, so rebuilding things locally with
> symbols is quite a pain.

Indeed rebuilding stuff on a rpi3 or a pinebook looks painful.

> They are working OK for me so far (N.B. I have only tested a handful)
> - I was sceptical before I tried (I wasn't sure it had enough of the
> gnu toolchain to handle them) but it's stripping and adding the debug
> links as expected.
>
> Any objections or OKs? (I'll review results from the next bulk and pull
> packages/backout before signing if it looks bad).

Seems safe.  Another concern is the size increase on the mirrors, but
giving this a try is the easiest way to know for sure.  ok jca@ fwiw

>
> Index: arch-defines.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/arch-defines.mk,v
> retrieving revision 1.71
> diff -u -p -r1.71 arch-defines.mk
> --- arch-defines.mk   4 Apr 2020 19:35:44 -   1.71
> +++ arch-defines.mk   4 Apr 2020 21:07:02 -
> @@ -40,7 +40,7 @@ GCC49_ARCHS = aarch64 alpha amd64 arm hp
>  
>  # arches where there is a C++11 compiler, either clang in base or ports-gcc
>  CXX11_ARCHS = ${CLANG_ARCHS} ${GCC49_ARCHS}
> -DEBUGINFO_ARCHS = amd64
> +DEBUGINFO_ARCHS = aarch64 amd64
>  
>  .for PROP in ALL APM BE LE LP64 CLANG GCC4 GCC3 GCC49 MONO LLVM \
>   CXX11 OCAML_NATIVE OCAML_NATIVE_DYNLINK GO \
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: debug-packages for aarch64?

2020-04-04 Thread Kurt Mosiejczuk
On Sat, Apr 04, 2020 at 10:29:36PM +0100, Stuart Henderson wrote:
> I think it would be useful to have debug packages on aarch64.
> The main bulk build machines are powerful, and most of the machines
> users are running this on are not, so rebuilding things locally with
> symbols is quite a pain.

> They are working OK for me so far (N.B. I have only tested a handful)
> - I was sceptical before I tried (I wasn't sure it had enough of the
> gnu toolchain to handle them) but it's stripping and adding the debug
> links as expected.

> Any objections or OKs? (I'll review results from the next bulk and pull
> packages/backout before signing if it looks bad).

Sounds very reasonable. 

ok kmos

--Kurt

> Index: arch-defines.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/arch-defines.mk,v
> retrieving revision 1.71
> diff -u -p -r1.71 arch-defines.mk
> --- arch-defines.mk   4 Apr 2020 19:35:44 -   1.71
> +++ arch-defines.mk   4 Apr 2020 21:07:02 -
> @@ -40,7 +40,7 @@ GCC49_ARCHS = aarch64 alpha amd64 arm hp
>  
>  # arches where there is a C++11 compiler, either clang in base or ports-gcc
>  CXX11_ARCHS = ${CLANG_ARCHS} ${GCC49_ARCHS}
> -DEBUGINFO_ARCHS = amd64
> +DEBUGINFO_ARCHS = aarch64 amd64
>  
>  .for PROP in ALL APM BE LE LP64 CLANG GCC4 GCC3 GCC49 MONO LLVM \
>   CXX11 OCAML_NATIVE OCAML_NATIVE_DYNLINK GO \
>