Discussion:
RFC: Cross compilers using newlib
(too old to reply)
Christer Solskogen via arch-general
2017-03-20 18:51:05 UTC
Permalink
Raw Message
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
Eli Schwartz via arch-general
2017-03-20 19:48:24 UTC
Permalink
Raw Message
Post by Christer Solskogen via arch-general
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
[snip]
Post by Christer Solskogen via arch-general
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
Christer Solskogen via arch-general
2017-03-21 07:07:57 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
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
Loading...