[hugin-ptx] Re: hugin-0.8.0_rc2 released

2009-06-03 Thread Harry van der Wolf
2009/6/3 Stuart Henderson s...@spacehopper.org


 On 2009-06-01, Bruno Postle br...@postle.net wrote:
 
  * hugin will use system lapack if available.  Note that this is
  experimental, you may find that optimisation is slower than before
  and may even fail.

 On my system (OpenBSD) lapack is detected and used if it's installed,
 but we must also link with libm and libblas, otherwise there are
 unresolved symbols, causing linking of celeste_standalone to fail.



Same on MacOSX (also in the earlier builds after 3880). I thought it had
something to do with MacOSX being a little different than the linuxes and
BSD's around.

The cmake version finds lapack, but the build itself doesn't use it. why?
(still MacOSX being a little different?)
The XCode build just crashed due to the unresolved dependencies.
As we are trying to release a stable 0.8, I disabled the lapack
functionality for OSX as Hugin has functioned correctly very long without
it. So, I decided to postpone it on OSX after the 0.8 release (and yes, I
know, that was not a democratic decision).  That's also why I decided not to
ask Lukas about it as he is busy now with his gsoc project.


Hoi,
Harry

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: hugin-0.8.0_rc2 released

2009-06-03 Thread Lukáš Jirkovský

2009/6/3 Harry van der Wolf hvdw...@gmail.com:


 2009/6/3 Stuart Henderson s...@spacehopper.org

 On 2009-06-01, Bruno Postle br...@postle.net wrote:
 
  * hugin will use system lapack if available.  Note that this is
  experimental, you may find that optimisation is slower than before
  and may even fail.

 On my system (OpenBSD) lapack is detected and used if it's installed,
 but we must also link with libm and libblas, otherwise there are
 unresolved symbols, causing linking of celeste_standalone to fail.


 Same on MacOSX (also in the earlier builds after 3880). I thought it had
 something to do with MacOSX being a little different than the linuxes and
 BSD's around.

 The cmake version finds lapack, but the build itself doesn't use it. why?
 (still MacOSX being a little different?)
 The XCode build just crashed due to the unresolved dependencies.
 As we are trying to release a stable 0.8, I disabled the lapack
 functionality for OSX as Hugin has functioned correctly very long without
 it. So, I decided to postpone it on OSX after the 0.8 release (and yes, I
 know, that was not a democratic decision).  That's also why I decided not to
 ask Lukas about it as he is busy now with his gsoc project.


 Hoi,
 Harry


 


I'll fix that, but probably not until tomorow.

Lukas

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---



[hugin-ptx] Re: hugin-0.8.0_rc2 released

2009-06-03 Thread Lukáš Jirkovský
2009/6/3 Lukáš Jirkovský l.jirkov...@gmail.com:
 2009/6/3 Harry van der Wolf hvdw...@gmail.com:


 2009/6/3 Stuart Henderson s...@spacehopper.org

 On 2009-06-01, Bruno Postle br...@postle.net wrote:
 
  * hugin will use system lapack if available.  Note that this is
  experimental, you may find that optimisation is slower than before
  and may even fail.

 On my system (OpenBSD) lapack is detected and used if it's installed,
 but we must also link with libm and libblas, otherwise there are
 unresolved symbols, causing linking of celeste_standalone to fail.


 Same on MacOSX (also in the earlier builds after 3880). I thought it had
 something to do with MacOSX being a little different than the linuxes and
 BSD's around.

 The cmake version finds lapack, but the build itself doesn't use it. why?
 (still MacOSX being a little different?)
 The XCode build just crashed due to the unresolved dependencies.
 As we are trying to release a stable 0.8, I disabled the lapack
 functionality for OSX as Hugin has functioned correctly very long without
 it. So, I decided to postpone it on OSX after the 0.8 release (and yes, I
 know, that was not a democratic decision).  That's also why I decided not to
 ask Lukas about it as he is busy now with his gsoc project.


 Hoi,
 Harry


 


 I'll fix that, but probably not until tomorow.

 Lukas


Anyway,
I'm not sure if it's necessary to use my module. In fact there's
module called FindLAPACK bundled with CMake, but I've found out that
this one looks also for the fortran compiler which is on all systems
I've tested (unfortunately only Linuxes) not necessary to build it. So
I've made simpler one which looks only for the lapack library.

But from your output it seems that your systems has LAPACK in form of
sources or maybe it's linked differently so it needs Fortran (or g2c
which is Fortran to C translator). Anyway blas really should be part
of dependencies.

Now I'm quite indecisive if I should change the FindLAPACK in hugin in
some way or if I should remove it in favor of the CMake one (but it
results in lapack not found on all systems without Fortran compiler
(and it doesn't find gfortran on my system). All in all when we decide
to keep the FindLAPACK in hugin blas should be added.

I'm not sure if it's possible to determine if the LAPACK library found
by cmake is usable without fortran compiler or not, but it would be
the best solution. For the 0.8 we could simply remove the FindLAPACK
module (it would still use the bundled module), but it would result
that on quite a big number of systems lapack would not be found (but
on the other hand it's better than not-compiable hugin).

Anyway, I've tried to solve it right now (I don't like that I've broke
something so I want to fix it ASAP). Could you please try attached
patch?

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

Index: CMakeModules/FindLAPACK.cmake
===
--- CMakeModules/FindLAPACK.cmake	(revision 3913)
+++ CMakeModules/FindLAPACK.cmake	(working copy)
@@ -7,7 +7,7 @@
 #  LAPACK_LIBRARIES, release link library list.
 #  LAPACK_FOUND, If != YES, do not try to use PANO13.
 
-FIND_LIBRARY(LAPACK_LIBRARIES
+FIND_LIBRARY(LAPACK_LAPACK_LIBRARY
   NAMES lapack
   PATHS /usr/lib
 /usr/local/lib
@@ -15,7 +15,31 @@
 ${SOURCE_BASE_DIR}/lapack
   )
 
-IF(LAPACK_LIBRARIES)
+FIND_LIBRARY(LAPACK_BLAS_LIBRARY
+  NAMES blas
+  PATHS /usr/lib
+/usr/local/lib
+${SOURCE_BASE_DIR}/
+${SOURCE_BASE_DIR}/lapack
+  )
+
+FIND_LIBRARY(LAPACK_G2C_LIBRARY
+  NAMES g2c
+  PATHS /usr/lib
+/usr/local/lib
+${SOURCE_BASE_DIR}/
+${SOURCE_BASE_DIR}/lapack
+  )
+
+IF(LAPACK_LAPACK_LIBRARY)
+  IF(LAPACK_BLAS_LIBRARY)
+SET(LAPACK_LIBRARIES ${LAPACK_BLAS_LIBRARY})
+  ENDIF(LAPACK_BLAS_LIBRARY)
+  IF(LAPACK_G2C_LIBRARY)
+SET(LAPACK_LIBRARIES ${LAPACK_G2C_LIBRARY})
+  ENDIF(LAPACK_G2C_LIBRARY)
+
   SET( LAPACK_FOUND YES )
-ENDIF(LAPACK_LIBRARIES)
+  SET(LAPACK_LIBRARIES ${LAPACK_LAPACK_LIBRARY} ${LAPACK_LIBRARIES})
+ENDIF(LAPACK_LAPACK_LIBRARY)