You are not logged in.
For cross compilers, it would by a lot easier to have one PKGBUILD for each component(binutils, gcc, glibc and linux headers) that can be used to create multiple packages.
But I'm not quite sure if this is a good idea or not. On one hand, it's hell of a lot easier to maintain 5 PKGBUILDs than 5 for each architecture, but I cannot upload them to AUR because --printsrcinfo barfs. Or are there other way of solving this that I haven't found?
In order to build binutils (for instance) I need to do it like this
TARGET=s390x makepkg
Here's a example for binutils
pkgname=$TARGET-binutils
pkgver=2.36.1
pkgrel=2
pkgdesc='A set of programs to assemble and manipulate binary and object files for the ARM64 target'
arch=('arm' 'armv6h' 'armv7h' 'aarch64' 'riscv64' 's390x' 'x86_64')
url='https://www.gnu.org/software/binutils/'
license=(GPL)
depends=(glibc zlib elfutils)
makedepends=(elfutils)
source=(https://ftp.gnu.org/gnu/binutils/binutils-$pkgver.tar.xz{,.sig})
sha256sums=('e81d9edf373f193af428a0f256674aea62a9d74dfe93f65192d4eae030b0f3b0'
'SKIP')
validpgpkeys=('EAF1C276A747E9ED86210CBAC3126D3B4AE55E93' # Tristan Gingold <gingold@adacore.com>
'3A24BC1E8FB409FA9F14371813FCEF89DD9E3C4F') # Nick Clifton (Chief Binutils Maintainer) <nickc@redhat.com>
case $TARGET in
arm) _target=armv5tel-unknown-linux-gnueabi;;
armv6h) _target=armv6l-unknown-linux-gnueabihf;;
armv7h) _target=armv7l-unknown-linux-gnueabihf;;
aarch64) _target=aarch64-unknown-linux-gnu;;
riscv64) _target=riscv64-unknown-linux-gnu;;
s390x) _target=s390x-unknown-linux-gnu;;
"") echo "You must set \$TARGET to a supported target." && exit 1;;
*) echo "$TARGET is not a supported target!" && exit 1;;
esac
prepare() {
#hack - Having CPPFLAGS defined makes the build barf. Workaround it like this:
_cppflags=$CPPFLAGS
CFLAGS="$_cppflags $CFLAGS"
CXXFLAGS="$CFLAGS"
unset CPPFLAGS
}
build() {
cd binutils-$pkgver
./configure --target=$_target \
--with-sysroot=/usr/$_target/sys-root \
--prefix=/usr \
--disable-multilib \
--disable-nls \
--enable-gold \
--enable-plugins \
--enable-deterministic-archives \
--enable-relro \
--with-pic \
--with-system-zlib
make
}
check() {
cd binutils-$pkgver
make
}
package() {
cd binutils-$pkgver
make DESTDIR="$pkgdir" install
# Replace hard links with symlinks
for file in $(ls "$pkgdir"/usr/$_target/bin)
do
rm "$pkgdir"/usr/$_target/bin/$file
ln -sv ../../bin/$_target-$file "$pkgdir"/usr/$_target/bin/$file
done
# Remove file conflicting with host binutils and manpages for MS Windows tools
rm "$pkgdir"/usr/share/man/man1/$_target-{dlltool,windres,windmc}*
# Remove info documents that conflict with host version
rm -r "$pkgdir"/usr/share/info
#Remove .so that conflict with host version
rm -r "$pkgdir"/usr/lib
}
Offline
For cross compilers, it would by a lot easier to have one PKGBUILD for each component(binutils, gcc, glibc and linux headers) that can be used to create multiple packages.
It does seem much simpler to have one package that can handle all arches .
One thing to be careful with is clashes with other env vars, best to use something unique , say SOLSKOGEN-CROSS-COMPILE-TARGET instead of TARGET .
For the pkgname I'd use something unique also , say solskogen-cross-compile-binutils .
That results in one package that can be used for all supported arches .
Whether this is a good idea is another question which I don't have the answer to.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
$TARGET shouldn't be a variable in anybody's environment, so I think that is quite safe. But I see your point.
The wiki quite clearly states that cross compilers should NOT be named cross-*, for reasons I don't agree with. Having a simple name like cross-binutils-$TARGET, and a clear description of what is I think is sufficient. But hey, I've been wrong before and I might be wrong again.
Offline