Sorry for not ccing the PerlDl list.. On Wed, Sep 23, 2009 at 3:33 PM, Sisyphus <[email protected]> wrote:
> ----- Original Message ----- From: "Adithya B M" <[email protected]> > >> I got the LAPACK Libraries from here >>> >> http://icl.cs.utk.edu/lapack-for-windows/ >> > Ok - I've just done the same. > I installed the libraries into C:/_32/LAPACK. > And, in C:/_32/LAPACK/lib/win32, I find BLAS.lib, LAPACK.lib, MATGEN.lib > and extras.lib (along with the debug versions of those three libraries). > To build PDL-LinearAlgebra-0.06 all I should have to do is to open up > Complex/Makefile.PL, Real/Makefile.PL and Trans/Makefile.PL and, in each of > those 3 files, change: > $hash{LIBS}[0] .= $^O =~ /MSWin/ ? '' : '-L/usr/lib/atlas -llapack -lblas > -latlas '; > to: > $hash{LIBS}[0] .= $^O =~ /MSWin/ ? '-LC:/_32/LAPACK/lib/win32 -lBLAS > -lLAPACK -lMATGEN -lextras' : '-L/usr/lib/atlas -llapack -lblas -latlas '; > But that's unfortunately not working - 'nmake' terminates with: > ################################### > Creating library ..\blib\arch\auto\PDL\LinearAlgebra\Trans\Trans.lib and > object ..\blib\arch\auto\PDL\LinearAlgebra\Trans\Trans.exp > Trans.obj : error LNK2019: unresolved external symbol _dscal_ referenced in > function _pdl_geexp_readdata > Trans.obj : error LNK2019: unresolved external symbol _dgesv_ referenced in > function _pdl_geexp_readdata > Trans.obj : error LNK2019: unresolved external symbol _daxpy_ referenced in > function _pdl_geexp_readdata > Trans.obj : error LNK2019: unresolved external symbol _dgemm_ referenced in > function _pdl_geexp_readdata > Trans.obj : error LNK2019: unresolved external symbol _dlange_ referenced > in function _pdl_geexp_readdata > Trans.obj : error LNK2019: unresolved external symbol _zdscal_ referenced > in function _pdl_cgeexp_readdata > Trans.obj : error LNK2019: unresolved external symbol _zgesv_ referenced in > function _pdl_cgeexp_readdata > Trans.obj : error LNK2019: unresolved external symbol _zaxpy_ referenced in > function _pdl_cgeexp_readdata > Trans.obj : error LNK2019: unresolved external symbol _zgemm_ referenced in > function _pdl_cgeexp_readdata > Trans.obj : error LNK2019: unresolved external symbol _zlange_ referenced > in function _pdl_cgeexp_readdata > Trans.obj : error LNK2019: unresolved external symbol _zdotu_ referenced in > function _pdl_ctrfun_readdata > ..\blib\arch\auto\PDL\LinearAlgebra\Trans\Trans.dll : fatal error LNK1120: > 11 unresolved externals > NMAKE : fatal error U1077: 'link' : return code '0x460' > Stop. > NMAKE : fatal error U1077: 'C:\vsnet\VC7\BIN\nmake.exe' : return code '0x2' > Stop. > ################################### > Either the libraries are not being found (unlikely), or they don't resolve > the symbols they are expected to resolve. > On further investigation, it looks like the BLAS library we've installed > resolves the symbol (eg) '_DGEMM' but not the symbol '_dgemm_'. And > similarly for the other undefined symbols. > In Trans/trans.pd, if I change every occurrence of 'dgemm_' to 'DGEMM' > then I don't get any error about either '_dgemm_' or '_DGEMM' being > unresolved - but making the same change for the other 10 symbols looks a bit > tedious, methinks :-) > Besides, once I do take care of 'dgemm', I then get (in addition to the 10 > symbols that were not resolved) 3 more unresolved symbols: > BLAS.lib(xerbla.obj) : error LNK2019: unresolved external symbol > _for_write_seq_fmt referenced in function _XERBLA > BLAS.lib(xerbla.obj) : error LNK2019: unresolved external symbol > _for_write_seq_fmt_xmit referenced in function _XERBLA > BLAS.lib(xerbla.obj) : error LNK2019: unresolved external symbol _for_cpstr > referenced in function _XERBLA > These last 3 are unresolved symbols in the BLAS library itself ... I don't > know what needs to be done about them. Maybe I just need to link the > libraries in a different order. (I'm running out of time for tonight.) > You should be able to get to the same stage as I have. I'm stumped as to > why cl.exe is croaking for you, and not even providing a meaningful error > message. Can you build other XS modules using the VC++ Express Edition that > you've installed ? (Try building Math::FFT with it and see if it works ok.) > Looks like we've still got a way to go :-) > I'll have another crack at it tomorrow night. > Cheers, > Rob > > > I found a little more time. > > I ran this script to fix up Trans.pd: > > ##################################### > use warnings; > > open RD, '<', 'trans.pd' or die "RD: $!"; > open WR, '>', 'trans.pd_fixed' or die "WR: $!"; > > while(<RD>) { > $_ =~ s/zdscal_/ZDSCAL/g; > $_ =~ s/zgesv_/ZGESV/g; > $_ =~ s/zaxpy_/ZAXPY/g; > $_ =~ s/zgemm_/ZGEMM/g; > $_ =~ s/zlange_/ZLANGE/g; > $_ =~ s/zdotu_/ZDOTU/g; > $_ =~ s/dscal_/DSCAL/g; > $_ =~ s/dgesv_/DGESV/g; > $_ =~ s/daxpy_/DAXPY/g; > $_ =~ s/dgemm_/DGEMM/g; > $_ =~ s/dlange/DLANGE/g; > > print WR $_; > } > > close RD or die "Close RD: $!"; > close WR or die "Close WR: $!"; > ##################################### > > (Then rename trans.pd to trans.pd_orig and rename trans.pd_fixed to > trans.pd.) > > Running 'nmake' now produces the following errors wrt Trans.c: > > LAPACK.lib(xerbla.obj) : error LNK2019: unresolved external symbol > _for_write_seq_fmt referenced in function _XERBLA > LAPACK.lib(dlamch.obj) : error LNK2001: unresolved external symbol > _for_write_seq_fmt > LAPACK.lib(xerbla.obj) : error LNK2019: unresolved external symbol > _for_write_seq_fmt_xmit referenced in function _XERBLA > LAPACK.lib(xerbla.obj) : error LNK2019: unresolved external symbol > _for_cpstr referenced in function _XERBLA > LAPACK.lib(dlamch.obj) : error LNK2019: unresolved external symbol > ___powr8i4 referenced in function _DLAMCH > ..\blib\arch\auto\PDL\LinearAlgebra\Trans\Trans.dll : fatal error LNK1120: > 4 unresolved externals > NMAKE : fatal error U1077: 'link' : return code '0x460' > Stop. > NMAKE : fatal error U1077: 'C:\vsnet\VC7\BIN\nmake.exe' : return code '0x2' > Stop. > > I tried the /I (ignore) along with nmake and it is not working (obviously) > I'm currently stumped by this ... > Those functions might be resolved by linking to an Intel fortran compiler > library that you have (but I don't). > I have a fortran library(intel) ..still no difference If you had kept cc'ing the list, someone might have been able to chime in > with some help on this. > sorry :3 > > I'll try again tomorrow night. (Googling for powr8i4 might turn up a clue > as to how resolve this and the other symbols.) > > Cheers, > Rob > >
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
