Cleanup the debian packages

[dinuxbg]

The current debian packages were hastily prepared to allow easy pru-gcc installation from official Beagleboard images. While functional, the packages do not meet many requirements for inclusion into Debian mainline. At least the following fixes are needed:

• Package PRU Simulator from an official GDB source tarball release.
• Separate G++ and Newlib in their own packages. This may or may not be possible, or practical. Probably need to contact Debian Developer lists for help.
• Switch to quilt 3.0 format?
• Remove all lintian errors
• Separate documentation in separate packages, to address Debian licensing concerns. This is not needed because Binutils and GCC provide decent online documentation.
• Include packages into Debian mainline.

[jadonk]

Is this something we should be prototyping/testing on https://github.com/beagleboard/repos?

[dinuxbg]

This particular task outlines what needs to be done for these packages to be accepted into Debian mainline. It doesn't have relation to the Beagleboard Repo.

Robert Nelson has merged the prototype pru-gcc and binutils-pru packages. Although prepared hastily and violating some Debian guidelines, these packages are fully functional. Users of Beagleboard Debian Jessie can start using them now after a simple "apt-get install pru-gcc".

The "Help Wanted" label indicates I'm not currently working on it, so task is free to be grabbed by someone else.

[dinuxbg]

jadonk: In essence we're already using beagleboard/repos for testing :)

[VedantParanjape]

Hi,
I would like to contribute to this issue.

Switch to quilt 3.0 format?
Remove all lintian errors

Could you explain these points

[dinuxbg]

Hi,
I would like to contribute to this issue.

Thank you and welcome aboard!

Switch to quilt 3.0 format?
Remove all lintian errors

Could you explain these points

See https://wiki.debian.org/Projects/DebSrc3.0 . Now that all toolchain components are upstreamed, you can build directly from released GNU tarballs. Hence 3.0 (native) might also work and might be simpler to implement.

[VedantParanjape]

Separate G++ and Newlib in their own packages.

When I checked in rcn-ee's repo, there was a separate package for newlib, is this still valid ? Can you redefine the tasks, as it is a 4 yr old post.

See https://wiki.debian.org/Projects/DebSrc3.0 . Now that all toolchain components are upstreamed, you can build directly from released GNU tarballs. Hence 3.0 (native) might also work and might be simpler to implement.

I will go through this.

[dinuxbg]

Separate G++ and Newlib in their own packages.
When I checked in rcn-ee's repo, there was a separate package for newlib, is this still valid ? Can you redefine the tasks, as it is a 4 yr old post.

I don't see a separate package for newlib.

Cross GCC for most architectures can be built in two phases. This is what gnupru/build.sh does:

1. Build bare GCC C compiler.
2. Use compiler from Signed integer comparison is totally broken #1 to build and install newlib.
3. Rebuild GCC C and C++ frontends using headers and libraries from the newly installed newlib.

I don't know if it is even possible to do the above if newlib and GCC are separate packages. Hence the existing debian packaging rules use the second option (see repos/gcc-pru/generate_source.sh )

1. Combine GCC and newlib sources into a single source tarball. This source tarball will be used for the Debian Package.
2. Build GCC C and C++ and newlib. This is possible because all sources are combined.

I will update the issue description.

[VedantParanjape]

I don't see a separate package for newlib.

Sorry my bad, I mistook it for binutils.

I don't know if it is even possible to do the above if newlib and GCC are separate packages. Hence the existing debian packaging rules use the second option (see repos/gcc-pru/generate_source.sh )

But then how do other toolchains do it ?, say arm-gcc ?

Build GCC C and C++ and newlib. This is possible because all sources are combined

Is it possible to separate them into two diff packages after the build step.

[dinuxbg]

But then how do other toolchains do it ?, say arm-gcc ?

You can find out:

dgit clone gcc-arm-none-eabi
dgit clone newlib

I haven't checked myself.

Is it possible to separate them into two diff packages after the build step.

No. You need one source tarball (perhaps with a bunch of patches applied, if necessary). And you have only one debian/rules description how to build it.

[VedantParanjape]

Cool, I will read about this, and start from next Monday as I have exams right now.

[VedantParanjape]

Package PRU Simulator from an official GDB source tarball release.

How do generate a PRU simulator ?

I looked up this file: https://github.com/rcn-ee/repos/blob/master/gcc-pru/suite/bionic/debian/rules

I think I need to change the target here

TARGET=pru
TARGET_ARCH=pru
PACKAGE=gcc-pru

If not how do I compile the PRU simulator separately ?

https://gcc.gnu.org/simtest-howto.html, I tried doing this, it doesn't list a PRU Simulator

[dinuxbg]

PRU simulator must be a separate Debian package. GNU simulator is part of the GDB source release.

1. Download gdb-9.2.tar.gz from GNU
2. ./configure --target=pru --enable-sim --disable-gdb --prefix=YOUR_INSTALLATION_PATH

If you are interested in PRU simulator for toolchain testing, then take a look at https://github.com/dinuxbg/gnupru/tree/master/testing .

[VedantParanjape]

CONFARGS = -v \
    --enable-languages=c,c++ \
    --with-newlib \
    --prefix=/usr/lib \
    --infodir=/usr/share/info \
    --mandir=/usr/share/man \
	--bindir=/usr/bin \
	--libexecdir=/usr/lib \
	--libdir=/usr/lib \
    --enable-shared \
    --with-system-zlib \
    --enable-long-long \
    --enable-nls \
    --without-included-gettext \
	--disable-libssp \
    --enable-sim \
    --build=$(DEB_BUILD_GNU_TYPE) \
    --host=$(DEB_HOST_GNU_TYPE) \
    --target=$(TARGET) \
    --with-bugurl="https://github.com/dinuxbg/gnupru/issues" \
    $(shell dpkg-buildflags --export=configure | sed -e 's/-Werror=format-security//g')

So, basically I would need to add this to CONFARGS, to generate a debian package with simulator, am I right?

--enable-sim

[dinuxbg]

So, basically I would need to add this to CONFARGS, to generate a debian package with simulator, am I right?

I'm afraid it's much more complicated. If you want to create Simulator Package, then you need to create a brand new Debian package.

1. Copy binutils-pru Debian package.
2. Ensure the following options are set: --target=pru --enable-sim --disable-gdb
3. Modify the debian package to use GDB source release tarball instead of binutils source tarball.
4. Change any "binutils-pru" reference to "pru-sim".

If you think that's too much work, then leave it aside. Simulator is anyway currently used only for running toolchain regression tests.