[arch-general] RFC: Cross compilers using newlib
Hi! Instead of having a separate binutils, gcc and newlib package for every architecture it is possible to combine them into one. You can even build them all in one swoop if you want. For instance, in something like this: _target=m68k-elf _binutilsver=2.28 _gccver=6.3.0 _islver=0.18 _newlibver=2.5.0.20170228 pkgname=${_target}-devkit pkgver=20170320 pkgrel=1 pkgdesc="A combined binutils/gcc/newlib kit for ${_target}" arch=('x86_64') options=('!strip') depends=('gmp' 'mpfr' 'libmpc') url="http://dummy.no" license=('GPL' 'LGPL' 'BSD') source=(binutils-${_binutilsver}.tar.gz gcc-${_gccver}.tar.gz isl-${_islver}.tar.gz newlib-${_newlibver}.tar.gz) md5sums=('d5d270fd0b698ed59ca5ade8e1b5059c' '6e5ea04789678f1250c1b30c4d9ec417' '076c69f81067f2f5b908c099f445a338' '6b7b45ed2280de9196df62511094fc58') prepare() { cd ${srcdir}/gcc-${_gccver} ln -s ../isl-${_islver} isl # Do not run fixincludes sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in # Create a combined source tree for i in bfd binutils gas ld opcodes do ln -s ${srcdir}/binutils-${_binutilsver}/$i done ln -s ${srcdir}/newlib-${_newlibver}/newlib mkdir ${srcdir}/build } build() { #binutils does not compile with the CPPFLAGS in makepkg.conf unset CPPFLAGS cd ${srcdir}/build ${srcdir}/gcc-${_gccver}/configure --prefix=/usr --libexecdir=/usr/lib --target=${_target} --enable-languages=c,c++ --disable-libstdcxx-pch --with-newlib make } package() { cd ${srcdir}/build make install-strip DESTDIR=${pkgdir} rm -rf ${pkgdir}/usr/share rm ${pkgdir}/usr/lib/libcc1* } Is this something that should be done? Or are there good reasons to keep them separate? -- chs
On 03/20/2017 02:51 PM, Christer Solskogen via arch-general wrote:
Hi!
Instead of having a separate binutils, gcc and newlib package for every architecture it is possible to combine them into one. You can even build them all in one swoop if you want. For instance, in something like this:
[snip]
Is this something that should be done? Or are there good reasons to keep them separate?
I guess the main question would be, what benefit do you get out of artificially combining separate source trees for separate projects, with essentially no purpose I can see other than preventing you from updating them individually (a very valid use case). Should we do the same to the packages for your host architecture? ... Generally, suggestions about how to do things differently should be accompanied by some sort of reasoning as to *why* one would want to do whatever-it-is. Especially when that is something which goes against intuitive packaging principles in a very large way. You seem to be taking it for granted, that people will somehow magically agree with you that a unified multi-package is an optimal state of affairs, and are looking to find out if there is any valid defense of the status quo. -- Eli Schwartz
On 20.03.2017 20.48, Eli Schwartz via arch-general wrote:
You seem to be taking it for granted, that people will somehow magically agree with you that a unified multi-package is an optimal state of affairs, and are looking to find out if there is any valid defense of the status quo.
Ah, I wasn't clear about that and thanks for pointing it out. My main reason is that you can build the combo in one swoop, without the need of staging packages like mips64-elf-gcc-stage1 in AUR. And the packages really belong together. I don't quite see the reason for having them in seperate packages as long as they all depend on each other. -- chs
participants (2)
-
Christer Solskogen
-
Eli Schwartz