Build prob on fedora8
mike watson
no longer builds. (Built fine on 7)
Its a wxwidget prob.
[ 61%] Building CXX object
src/hugin1/base_wx/CMakeFiles/huginbasewx.dir/ImageCache.o
/usr/include/wx-2.8/wx/filename.h: In static member function ‘static
wxChar wxFileName::GetPathSeparator(wxPathFormat)’:
/usr/include/wx-2.8/wx/filename.h:393: error: ambiguous overload for
‘operator[]’ in ‘wxFileName::GetPathSeparators(wxPathFormat)()[0u]’
/usr/include/wx-2.8/wx/filename.h:393: note: candidates are:
operator[](const wxChar*, long int) <built-in>
/usr/include/wx-2.8/wx/string.h:822: note: wxChar&
wxString::operator[](int)
/usr/include/wx-2.8/wx/string.h:824: note: wxChar&
wxString::operator[](size_t)
make[2]: ***
[src/hugin1/base_wx/CMakeFiles/huginbasewx.dir/ImageCache.o] Error 1
make[1]: *** [src/hugin1/base_wx/CMakeFiles/huginbasewx.dir/all] Error 2
make: *** [all] Error 2
Installing the 2.6 compatibility libraries and reconfiguring (ccmake is
fantastic!) gives the same error :(
[ 61%] Building CXX object
src/hugin1/base_wx/CMakeFiles/huginbasewx.dir/ImageCache.o
/usr/include/wx-2.6/wx/filename.h: In static member function ‘static
wxChar wxFileName::GetPathSeparator(wxPathFormat)’:
/usr/include/wx-2.6/wx/filename.h:351: error: ambiguous overload for
‘operator[]’ in ‘wxFileName::GetPathSeparators(wxPathFormat)()[0u]’
/usr/include/wx-2.6/wx/filename.h:351: note: candidates are:
operator[](const wxChar*, long int) <built-in>
/usr/include/wx-2.6/wx/string.h:766: note: wxChar&
wxString::operator[](int)
/usr/include/wx-2.6/wx/string.h:768: note: wxChar&
wxString::operator[](size_t)
make[2]: ***
[src/hugin1/base_wx/CMakeFiles/huginbasewx.dir/ImageCache.o] Error 1
make[1]: *** [src/hugin1/base_wx/CMakeFiles/huginbasewx.dir/all] Error 2
make: *** [all] Error 2
Any ideas? I'm stumped when it comes to c++
Thanks.
Bruno Postle
>
>Just built a new fedora 8 (64bit) machine today and hugin from svn now
>no longer builds. (Built fine on 7)
This is a problem with the new wxGTK package being built with
-fno-strict-aliasing:
https://bugzilla.redhat.com/show_bug.cgi?id=295521
There is a quick hack to a wx header file on that page that should
work for you to build hugin.
Though I'm not entirely clear about why this is, I can build hugin
on the fedora build farm, but not locally, and it seems you have the
same problem - Both on x86_64.
>/usr/include/wx-2.8/wx/filename.h:393: error: ambiguous overload for
>‘operator[]’ in ‘wxFileName::GetPathSeparators(wxPathFormat)()[0u]’
--
Bruno
mike watson
Another thing, not all the libraries ended up in the correct place so I
put some links in /usr/lib64 to get it running -
lrwxrwxrwx 1 root root 34 2007-11-11 09:55 libhuginbase.so.0.0 ->
/usr/local/lib/libhuginbase.so.0.0
lrwxrwxrwx 1 root root 35 2007-11-11 09:55 libhuginjhead.so.0.0 ->
/usr/local/lib/libhuginjhead.so.0.0
lrwxrwxrwx 1 root root 40 2007-11-11 09:55 libhuginvigraimpex.so.0.0
-> /usr/local/lib/libhuginvigraimpex.so.0.0
Bruno Postle
>
>Another thing, not all the libraries ended up in the correct place so I
>put some links in /usr/lib64 to get it running -
>
>lrwxrwxrwx 1 root root 34 2007-11-11 09:55 libhuginbase.so.0.0 ->
>/usr/local/lib/libhuginbase.so.0.0
This is a cmake quirk, you have to define LIB_SUFFIX=64, something
like this:
cmake -DLIB_SUFFIX=64
I'm also not sure if fedora will work with libs in /usr/local unless
you set LD_LIBRARY_PATH
--
Bruno
Bruno Postle
>> On Sat 10-Nov-2007 at 17:50 +0000, mike watson wrote:
>>> Just built a new fedora 8 (64bit) machine today and hugin from svn now
>>> no longer builds. (Built fine on 7)
[snip wx fix]
>Thanks Bruno, that seems to have got the build through.
Odd, today I upgraded to fedora 8, also 64bit, and can't get hugin
to build:
cd /home/bruno/rpm/BUILD/hugin-0.7.0/src/hugin_base/test && /usr/bin/c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O2 -g -fPIC "CMakeFiles/open_file.dir/open_file.o" -o open_file -rdynamic -L/home/bruno/rpm/BUILD/hugin-0.7.0/src/hugin_base -L/home/bruno/rpm/BUILD/hugin-0.7.0/src/foreign/jhead -L/home/bruno/rpm/BUILD/hugin-0.7.0/src/foreign/levmar -L/home/bruno/rpm/BUILD/hugin-0.7.0/src/foreign/vigra/vigra_impex -lhuginbase -lhuginjhead -lboost_thread -lpano13 -Wl,-Bstatic -lhuginlevmar -Wl,-Bdynamic -lhuginvigraimpex -lImath -lIlmImf -lIex -lHalf -ljpeg -ltiff -lpng -lz -Wl,-rpath,/home/bruno/rpm/BUILD/hugin-0.7.0/src/hugin_base:/home/bruno/rpm/BUILD/hugin-0.7.0/src/foreign/jhead:/home/bruno/rpm/BUILD/hugin-0.7.0/src/foreign/levmar:/home/bruno/rpm/BUILD/hugin-0.7.0/src/foreign/vigra/vigra_impex
/usr/bin/ld: cannot find -lboost_thread
It seems to be trying to link against libboost_thread, but there is
only libboost_thread-mt in fedora 8:
/usr/lib64/libboost_thread-mt.so.1.34.1
Presumably there is some cmake tweak to get this to work.
--
Bruno
mike watson
libraries to what hugin expected. Quick & dirty I'm afraid..
Bruno Postle
>
>> It seems to be trying to link against libboost_thread, but there is
>> only libboost_thread-mt in fedora 8:
>Oh, I forgot about that... I just quickly setup some links from the -mt
>libraries to what hugin expected. Quick & dirty I'm afraid..
Thanks that's what I needed to know, I need to look at the cmake
stuff because I'm building RPMs.
--
Bruno
Bruno Postle
>
>
>Odd, today I upgraded to fedora 8, also 64bit, and can't get hugin
>to build:
>
>
>It seems to be trying to link against libboost_thread, but there is
>only libboost_thread-mt in fedora 8:
This patch fixes it but I have no idea why, as far as I can tell
this section is Windows specific:
Index: src/CMakeLists.txt
===================================================================
--- src/CMakeLists.txt (revision 2531)
+++ src/CMakeLists.txt (working copy)
@@ -18,7 +18,7 @@
ELSE (WIN32 AND NOT MINGW)
# need to specify boost thread library
set(common_libs huginbase huginjhead
- boost_thread ${PANO_LIBRARIES} huginlevmar)
+ boost_thread-mt ${PANO_LIBRARIES} huginlevmar)
ENDIF (WIN32 AND NOT MINGW)
set(image_libs huginvigraimpex ${OPENEXR_LIBRARIES} ${JPEG_LIBRARIES} ${TIFF_LIBRARIES}
Pablo d'Angelo
In the default boost build, the boost libraries can have very creative
suffixes (including compiler and some compiler flags).
Currently, I'm using the FindBoost macro that comes with CMake, but that
does not check for the right boost threads library name, so I'm just using
boost_thread which seems to work on ubuntu. Obviously the CMake macro needs
to be extended to check for the correct library. Hmm, could become quite
hairy if multiple boost libraries are installed.
ciao
Pablo
Pablo d'Angelo
> Hi Bruno,
>
> Bruno Postle wrote:
>> On Mon 12-Nov-2007 at 17:39 +0000, mike watson wrote:
>>>> It seems to be trying to link against libboost_thread, but there is
>>>> only libboost_thread-mt in fedora 8:
>> Thanks that's what I needed to know, I need to look at the cmake
>> stuff because I'm building RPMs.
>
> In the default boost build, the boost libraries can have very creative
> suffixes (including compiler and some compiler flags).
>
> Currently, I'm using the FindBoost macro that comes with CMake, but that
> does not check for the right boost threads library name, so I'm just using
> boost_thread which seems to work on ubuntu. Obviously the CMake macro needs
> to be extended to check for the correct library. Hmm, could become quite
> hairy if multiple boost libraries are installed.
I have just changed the Boost detection macro to a version that also checks
for the various boost libraries (thread is the only one required right now).
It should now also search for libs with various suffixes such as gcc and mt.
If that still fails, the boost library suffix can be specfied in the cmake
variable Boost_LIB_SUFFIX, for example:
cmake -DBoost_LIB_SUFFIX=gcc41-mt-1_34_1
libboost_thread-gcc41-mt-1_34_1 is the "native" name of the boost thread
library shipped with ubuntu, but the debian (or ubuntu) packagers created
various symlinks, for example to libboost_thread.so
I haven't tested how this affects the MSVC build, but it should still work,
I hope.
ciao
Pablo
Bruno Postle
>
>I have just changed the Boost detection macro to a version that also checks
>for the various boost libraries (thread is the only one required right now).
>It should now also search for libs with various suffixes such as gcc and mt.
Thanks, this fixes the problem on fedora.
--
Bruno