That's strange. I use the same SDK, as far as I know. The error messages I get are all similar to what I posted above, along the lines of:
huginlevmar.lib(Axb.obj) : error LNK2019: unresolved external symbol _spotf2_ referenced in function _sAx_eq_b_Chol I don't know exactly what all that is, but all those functions sound like linear algebra to me (Chol = Cholesky etc). This, and the fact that Cmake suddenly asked me where the Lapack libraries are, is why I assumed Lapack is the culprit for this. But if Guido can build it without Lapack, I don't know what's going on. On Jun 8, 1:54 pm, Guido Kohlmeyer <[email protected]> wrote: > Just a note: > I built SVN3923 wich is quite the same as RC3 without any problems based > on my SDK, which does not contain any LAPACK lib. > Guido > > Lukáš Jirkovský schrieb: > > > 2009/6/8 Tom Sharpless <[email protected]>: > > >> Hi allard > > >> LAPACK is a FORTRAN package, and Microsoft does not support FORTRAN. > >> On Windows, you have to use CLAPACK, a C version generated largely by > >> automatic translation. CLAPACK still acts like FORTRAN, though, so > >> you need several special headers and libraries to mediate between the > >> C and FORTRAN environments (you also have to get used to 1-origin > >> array indexing). And you need a couple of "blas" libraries that > >> provide the low-level arithmetic routines on which LAPACK depends > >> (typically the blas codes are processor-specific, for speed, but there > >> are generic versions too). > > >> And as with all Windows builds, you have to deal with the fact that > >> you need separate debug and release versions of every library, that > >> must have been built with the same compiler version that builds your > >> app. > > >> So you would have to do a whole lot of preparative work before you > >> could build Hugin with LAPACK on Windows. The resulting gain of > >> optimizer speed would be of little value, since stitching throughput > >> is hardly limited by the optimizer. > > >> So in short, you will be much happier if you build without LAPACK. > > >> Indeed, LAPACK should be removed from Hugin, as it offers only > >> trouble. There are alternative hgih performance Levenberg-Marquardt > >> codes in C++ (for example at AlgLib) if one really needed to tune up > >> the optimizer. > > >> -- Tom > > > Hi, Tom, > > as I've said I've no idea why MSVC requires LAPACK when it's clearly > > optional. Moreover in current svn LAPACK have to be enabled explicitly > > so it will not use LAPACK by default even when there is a LAPACK > > library installed on system. > > > More to the speed. LAPACK is in fact a bit slower on my machine and on > > Bruno's it's much slower. This lead to the disabling the LAPACK by > > default even when there are necessary libraries. > > > I've explained why I've added LAPACK support under the rc2 > > announcement. In short because it gives me a bit better (not so bad as > > without LAPACK) results with one of my test panoramas and doesn't > > change results with the other ones. Moreover it's recommended to use > > LAPACK in LEVMAR because it's more stable than it LU-decomposition or > > whatever it uses. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
