If you are using blitz with egcs under Solaris, SunOS, or OSF/1
you may need to use the gnu linker.

You can download the binutils from ftp://prep.ai.mit.edu/gnu/binutils/

From Peter Nordlund:

My experience with blitz and sun is that you need the gnu linker.
At least I had the same problem, and by using gnu-binutils-2.9.1 I got
it to work.

It can be somewhat tricky to get egcs to use the gnu-linker also.
So how I do it migth not be the only way, but it worked for me.

1. Install binutils-2.9.1
2. Create the bin directory where the egcs compiler will be installed.
3. create links from the linker and assembler to the egcs-bin-dir.
4. configure and install egcs.

See the commands I used below.
---------------------------
mkdir BUILD; cd BUILD
mkdir ../egcs-1.1a/bin
pushd ../egcs-1.1a/bin
ln -s /misc/cvap/gnu/binutils-2.9.1/bin/ld .
ln -s /misc/cvap/gnu/binutils-2.9.1/bin/as .
popd
../src/egcs-1.1a/configure --prefix=/misc/cvap/egcs/egcs-1.1a
--with-gnu-as --with-gnu-ld
make bootstrap-lean ; make install


> I am trying to get blitz++ going on a Sun Ultra-1 running Solaris 5.6.
>
> The compiler is egcs 1.1b.
>
> The make seems to go fine until we get to the examples:
>
> > gmake[1]: Entering directory `/data/gaetz/blitz-19980903/examples'
> > g++  matmult.o -o matmult -L../lib -lblitz -lm
> > ld: warning: relocation error: R_SPARC_32: file matmult.o: symbol __Q25blitz
t13_bz_ArrayExpr1ZQ25blitzt15_bz_ArrayExprOp3ZQ25blitzt13_bz_ArrayExpr1ZQ25blitz
t20_bz_ArrayExprUnaryOp2ZQ25blitzt13_bz_ArrayExpr1ZQ25blitzt15_bz_ArrayExprOp3ZQ
25blitzt21_bz_ArrayExprConstant1ZfZQ25blitzt13_bz_ArrayExpr1ZQ25blitzt20_bz_Arra
yExprUnaryOp2ZQ25blitzt13_bz_ArrayExpr1ZQ25blitzt15_bz_ArrayExprOp3ZQ25blitzt13_
bz_ArrayExpr1ZQ25blitzt20_bz_ArrayExprUnaryOp2ZQ25blitzt13_bz_ArrayExpr1ZQ25blit
zt15_bz_ArrayExprOp3ZQ25blitzt16IndexPlaceholder1i0ZQ25blitzt21_bz_ArrayExprCons
tant1ZfZQ25blitzt8Subtract2ZiZfZQ25blitzt8_bz_pow21ZfZQ25blitzt13_bz_ArrayExpr1Z
Q25blitzt20_bz_ArrayExprUnaryOp2ZQ25blitzt13_bz_ArrayExpr1ZQ25blitzt15_bz_ArrayE
xprOp3ZQ25blitzt16IndexPlaceholder1i1ZQ25blitzt21_bz_ArrayExpr:
> >         external symbolic relocation against non-allocatable section .stab;
> >         cannot be processed at runtime: relocation ignored
> > Undefined                       first referenced
> >  symbol                             in file
> > __Q25blitzt13_bz_ArrayExpr1ZQ25blitzt15_bz_ArrayExprOp3ZQ25blitzt13_bz_Array
Expr1ZQ25blitzt20_bz_ArrayExprUnaryOp2ZQ25blitzt13_bz_ArrayExpr1ZQ25blitzt15_bz_
ArrayExprOp3ZQ25blitzt21_bz_ArrayExprConstant1ZfZQ25blitzt13_bz_ArrayExpr1ZQ25bl
itzt20_bz_ArrayExprUnaryOp2ZQ25blitzt13_bz_ArrayExpr1ZQ25blitzt15_bz_ArrayExprOp
3ZQ25blitzt13_bz_ArrayExpr1ZQ25blitzt20_bz_ArrayExprUnaryOp2ZQ25blitzt13_bz_Arra
yExpr1ZQ25blitzt15_bz_ArrayExprOp3ZQ25blitzt16IndexPlaceholder1i0ZQ25blitzt21_bz
_ArrayExprConstant1ZfZQ25blitzt8Subtract2ZiZfZQ25blitzt8_bz_pow21ZfZQ25blitzt13_
bz_ArrayExpr1ZQ25blitzt20_bz_ArrayExprUnaryOp2ZQ25blitzt13_bz_ArrayExpr1ZQ25blit
zt15_bz_ArrayExprOp3ZQ25blitzt16IndexPlaceholder1i1ZQ25blitzt21_bz_ArrayExpr mat
mult.o
> > ld: fatal: Symbol referencing errors. No output written to matmult
> > collect2: ld returned 1 exit status
> > gmake[1]: *** [matmult] Error 1
>
> What is happening here?  Are there workarounds?

[![Build Status](https://travis-ci.org/blitzpp/blitz.svg?branch=master)](https://travis-ci.org/blitzpp/blitz)
[![Windows Build status](http://ci.appveyor.com/api/projects/status/github/blitzpp/blitz?branch=master&svg=true)](https://ci.appveyor.com/project/blitzpp/blitz/branch/master)

Blitz++ is a C++ template class library that provides high-performance multidimensional array containers
for scientific computing.

Blitz++ has gone through some changes in location:

 1. The original Blitz++ website was located at ``http://oonumerics.org/blitz``
    (archived at http://www.math.unipd.it/~michela/OP.htm).

 2. Blitz++ then moved to SourceForge, at http://www.sourceforge.net/projects/blitz.

 3. The latest maintained version of Blitz++ is now on GitHub, at https://github.com/blitzpp/blitz

Diverse information on Blitz++ is now being catalogued at the GitHub wiki:
http://github.com/blitzpp/blitz/wiki/

Licensing information is detailed in the LEGAL file.
Summary: you can do anything except sell this library in source
form.  Blitz is licensed under either the Lesser GPL version 3 license
(see COPYING and COPYING.LESSER), the BSD license (see COPYRIGHT), and
the less restrictive Perl "artistic license" version 2.0 (see LICENSE).

Installing Blitz
================

We recommend that users consider using Spack to install Blitz++ (see
below; use `spack install blitz`).  For those who enjoy spending hours
upon hours installing software by hand...

Blitz++ is distributed with a GNU Autotools build.  Autotools was
originally developed to address the non-portability of hand-built
Makefiles.  It was a big step forward, and for the first time allowed
users to install programs on their own Unix/Linux system, without too
many hassles due to minor differences between Unices.  While
frequently easy to use for end users, Autotools is also arcane and
difficult to use.  It has since been supplanted by `CMake`, which
offers a somewhat more straightforward way of doing things.  It is our
recommendation that any new projects are produced with CMake builds
--- not Autotools or hand-built Makefiles.  See
[here](https://devmanual.gentoo.org/general-concepts/autotools/index.html)
--- or search around --- for more information on Autotools:

NOTES:

1. Autools-based tarballs are normally distributed with a
`./configure` script.  This is most convenient for the user, since
nothing special must be installed on the system for it to work.
Autotools-based Git repositories normally do *not* contain the
`./configure` script: because that script is a generated file, not an
original source file.  Anyone checking out an Autotools-based project
from a Git repository needs to run `autoreconf` to first generate the
`./configure` file; this is a fundamental fact of life when using
Autotools and Git.  Search around for instructions on how to do so.

Auto-Builders: Spack
=====================

Although Autotools is not in itself particularly difficult to use,
modern open source software stacks frequently require dozens or even
hundreds of packages for a particular project.  Blitz++ does not have
any dependencies, and is therefore pretty "easy" to install; but
typical projects that involve Blitz++ could require the installation
of many more packages.  Installing a dozen or more packages by hand is
slow, error-prone, and must be re-done every time something
foundational changes (compiler or OS version) --- in other words, hand
installation of packages is a waste of time.  Nobody hand-builds
assembly code today either.  Some things are better automated.

[Spack](https://spack.io) is an auto-installer that automates the
installation (and re-installation) of packages.  People have
successfully used it to manage software stacks for particular projects
involving over 100 packages --- which would previously have taken
weeks for one person to complete by hand.  We recommend that people
interested in Blitz++ use Spack for installation, for the following
reaosns:

1. Spack already knows the intricacies of building and installing
software --- including Autotools, Autoreconf, CMake, dependency
management, compiler versions, shared libraries, etc.  This is arcane,
tricky stuff that should not be foisted on everybody just because they
want to use open source software.

1. Spack already knows the package-specific "gotchas" involved in
installing any particular piece of software.  Many packages are quite
standard, and don't require much special knowledge beyond a general
understanding of Autotools or CMake --- but many others have a variety
of "gotchas": they require patches or workardounds for particular
situations, they use standard tools in non-standard ways, they have
bugs that require patching, they involve a one-off hand-built
Makefile; the list goes on.  Every package-specific "gotcha" requires
minutes or hours of effort to understand when installing that package
--- effort that does not help in installing any other package, nor
does it help the next person installing the same package.  This is a
big waste of time.  Spack knows the "gotchas" for each package so you
don't have to.

1. The use of Spack avoides the need for project authors (such as
those at Blitz++) to answer an unending stream of build questions,
almost all of which are entirely generic and have nothing to do with
the actual project.  If Spack fails on a particular package, and then
questions are asked on the Spack forum --- then people who spend every
day on build system minutea will be there to help.

1. Spack recipes provide a clear and concise explanation (in Python
code) of how to install a particular package.  For those who prefer to
continue stone age traditions, inspection of the Spack package will
tell exactly what is required to install a package by hand, including
the package-specific "gotchas."