OCC with gcc3.2

Using Redhat 8.0 (GCC 3.2)

I made a directory called OCC-4.0 then downloaded the cvs tree (using cvs -z3 checkout .) into it. I followed the instructions in the web page . adm/build.htm. I made a link to install-sh in my OCC directory to get the config file to work and I used the following command to make the makefiles...
./configure --enable-static=no --with-tcl=/usr/lib
--with-tk=/usr/lib -with-gl-include=/usr/include --with-xmu-include=/usr/X11R6/include --with-xmu-library=/usr/X11R6/lib -with-gl-library=/usr/lib --prefix=/opt/OCC-4.0

then the command touch NEWS to make make stop whining.

the make then started and appeared to be going well. The only problem is that after 70 minutes of grinding my 1.4MHz P4 into the ground the make process had chewed through 18GB of disk space and I interrupted the build because it looked like it would never stop (I only had 300Mbytes of disk space left) it was linking at the time so I guess the compilation had completed successfuly.

Can it really take so much to build the shared libraries ?

Should one build the shared libraries or the static libraries out of preference ?
or are both needed ?

Commenter-1

the libtool script need the max_cmd_len variable to be added at the start of the file.

that is,
max_cmd_len=32767

The most critical library is V3d which now will be done in two steps using partial linking. And will speed up linking.

Current gcc is 3.2.2
Past success with 3.0.4 and up

thank you - that was insightful.

Now I have a different problem when the compiler gets to the TKernel directory...

../../src/FSD/FSD_CmpFile.cxx: In member function `virtual Storage_BaseDriver&
FSD_CmpFile::GetCharacter(Standard_Character&)':
../../src/FSD/FSD_CmpFile.cxx:452: invalid conversion from `int' to `
std::_Ios_Iostate'
../../src/FSD/FSD_CmpFile.cxx:452: initializing argument 1 of `void
std::basic_ios<_CharT, _Traits>::clear(std::_Ios_Iostate) [with _CharT =
char, _Traits = std::char_traits]'
make[3]: *** [FSD_CmpFile.lo] Error 1

Is this something I need to finad an answer to myself or does someone out there know a quick fix ? It seems to do this both with the distribution and with the cvs code.

It feels like I'm getting close

Commenter-1

hmm
Same problem here. Can't build TKernel (doesnot compile FSD_CmpFile). I wish there were a place where you could get all the shared libs already compiled with gcc 3.2

Please,
keep us posted.

thanks,
Commenter-3 -

Also added a #define CLK_TCK 100 at the start of OSF_Chronometer.cxx.

I have no idea if this value is correct !

this is good parctice for my high school french too.

Commenter-1

Hello

I have been fighting with OCC 4.0 and gcc 3.2 recently and I ran into all of the troubles that were reported here. I found that you can compile the library, if you first specify the symbol CXXFLAGS before running ./configure the following way

export CXXFLAGS='--DCLK_TCK=CLOCKS_PER_SEC -fpermissive -Wno_deprecated'

This way, I was able to compile the libraries

FWOSPlugin, PAppStdPlugin, PTKernel, TKBool, TKBrep, TKCAF, TKCDF, TKDraw, TKDrawDEB, TKernel, TKFeat, TKFillet, TKG2d, TKG3d, TKGeomAlgo, TKGeomBase, TKHLR, TKMath, TKOffset, TKOpenGl, TKPAppStd, TKPCAF, TKPrim, TKPShape, TKService, TKShapeSchema, TKStdSchema, TKTopAlgo, TKV2d, TKV3d, TKViewer, TKXCAF, TKXCAFSchema

There seems to be an error in the makefile that breaks the compilation after these libraries are generated. Because these libraries include all the ones I am currently working with, I didn't continue here.

By the way, by using the -fpermissive statement, the compiler is tuned to be more forgiving with small inconsistencies in the code. The executables generated with the libraries compiled like that seem to work as expected however.

I used the OCC 4.0 diustribution from the CD for this compilation

Commenter-4

It compiled and Linked !

Many, many thanks to Gilles, Bjorn, hugues and Sebastian.

I have not tested it yet, but it would seem that it has created all of the libraries (where it found the java headers I still don't know!).

In summary
I used a completely stock (fresh installed) version of Redhat Linux 8.0 (the free version from the dust jacket of a book). I used the cvs download (which is Much faster than downloading the cd image). I needed to set the max_cmd_len, I can't remember now whether or not I set the CLOCK_TCK (I think this may have been fixed in the cvs code. Anyhow, Sebastian's approach is better), I copied the version of install-sh from the make directory to the top level directory, created an empty NEWS file, changed the type of the return value for OS.setf to std::Ios_Fmtflags in a couple of files, it was not necessary to FSD_CmpFile.cxx in the cvs release, I also put up with the scrolling warnings and did not, in the end set the -Wno-deprecated or the -fpermissive flags for the compiler.

I think I might do one more build to convince myself that all is clean, but my most immediate concern is to see if what I have works.

What would be a simple, quick test ?

Commenter-1

and one more detail. I added -ldps to the existing make command for TKService and AIS_Viewer (I think the line in the Makefile already stipulated the directory and the flags for -lXt and something else. It's more obvious if you look at the file). This could probably be build into the automake files before the initial make builds the make files.

Commenter-1

changed line 452 of .../src/FSD/FSD_CmpFile.cxx from

... .clear(0)

to

... .clear()

as it says elsewhere in the code, clear(0) is not portable.

Commenter-1

Also changed the following lines in the following files...

DrawTrSurf.cxx lines 1531, 1583 and 1644
DrawTrSurf_Point.cxx line 169

to read...

std::_Ios_Fmtflags form = OS.setf(ios::scientific);

compilation continues...

Now I'm Stuck !

Any help would be appreciated...

TKService won't link...

/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `DPSinitmatrix'
/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `DPSWaitContext'
/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `DPSSetResultTable'
/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `DPSBinObjSeqWrite'
/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `DPSFlushContext'
/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `DPSDestroySpace'
/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `DPSMapNames'
/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `DPSDefaultErrorProc'
/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `XDPSCreateSimpleContext'
/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `DPSitransform'
/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `DPSDefaultTextBackstop'
/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `DPSAwaitReturnValues'
/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `DPSWriteStringChars'
/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `XDPSCreateContext'
/home/alan/opencascade/src/TKService/.libs/libTKService.so: undefined reference to `DPSSetContext'
collect2: ld returned 1 exit status
make[3]: *** [AISViewer] Error 1
make[3]: Leaving directory `/home/alan/opencascade/src/AISViewer'

Commenter-1

Looks like this is a post/ghost script problem. Is this an option I should have plugged into ./configure ?

Commenter-1

Hi,

we've encountered the same problem, too. All you need to do is link against -ldps. It should be located in /usr/X11R6/lib, so be shure to have

-L/usr/X11R6/lib -ldps

in the command line for linking your application.

Rgds,

Björn

Hi,

I didn't succeed to build OCC from the cvs of Opencascade.org (I didn't try with the -fpermissive flag). I did it from the autoopencas project (autoopencas.sourceforge.net).

The libtool script need the variable max_cmd_len to be defined. I do not remember any other problems.

I built all the libraries on a RH8.0 with gcc 3.2. I am currently using some topological and dataexchange features, and it works. I did not try any display features.

Commenter-6.