synocli-devel: New package - debugging, target python wheel building

[th0ma7]

Description

New package to help debugging including gdb, binutils and LLVM

Checklist

• Build rule all-supported completed successfully
• New installation of package completed successfully
• Package upgrade completed successfully (Manually install the package again)
• Package functionality was tested
• Any needed documentation is updated/created

Type of change

• Bug fix
• New Package
• Package update
• Includes small framework changes
• This change requires a documentation update (e.g. Wiki)

[th0ma7]

@hgy59 just a thought, perhaps the naming could be more generic, such as synocli-debug ... or not. Any thoughts?

[hgy59]

@hgy59 just a thought, perhaps the naming could be more generic, such as synocli-debug ... or not. Any thoughts?

I still have somewhere a synocli-develop package in my mind, see #3253.

And probably you can't remember that the synogear package by synology already provides gdb for DSM https://github.com/SynoCommunity/spksrc/wiki/FAQ-synogear

Ok, gdb by synology is not the newest
on DSM 6.2.4:

# gdb --version
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "aarch64-unknown-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".

Unfortunately on DSM 7.1.0 gdb is missing in synogear.

[th0ma7]

@hgy59 I've now switched the naming of the package to be synocli-devel. I know sometime you're quite good at finding patches for older archs... Having a difficult time compiling older gdb 7.x for qoriq. Honestly getting older gdb to build hasn't been an easy process... Perhaps you may find a cure for that last bit for legacy archs/gcc?

[hgy59]

💯 👍 👍 👍 for the synocli-devel package.
I already created the package icon (but I called it synocli-develop)

[th0ma7]

100 +1 +1 +1 for the synocli-devel package. I already created the package icon (but I called id synocli-develop)

Most linux distribution uses either dev or devel. Would you mind slightly adjusting your proposed icon for that? If it ain't possible I'll simply rename to develop then.

[th0ma7]

@hgy59 any chances you get the icon slightly updated to use devel instead of develop ?

[hgy59]

@hgy59 any chances you get the icon slightly updated to use devel instead of develop ?

no problem to update the icon (but I originally suggested to rename this package to synocli-develop)

[th0ma7]

On most linux distributions the -devel is being used. I thought it may be best to align using that standard? If you have a strong preference towards develop, fine by me.

[th0ma7]

no problem to update the icon (but I originally suggested to rename this package to synocli-develop)

@hgy59 I believe I may have rebased against master then forced push and forgot to pull your icon commit first... sorry. Would you still have the icon close by? 🤷

[hgy59]

no problem to update the icon (but I originally suggested to rename this package to synocli-develop)

@hgy59 I believe I may have rebased against master then forced push and forgot to pull your icon commit first... sorry. Would you still have the icon close by? 🤷

[th0ma7]

@hgy59 good news! I finally got a working LLVM and in extra I believe I may have found a workaround to enable building gcc as well (code not uploaded yet, stabilizing llvm first). Currently the github-action build output won't work as the toolchain is being cached online and won't apply the small patch for compiling to work out (due to caching).

Currently everything is redirected to llvm-9.0 until I confirm a few more details and try out again building for armv5 and qoriq (full builds take 4h to get through on my 6x core AMD). Once the last details are solved I'll redirect gcc-7.5+ builds to llvm-latest, then next will be gcc which should make this package way more interesting, and opening new options.

So I thought I'd share as this is a great milestone.

PS: comcerto2k and hi3535 fails due to ASM when building compiler-rt (which is now set off for these specifically). Tricks on what to pass to the as compiler welcomed if you have any. Cheers!

[th0ma7]

@hgy59 I have a plan to propose for this development package... Not everything needs to be included at first but here are some thoughts:

1. complete LLVM to provide latest version for DSM7 gcc-7/8.5+
2. prepare LLVM to build SPIRV for GPU acceleration (probably later part of future FFMPEG)
3. provide gcc (I believe I can now build it in full, to confirm)
4. provide autotools + pkg-config
5. provide an environment script similar to tc_vars.mk pointing towards binutils/gcc/autotools/etc that can then be used by other packages
6. look into installing rustc as well, through service-setup script perhaps?
7. create a python package to test build python wheels locally on the target.... which would solve homeassistant issue faced earlier this week for instance.

I'm aiming towards item 1-3-4 for the initial package (which may take a few more weeks). Help welcomed. What do you think?

[hgy59]

@th0ma7 I already included gnu make in 2020 in my local work (current version is 4.4.1 of 2023-02-26)
would be great to include this (just saw that you added the autotools)

PKG_NAME = make
PKG_VERS = 4.3
PKG_EXT = tar.lz
PKG_DIST_NAME = $(PKG_NAME)-$(PKG_VERS).$(PKG_EXT)
PKG_DIST_SITE = https://ftp.gnu.org/gnu/make
PKG_DIR = $(PKG_NAME)-$(PKG_VERS)

DEPENDS =

HOMEPAGE = https://www.gnu.org/software/make/
COMMENT  = GNU Make is a tool which controls the generation of executables and other non-source files of a program from the program's source files. 
LICENSE  = GPLv2

GNU_CONFIGURE = 1

include ../../mk/spksrc.cross-cc.mk

[th0ma7]

Besides testing and most importantly getting gcc in, I'm finally nearing the finish line. One thing to note is that resulting packages are huges... :

$ du -h synocli-devel_*
87M	synocli-devel_aarch64-6.1_1.0-1.spk
142M	synocli-devel_aarch64-7.1_1.0-1.spk
53M	synocli-devel_armv7-6.1_1.0-1.spk
85M	synocli-devel_armv7-7.1_1.0-1.spk
51M	synocli-devel_comcerto2k-7.1_1.0-1.spk
78M	synocli-devel_evansport-6.1_1.0-1.spk
119M	synocli-devel_evansport-7.1_1.0-1.spk
53M	synocli-devel_hi3535-6.1_1.0-1.spk
94M	synocli-devel_x64-6.1_1.0-1.spk
156M	synocli-devel_x64-7.1_1.0-1.spk

@hgy59 when you have a moment can you have a look at it and test this on your end to confirm there isn't any loose pieces up to now? I haven't tested the full build with pkg-config but all was ok until that point.

[th0ma7]

@hgy59 I'm now considering releasing as is due to my inhability to cross-compile gcc. Besides a few clean-ups and testing, anything you find missing (that couldn't wait until a future update)?