Open dinuxbg opened 8 years ago
Is this something we should be prototyping/testing on https://github.com/beagleboard/repos?
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.
jadonk: In essence we're already using beagleboard/repos for testing :)
Hi, I would like to contribute to this issue.
Switch to quilt 3.0 format? Remove all lintian errors
Could you explain these points
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.
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.
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:
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 )
I will update the issue description.
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.
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.
Cool, I will read about this, and start from next Monday as I have exams right now.
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
PRU simulator must be a separate Debian package. GNU simulator is part of the GDB source release.
./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 .
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
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.
If you think that's too much work, then leave it aside. Simulator is anyway currently used only for running toolchain regression tests.
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:
Separate documentation in separate packages, to address Debian licensing concerns. This is not needed because Binutils and GCC provide decent online documentation.