Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Bountysource campaign for gcc-vax



Hi,

Thank you for this. I don't have much time to give this as much attention as it deserves, so this is the perfect amount of a how-to to at least get started. I'll give it a go, hopefully some time this week.

-j 64? Must be nice ;) For NetBSD you can use `sysctl -n hw.ncpu`.

Thanks!
John Klos




One option is to build a cross toolchain via the standard gcc procedure
on the build machine, targetting VAX. Then copy over all created binaries
(e.g. to /usr/local/) and play with them manually to verify they work for
simple programs. When that works, set CC (and maybe AS, LD, ...) in the
environment and build a kernel (this still works the old way, with config
and make, you may have to additionally set USE_TOOLS=never).

Umm, not targetting, but hosting VAX (i.e. cross-build native GCC).  As I
noted previously you need to do that in three steps on your non-VAX system
(I suggest choosing a mighty one as otherwise it'll take a while, and make
sure you run parallel builds if SMP):

1. Build native GCC 11, e.g.:

$ cd /path/to/gcc-src
$ contrib/download_prerequisites
$ mkdir -p $HOME/vax/native-gcc
$ cd $HOME/vax/native-gcc
$ /path/to/gcc-src/configure --disable-nls \
	--disable-version-specific-runtime-libs --enable-languages=c,c++ \
	--prefix=/usr
$ gmake -j 64 bootstrap
$ gmake DESTDIR=$HOME/vax/install install

2. Install VAX headers and libraries in the intended sysroot, e.g.:

$ mkdir -p $HOME/vax/install/usr/sysroot
$ cd $HOME/vax/install/usr/sysroot
$ ssh vax 'tar -ch lib/libc.so* lib/libm.so* libpthread.so*
	libexec/ld.elf_so usr/include usr/lib/*crt?.o
	usr/lib/lib[cm][._]* usr/lib/libposix[._]*
	usr/lib/libpthread[._]* usr/libexec/ld.elf_so' | tar -xp

(this needs to dereference symlinks as some are absolute and therefore
won't work when copied over; you can recreate them as relative ones by
hand instead if you so prefer).

3. Build VAX binutils 2.36.1 and GCC 11 (using the newly-built native
  compiler), e.g.:

$ export PATH=$HOME/vax/install/bin:$PATH
$ export LD_LIBRARY_PATH=$HOME/vax/install/lib
$ mkdir -p $HOME/vax/vax-binutils
$ cd $HOME/vax/vax-binutils
$ /path/to/binutils-src/configure --disable-gdb --disable-gdbserver \
	--disable-libdecnumber --disable-readline --disable-sim \
	--with-sysroot=/usr/sysroot --target=vax-netbsdelf
$ gmake -j 64
$ gmake DESTDIR=$HOME/vax/install install
$ mkdir -p $HOME/vax/vax-gcc
$ cd $HOME/vax/vax-gcc
$ /path/to/gcc-src/configure --disable-nls \
	--disable-version-specific-runtime-libs --enable-languages=c,c++ \
	--with-build-sysroot=$HOME/vax/install/usr/sysroot \
	--with-sysroot=/usr/sysroot --prefix=/usr \
	--with-toolexeclibdir=/usr/sysroot/usr/lib --target=vax-netbsdelf
$ gmake -j 64
$ gmake DESTDIR=$HOME/vax/install install

4. Build native VAX GCC 11 (using the newly-built VAX binutils and GCC),
  e.g.:

$ export PATH=$HOME/vax/install/bin:$PATH
$ export LD_LIBRARY_PATH=$HOME/vax/install/lib
$ mkdir -p $HOME/vax/vax-native-gcc
$ cd $HOME/vax/vax-native-gcc
$ /path/to/gcc-src/configure --disable-nls \
	--disable-version-specific-runtime-libs --enable-languages=c,c++ \
	--prefix=/usr --host=vax-netbsdelf
$ gmake -j 64
$ gmake DESTDIR=$HOME/vax/install/usr/sysroot install

5. And then either copy $HOME/vax/install/usr/sysroot over to your VAX
  system somewhere or just export the directory over NFS as I previously
  suggested (in which case you won't ever get caught by using a stale
  copy by accident as you iterate over the process).

Substitute `64' with the number of processors in the non-VAX machine (for
Linux I use `$(nproc)', but I don't know what's the NetBSD's equivalent),
and `$HOME/vax' with whatever is convenient.  Apologies for any bash-isms
above (hopefully trivially resolved), and if anything above does not work
right away and tweaks are required (hopefully minor).

NB it could be easier and maybe more reliable to set PATH on the VAX
system so that the new tools are found first rather than tweaking CC, CXX,
etc. individually.  I'd normally only override CC, CXX, etc. if options
are required to configure the compilation correctly, such as to select a
non-default multilib (ordinary user flags go into CFLAGS, CXXFLAGS, etc.).

HTH,

 Maciej



Home | Main Index | Thread Index | Old Index