[tlbuild] Solaris fails to process asy's Makefile

[Mojca Miklavec]

On 16 April 2016 at 23:51, Karl Berry wrote:
> Hi Mojca - regarding dynamic libraries.
>
> 1) Could just live with it.  The binaries won't work for everyone, but
> in general we don't try to statically link everything for asy as we do
> for other programs.  My asy for i386-linux links against libstdc++ and
> libgcc dynamically.

But at least it probably links against the system libstdc++. Here
libstdc++ comes from the package manager that just happens to be
installed on the machine.

> 2) That said, try adding -static to the link line to get everything
> linked statically.  I'm not sure if it'll be successful, but it's the
> easiest thing to try.
>
> 3) If you need to break it down, and for background, what we do for TL
> is a hack to link libstdc++ (alone) statically, since we must continue
> to link libc and libm (and fontconfig, etc.)  dynamically.  It boils
> down to a load line like this:
>
> g++ "$@" -nodefaultlibs -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic -lm -lgcc_eh -lgcc -lc -lgcc_eh -lgcc
>
> (It ends up encapsulated in a file CXXLD.sh in the build directory.)
> You could probably do the same -Wl,-Bstatic ... -Wl,-Bdynamic to
> statically link libgcc.

Thank you. The following eventually worked:

/opt/csw/bin/g++-5.2 -Wall -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64
-DUSEGC  -D_REENTRANT -pthreads -DFFTWPP_SINGLE_THREAD -O3 -ansi
-fno-var-tracking -o asy camperror.o path.o drawpath.o drawlabel.o
picture.o psfile.o texfile.o util.o settings.o guide.o flatguide.o
knot.o drawfill.o path3.o drawpath3.o drawsurface.o beziertriangle.o
pen.o pipestream.o types.o builtin.o gsl.o runtime.o runbacktrace.o
runpicture.o runlabel.o runhistory.o runarray.o runfile.o runsystem.o
runpair.o runtriple.o runpath.o runpath3d.o runstring.o runmath.o
env.o genv.o stm.o dec.o errormsg.o callable.o name.o symbol.o entry.o
exp.o newexp.o stack.o camp.tab.o lex.yy.o access.o
virtualfieldaccess.o absyn.o record.o interact.o fileio.o fftw++asy.o
simpson.o coder.o coenv.o impdatum.o locate.o parser.o program.o
application.o varinit.o fundec.o refaccess.o envcompleter.o process.o
constructor.o array.o Delaunay.o predicates.o PRCbitStream.o
oPRCFile.o PRCdouble.o writePRC.o glrender.o tr.o arcball.o algebra3.o
quaternion.o main.o revision.o gc-7.4.2/.libs/libgc.a  -nodefaultlibs
-Wl,-Bstatic -lstdc++ -Wl,-Bdynamic -lnsl -lrt -lz -lm -lgcc_eh -lgcc
-lc

> 4) I don't think an older compiler, per se, would make a difference.
> This basic situation hasn't changed for many years.

It could be that an older compiler would work with the "system
libstdc++". On Mac it does make a difference because newer compilers
no longer work with the system library (on < 10.9) and need a separate
library.

------

One (probably irrelevant) thing. I configured with:

./configure --prefix=/tmp/asyinst --enable-texlive-build --disable-gsl
--disable-fftw --disable-offscreen --disable-gl --disable-readline

and I get:

../asy -dir ../base gsl/*.asy
gsl/random.asy: 7.21: invalid integer
gsl/random.asy: 8.21: invalid integer
gsl/random.asy: 11.21: invalid integer
gsl/random.asy: 15.21: invalid integer
gsl/random.asy: 16.21: invalid integer

That's probably to be expected?

Mojca