#420 PDL-2.016 fails to build on ASperl solaris 32bit or 64bit platforms
With PDL-2.016 building for all the ASperl build systems, I took a look at where the failures are.
Solaris has no successful builds for recent PDL releases.
The 32bit solaris builds fail due to out of memory/time conditions from compiling our large machine generated files. It would be nice to know if the build would succeed if the build machine had more memory or a longer run time limit.
For 64bit solaris, the problem seems to be in inconsistent compiling and linking between the slatec fortran routines and the ld step:
f77 -c -o slatec/xgetua.o -O slatec/xgetua.f
NOTICE: Invoking /opt/SUNWspro/bin/f90 -f77 -ftrap=%none -c -o slatec/xgetua.o -O slatec/xgetua.f
slatec/xgetua.f:
xgetua:
rm -f ../../blib/arch/auto/PDL/Slatec/Slatec.so
LD_RUN_PATH="/opt/SUNWspro/lib" cc -G -xarch=v9 -L/opt/SUNWspro/prod/lib/v9 -L/lib/sparcv9 -L/usr/lib/sparcv9 -L/usr/ccs/lib/sparcv9 Slatec.o slatec/chfcm.o slatec/chfdv.o slatec/chfev.o slatec/chfie.o slatec/d1mach.o slatec/dasum.o slatec/daxpy.o slatec/dchfcm.o slatec/dchfdv.o slatec/dchfev.o slatec/dchfie.o slatec/ddot.o slatec/dgeco.o slatec/dgedi.o slatec/dgefa.o slatec/dgesl.o slatec/dp1vlu.o slatec/dpchbs.o slatec/dpchce.o slatec/dpchci.o slatec/dpchcm.o slatec/dpchcs.o slatec/dpchdf.o slatec/dpchfd.o slatec/dpchfe.o slatec/dpchia.o slatec/dpchic.o slatec/dpchid.o slatec/dpchim.o slatec/dpchkt.o slatec/dpchsp.o slatec/dpchst.o slatec/dpchsw.o slatec/dpcoef.o slatec/dpoco.o slatec/dpodi.o slatec/dpofa.o slatec/dpolft.o slatec/dscal.o slatec/dswap.o slatec/ezfft1.o slatec/ezfftb.o slatec/ezfftf.o slatec/ezffti.o slatec/fdump.o slatec/i1mach.o slatec/idamax.o slatec/isamax.o slatec/j4save.o slatec/pchbs.o slatec/pchce.o slatec/pchci.o slatec/pchcm.o slatec/pchcs.o slatec/pchdf.o slatec/pchfd.o slatec/pchfe.o slatec/pchia.o slatec/pchic.o slatec/pchid.o slatec/pchim.o slatec/pchkt.o slatec/pchsp.o slatec/pchst.o slatec/pchsw.o slatec/pcoef.o slatec/polfit.o slatec/pvalue.o slatec/pythag.o slatec/r1mach.o slatec/radb2.o slatec/radb3.o slatec/radb4.o slatec/radb5.o slatec/radbg.o slatec/radf2.o slatec/radf3.o slatec/radf4.o slatec/radf5.o slatec/radfg.o slatec/rfftb.o slatec/rfftb1.o slatec/rfftf.o slatec/rfftf1.o slatec/rs.o slatec/sasum.o slatec/saxpy.o slatec/sdot.o slatec/sgeco.o slatec/sgedi.o slatec/sgefa.o slatec/sgesl.o slatec/snrm2.o slatec/spoco.o slatec/spodi.o slatec/spofa.o slatec/srot.o slatec/srotg.o slatec/sscal.o slatec/ssvdc.o slatec/sswap.o slatec/tql2.o slatec/tqlrat.o slatec/tred1.o slatec/tred2.o slatec/xerbla.o slatec/xercnt.o slatec/xerhlt.o slatec/xermsg.o slatec/xerprn.o slatec/xersve.o slatec/xgetua.o -o ../../blib/arch/auto/PDL/Slatec/Slatec.so \
-L/opt/SUNWspro/lib -lf77compat -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai -lfminvai -lfmaxvai -lfsu -lsunmath -lm \ld: fatal: file slatec/chfcm.o: wrong ELF class: ELFCLASS32
ld: fatal: File processing errors. No output written to ../../blib/arch/auto/PDL/Slatec/Slatec.so
I believe the issue here is that the ExtUtils::F77 flags for the fortran compiles are not consistent with the flags needed for the 64bit index operation. This should be relatively straightforward to debug and resolve for someone with the ability to compile and test PDL on solaris systems.
This matter will now be tracked at https://github.com/PDLPorters/pdl/issues/220