Open CASCADE, the 3D modelling kernel
3D modeling & numerical simulation

Search the Forums
See All Topics
 

Can't configire/compile Open Cascade for Fedora 15

Can't configire/compile Open Cascade for Fedora 15
Richard Burton 2011/09/12 06:46
checking X11/extensions/transovl.h usability... no
checking X11/extensions/transovl.h presence... no
checking for X11/extensions/transovl.h... no
checking X11/extensions/readdisplay.h usability... no
checking X11/extensions/readdisplay.h presence... no
checking for X11/extensions/readdisplay.h... no
checking X11/extensions/multibuf.h usability... no
checking X11/extensions/multibuf.h presence... yes
configure: WARNING: X11/extensions/multibuf.h: present but cannot be compiled
configure: WARNING: X11/extensions/multibuf.h: check for missing prerequisite headers?
configure: WARNING: X11/extensions/multibuf.h: proceeding with the preprocessor's result
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: ## Report this to bug-autoconf@gnu.org. ##
configure: WARNING: ## ------------------------------------ ##
checking for X11/extensions/multibuf.h... yes



installed autoconf after this and got the following:

checking X11/extensions/transovl.h usability... no
checking X11/extensions/transovl.h presence... no
checking for X11/extensions/transovl.h... no
checking X11/extensions/readdisplay.h usability... no
checking X11/extensions/readdisplay.h presence... no
checking for X11/extensions/readdisplay.h... no
checking X11/extensions/multibuf.h usability... no
checking X11/extensions/multibuf.h presence... yes
configure: WARNING: X11/extensions/multibuf.h: present but cannot be compiled
configure: WARNING: X11/extensions/multibuf.h: check for missing prerequisite headers?
configure: WARNING: X11/extensions/multibuf.h: see the Autoconf documentation
configure: WARNING: X11/extensions/multibuf.h: section "Present But Cannot Be Compiled"
configure: WARNING: X11/extensions/multibuf.h: proceeding with the compiler's result

Denis Barbier 2011/09/12 07:47
Hello,

You can find a patch at
http://anonscm.debian.org/gitweb/?p=debian-science/packages/opencascade.git;a=blob;f=debian/patches/multibuf.patch
Ryan 2012/01/01 18:07
The patch did not work for me. I get the same warning message before and after applying the patch. Running Fedora 16. Any help would be muchly appreciated.


checking X11/extensions/transovl.h usability... no
checking X11/extensions/transovl.h presence... no
checking for X11/extensions/transovl.h... no
checking X11/extensions/readdisplay.h usability... no
checking X11/extensions/readdisplay.h presence... no
checking for X11/extensions/readdisplay.h... no
checking X11/extensions/multibuf.h usability... no
checking X11/extensions/multibuf.h presence... yes
configure: WARNING: X11/extensions/multibuf.h: present but cannot be compiled
configure: WARNING: X11/extensions/multibuf.h: check for missing prerequisite headers?
configure: WARNING: X11/extensions/multibuf.h: see the Autoconf documentation
configure: WARNING: X11/extensions/multibuf.h: section "Present But Cannot Be Compiled"
configure: WARNING: X11/extensions/multibuf.h: proceeding with the compiler's result
checking for X11/extensions/multibuf.h... no
checking sys/filio.h usability... no
checking sys/filio.h presence... no
checking for sys/filio.h... no
Denis Barbier 2012/01/01 20:46
Did you run autoconf after applying the patch?
Ryan 2012/01/02 02:20
Denis,

Thank you very much for your help. I ran Autoconf, and the error message went away. Now I have another issue if you have a moment to help some more:


libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../.. -I/usr/lib64/include -DHAVE_GL2PS -I../../../inc -I../../../drv/OpenGl -I../../../src/OpenGl -I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.1.x86_64/include -I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.1.x86_64/include/linux -D_OCC64 -m64 -DNDEBUG -DNo_Exception -DCSFDB -DOCC_CONVERT_SIGNALS -DLIN -DLININTEL -D_GNU_SOURCE=1 -O2 -MT OpenGl_FontMgr.lo -MD -MP -MF .deps/OpenGl_FontMgr.Tpo -c ../../../src/OpenGl/OpenGl_FontMgr.cxx -fPIC -DPIC -o .libs/OpenGl_FontMgr.o
In file included from ../../../src/OpenGl/OpenGl_FontMgr.cxx:1:0:
../../../inc/OpenGl_FontMgr.hxx:9:20: fatal error: FTFont.h: No such file or directory
compilation terminated.
make[3]: *** [OpenGl_FontMgr.lo] Error 1
make[3]: Leaving directory `/home/ryan/OpenCascade/ros/adm/make/TKOpenGl'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/ryan/OpenCascade/ros/adm/make'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ryan/OpenCascade/ros'
make: *** [all] Error 2



------


I configured with the following command:

./configure --with-tcl=/usr/lib64 --with-tk=/usr/lib64 --with-java-include=/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.1.x86_64/include --with-x --with-freetype=/usr/lib64 --with-ftgl=/usr/lib64/ --with-gl2ps=/usr/lib64 --with-freeimage=/usr/local/FreeImage/usr/ --with-tbb-include=/usr/include/tbb --with-tbb-library=/usr/lib64 --with-qt=/usr/lib64/qt-3.3 --enable-static=yes --enable-production --prefix=/usr/local/OpenCASCADE



Not sure why it is looking for FTFont.h within the OpenCASCADE directory, since I have already installed FTGL...

Any insight would be very much appreciated.

Denis Barbier 2012/01/02 08:24
See http://www.opencascade.org/org/forum/thread_20128/
Ryan 2012/01/02 20:46
Thank you Denis, you have been very helpful, and I think we are almost there.

I managed to overcome a few more error messages during 'make' by using some other patches:
- looking in wrong folder for freetype http://ubuntuforums.org/showthread.php?t=1396493
- fix-freeimage-gl2ps-support.patch http://www.opencascade.org/org/forum/thread_21948/
- enable-freeimage.patch (seems to be already incorporated into OCC 652) http://www.opencascade.org/org/forum/thread_20043/
- plus the other two patches you suggested above.

Now I get an error about FreeImage:

*********

/home/ryan/OpenCascade/ros/adm/make/TKService/.libs/libTKService.so: undefined reference to `fipImage::getScanLine(unsigned int) const'
/home/ryan/OpenCascade/ros/adm/make/TKService/.libs/libTKService.so: undefined reference to `fipImage::fipImage(FREE_IMAGE_TYPE, unsigned int, unsigned int, unsigned int)'
collect2: ld returned 1 exit status
make[3]: *** [DRAWEXE] Error 1

*********

I think fipImage appears to be part of the wrapper for FreeImage. In the terminal, 'find' comes up with this:

/home/ryan/FreeImage/Wrapper/FreeImagePlus/src/fipImage.cpp

Perhaps this should have been moved to /usr/local/FreeImage/usr when I 'make install'ed FreeImage? I tried copying it there, but that was not it.

I am truly at a loss. Have you seen this before?

Regards,
Ryan

Denis Barbier 2012/01/02 21:25
Please post the full linker command line. Also are there only 2 missing symbols, or many others?
Ryan 2012/01/02 21:48
There seem only to be two missing symbols. Here is the full linker command line:


libtool: link: g++ -DCSFDB -DOCC_CONVERT_SIGNALS -DLIN -DLININTEL -D_GNU_SOURCE=1 -O2 -o .libs/DRAWEXE DRAWEXE.o -lstdc++ ../TKDraw/.libs/libTKDraw.so -L/usr/lib64 -L/usr/local/FreeImage/usr/lib /home/ryan/OpenCascade/ros/adm/make/TKMesh/.libs/libTKMesh.so /home/ryan/OpenCascade/ros/adm/make/TKHLR/.libs/libTKHLR.so /home/ryan/OpenCascade/ros/adm/make/TKService/.libs/libTKService.so ../TKMesh/.libs/libTKMesh.so ../TKernel/.libs/libTKernel.so ../TKGeomAlgo/.libs/libTKGeomAlgo.so ../TKTopAlgo/.libs/libTKTopAlgo.so ../TKHLR/.libs/libTKHLR.so /home/ryan/OpenCascade/ros/adm/make/TKTopAlgo/.libs/libTKTopAlgo.so /home/ryan/OpenCascade/ros/adm/make/TKGeomAlgo/.libs/libTKGeomAlgo.so /home/ryan/OpenCascade/ros/adm/make/TKBRep/.libs/libTKBRep.so ../TKGeomBase/.libs/libTKGeomBase.so ../TKG2d/.libs/libTKG2d.so ../TKBRep/.libs/libTKBRep.so /home/ryan/OpenCascade/ros/adm/make/TKGeomBase/.libs/libTKGeomBase.so /home/ryan/OpenCascade/ros/adm/make/TKG3d/.libs/libTKG3d.so ../TKMath/.libs/libTKMath.so ../TKG3d/.libs/libTKG3d.so /home/ryan/OpenCascade/ros/adm/make/TKG2d/.libs/libTKG2d.so ../TKService/.libs/libTKService.so /home/ryan/OpenCascade/ros/adm/make/TKMath/.libs/libTKMath.so /home/ryan/OpenCascade/ros/adm/make/TKernel/.libs/libTKernel.so -lrt -ltcl8.5 -ltk8.5 -ltbb -ltbbmalloc -lXt -lX11 -lXmu -lfreeimageplus -ldl -lpthread -Wl,-rpath -Wl,/usr/local/OpenCASCADE/lib
/home/ryan/OpenCascade/ros/adm/make/TKService/.libs/libTKService.so: undefined reference to `fipImage::getScanLine(unsigned int) const'
/home/ryan/OpenCascade/ros/adm/make/TKService/.libs/libTKService.so: undefined reference to `fipImage::fipImage(FREE_IMAGE_TYPE, unsigned int, unsigned int, unsigned int)'
collect2: ld returned 1 exit status
make[3]: *** [DRAWEXE] Error 1
make[3]: Leaving directory `/home/ryan/OpenCascade/ros/adm/make/DRAWEXE'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/ryan/OpenCascade/ros/adm/make'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ryan/OpenCascade/ros'
make: *** [all] Error 2

Denis Barbier 2012/01/02 22:29
On my machine:

$ objdump -T /usr/lib/libfreeimageplus.so | grep getScanLine | c++filt
00000000000b0b20 g DF .text     0000000000000051 Base fipImage::getScanLine(unsigned short) const

If you look at FreeImagePlus.h, you see that type argument is WORD, and WORD is an alias for unsigned short.
Moreover your missing symbols are among the few methods which have an argument of type WORD, so it looks like there is a mismatch in your installation, your libfreeimageplus.so defines fipImage::getScanLine(unsigned short) but your header file sets WORD to unsigned int.
Ryan 2012/01/03 03:52
I see references to getScanLine in both FreeImage.h and FreeImagePlus.h


In FreeImagePlus.h I see the following:

*****************

     //@}

     /**@name Pixel access */
     //@{     

     /** @brief Returns a pointer to the bitmap bits.

     It is up to you to interpret these bytes correctly,
     according to the results of FreeImage_GetBPP and
     GetRedMask, FreeImage_GetGreenMask and FreeImage_GetBlueMask.

     Use this function with getScanWidth to iterates through the pixels.
     @see FreeImage_GetBits
     */
     BYTE* accessPixels() const;

     /** @brief Returns a pointer to the start of the given scanline in the bitmap’s data-bits.
          This pointer can be cast according to the result returned by getImageType.

          Use this function with getScanWidth to iterates through the pixels.
          @see FreeImage_GetScanLine, FreeImage documentation
     */
     BYTE* getScanLine(unsigned scanline) const;

     /**

*****************


In FreeImage.h I have:

*****************
// Pixel access routines ----------------------------------------------------

DLL_API BYTE *DLL_CALLCONV FreeImage_GetBits(FIBITMAP *dib);
DLL_API BYTE *DLL_CALLCONV FreeImage_GetScanLine(FIBITMAP *dib, int scanline);
*****************

I tried changing "int scanline" to "short scanline" in FreeImage.h, but got the same result.

It sounds like maybe the issue is within the FreeImage source, and I would need to recompile FreeImage?
Denis Barbier 2012/01/03 09:43
Which version of FreeImage are you using? Why don't you use the official Fedora package?

Please also run this command:
objdump -T /usr/local/FreeImage/usr/lib/libfreeimageplus.so | grep getScanLine | c++filt
and post its output.
Ryan 2012/01/03 12:08
I am using FreeImage 3.1.5. I notice 3.1.4 source appears to have similar usage of 'int scanline'

I compiled FreeImage from source because .configure was not recognizing the .rpm installation. I will try again and post the result.

Per your request:

$ objdump -T /usr/local/FreeImage/usr/lib/libfreeimageplus.so | grep getScanLine | c++filt
objdump: '/usr/local/FreeImage/usr/lib/libfreeimageplus.so': No such file

$ objdump -T /usr/lib64/libfreeimageplus.so | grep getScanLine | c++filt
0000000000006470 g DF .text     0000000000000051 Base fipImage::getScanLine(unsigned short) const


Denis Barbier 2012/01/03 12:25
Your linker flags contain -L/usr/local/FreeImage/usr/lib, thus I thought that you compiled and installed FreeImage into /usr/local/FreeImage/usr/lib. It seems that you compile against the headers you installed, but link against system libraries, this is why it does not work.

In configure.in, replace "$freeimage/lib" by "$freeimage/lib64" everywhere and re-run autoconf, Fedora library should now be detected when calling configure --with-freeimage=/usr
Ryan 2012/01/03 12:10
Sorry, I meant to say:
I'm running FreeImage 3.15.1. I noticed the same usage of 'int scanline' in 3.14.1
Ryan 2012/01/03 12:56
It seems configure.ac is looking for the directory structure that only exists when I compile FreeImage from source. It is looking for $freeimage/include and $freeimage/lib

When I install the official fedora package, the headers are located in /usr/include and the lib files are located in /usr/lib64/

I will try modifying configure.ac as below, and pass it the flag --with-freeimage=/usr

*******

CPPFLAGS="-I$freeimage/include $CPPFLAGS";
AC_CHECK_HEADER( [FreeImage.h], [], [HAVE_FREEIMAGE_INC=no] )
if test "x$HAVE_FREEIMAGE_INC" = "xyes"; then
CSF_FreeImagePlus_INCLUDES="-I$freeimage/include -DHAVE_FREEIMAGE"
HAVE_FREEIMAGE_LIB=yes
AC_MSG_CHECKING([for FreeImage_OpenMemory in -lfreeimageplus])
LDFLAGS="-L$freeimage/lib64 $LDFLAGS"
LIBS="$CSF_FreeImagePlus_LIB $LIBS"
AC_CHECK_LIB( [freeimageplus], [FreeImage_OpenMemory], [CSF_FreeImagePlus_LIB="-L$freeimage/lib64 -lfreeimageplus"], [HAVE_FREEIMAGE_LIB=no] )
Ryan 2012/01/03 17:48
Denis,

It was a success! You are correct, there were conflicting traces of both the Fedora official installation and the version I compiled.

I completely removed all traces of FreeImage and reinstalled the Fedora official install, but it is 3.10.1, and it fails on "checking for FreeImage_OpenMemory" in ./configure

I then removed that and re-compiled using 3.14.1, and applied a change noted here: http://sourceforge.net/projects/freeimage/forums/forum/36111/topic/3807101

and passed compiler flag --with-freeimage=/usr/local/FreeImage/usr

then 'make' and 'make install'

Success!

Thank you for your help! I feel like I learned a lot from this experience.
 
 
Latest news
  • OCCT Applications
  • Open CASCADE Technology 6.8.0 is available for download!
  • New features to enhance the development process

  • © OPEN CASCADE 2000 - 2014  |  Search  |  Contacts   |  Site map