dinuxbg / gnupru

GCC and Binutils port for the TI PRU I/O processor
92 stars 11 forks source link

Cleanup the debian packages #20

Open dinuxbg opened 8 years ago

dinuxbg commented 8 years ago

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:

jadonk commented 8 years ago

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

dinuxbg commented 8 years ago

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 commented 8 years ago

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

VedantParanjape commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 #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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

VedantParanjape commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago
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 commented 4 years ago

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.