For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings

 

Need to speed up your development?
Have a look at our:

Samples & Tools

 

Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

Related pages

Help with installing

Scott KIes's picture

Hi,

I am trying install and application called lignumCAD which is a furniture design and drafting application. It makes use of OpenCascade 4. I assume you download the source and compile it? Guess what I don't have any development tools installed. So, I got a gcc compile RPM and installed it and it appears to have gone okay. I then needed make. I got a version of make but the intall script issues a gcc -V. The compiler doesn't know anything about the -V option. Do I have it installed incorrectly or do I need a differenct version?

Thanks for your help in advance.

Cheers,
Scott

Brent Goodrick's picture

Which OS are you running? Which version? I'm in the same boat as you are (trying to build opencascade as a prerequisite to lignumcad).

bg

Scott KIes's picture

Well, I'm running a version of Linux from Lycoris (formerly known ad Redmond Linux). I got the development tools installed and ran the ./configure script. It indicated it was missing install-sh. So, I found it in /src or /make and linked it to this directory and ran it. Now it indicates that it cannot locate my Tcl Configuration Definition file. Not sure where that is or how I indicate it's location to ./configure.

any ideas would be appreciated.

Cheers,
Scott

Brent Goodrick's picture

I've decided to move away from using the opencascade tarball, as I
think it might be stale, as I've seen the same quirky errors you've
been seeing, and even on a completely different version of Linux --
Red Hat 7.3. I've been trying to use the stuff at:

http://autoopencas.sourceforge.net/

which requires a long process to pull the sources directly via remote
CVS via a command along the lines of:

cvs -z9 -d :pserver:anonymous@cvs.autoOpenCAS.sourceforge.net:/cvsroot/autoopencas co OCC

Not sure, but I don't think that the above requires you to do a "cvs
login" before execution. Reading between the lines at the above web
site leads me to suspect that those sources might not be exactly the
same as the CVSROOT implied by:

http://www.opencascade.org/devversion/cvs.php

The ./configure line that I'm trying to use with the "autoopencas"
stuff is currently:

./configure \
--with-tcl=$(INSTALL_DIR_tcl)/lib \
--with-tk=$(INSTALL_DIR_tk)/lib \
--prefix=$(INSTALL_DIR_opencascade) \
--enable-static=no

where INSTALL_DIR_tcl and INSTALL_DIR_tk are the --prefix directories
of the installs of Tcl and Tk, respectively. I just downloaded and
rebuild tcl and tk just to be safe -- I've found that when I'm using
anything from CVS that I'm better off using the latest and greatest of
every subpackage that the thing (opencascade in this instance) depends
upon.

Right now, I'm in the middle of recompiling AutoConf 2.54 and AutoMake
1.7 as the autoconfig-scated opencascade ./configure script barked at
me like this:

gmake[5]: Entering directory `SNIPPED/opencascade/Linux_2_4_18_3/OCC/OCC'
cd . && \
/bin/sh SNIPPED/opencascade/Linux_2_4_18_3/OCC/OCC/make/missing --run automake-1.7 --gnu GNUmakefile
SNIPPED/opencascade/Linux_2_4_18_3/OCC/OCC/make/missing: automake-1.7: command not found
WARNING: `automake-1.7' is missing on your system. You should only need it if
you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
You might want to install the `Automake' and `Perl' packages.
Grab them from any GNU archive site.
Making all in libltdl
gmake[6]: Entering directory `SNIPPED/opencascade/Linux_2_4_18_3/OCC/OCC/libltdl'
gmake[6]: *** No rule to make target `all'. Stop.

So, yeah its a battle. Now that there is a AutoConf, AutoMake, there
should also be a AutoDownloadAndJustBuildIt too. ;)

bg

Scott KIes's picture

It appears you are far more technically adept at this type of process than I am! What is the difference between the download at http://autoopencas.sourceforge.net/ and the download available via www.opencascade.com/download/?

Scott KIes's picture

It has been a long night. I downloaded and installed the latest and greatest of tcl, tk, autconf, automake. I then went to sourceforge.net and did the cvs download. It appeared to go smoothly.

I now run the ./configure --enable-static=no \\
--prefix=/usr/share/OCC/OCC

It runs for a long time and then throws an error. Here is a snippet of the config.sh

configure:25440:WARNING: no configuration information is in libltdl

and basically quits. Ya think I might be missing something in that directory? How did yours turn out?

Brent Goodrick's picture

No, I'm not adept at this -- just trying to fix each error as I go, and making wild guesses as to which dependency must be out of date or stale.

Yes, that libltdl is a problem on my end too. I could be wrong, but it seems that there are some M4 macros that are not getting expanded by one ore more of those Auto???? things. My guess is that the versions of those Auto???? things that OCC/OCC was built with are not forwardly compatible with the recent Auto??? things you and I downloaded. Sound confusing? Yes, it is.

Bear with me on this, I'm trying to get this up and running in my "off hours", so my responses may be delayed.

bg

Brent Goodrick's picture

I've gotten past the missing M4 macro issues. Jump to the fixes I
applied by searching below for "The Fix1" and "The Fix2".

Ok, so heres what I did and the errors I saw, so that they show up in
the forum web search:

At some point during the execution of:

./configure \
--with-tcl=$(INSTALL_DIR_tcl)/lib \
--with-tk=$(INSTALL_DIR_tk)/lib \
--prefix=$(INSTALL_DIR_opencascade) \
--enable-static=no

it complained that I had an old automake installed:

gmake[5]: Entering directory `..../thirdParty/opencascade/objdir/opencascade/Linux_2_4_18_3/OCC/OCC'
cd . && \
/bin/sh ..../thirdParty/opencascade/objdir/opencascade/Linux_2_4_18_3/OCC/OCC/make/missing --run automake-1.7 --gnu GNUmakefile
..../thirdParty/opencascade/objdir/opencascade/Linux_2_4_18_3/OCC/OCC/make/missing: automake-1.7: command not found
WARNING: `automake-1.7' is missing on your system. You should only need it if
you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
You might want to install the `Automake' and `Perl' packages.
Grab them from any GNU archive site.
Making all in libltdl
gmake[6]: Entering directory `..../thirdParty/opencascade/objdir/opencascade/Linux_2_4_18_3/OCC/OCC/libltdl'
gmake[6]: *** No rule to make target `all'. Stop.

Fair enough. This is Red Hat 7.3 and is in bad need of an upgrade. I
figured (probably correctly or incorrectly, I don't know yet) to
install the latest of all three tools: automake, autoconf, and
libtool, because they like to be together I think ("The Fix1"). Lots
to read in their associated info pages. Whew!

... lots of time passes with lots of hair loss ...

Ok, now I've got these tools in my $PATH and here are their versions,
along with what my uname -a spits out:

nunyabidness@brentg : autoconf --version
autoconf (GNU Autoconf) 2.57
Written by David J. MacKenzie and Akim Demaille.

Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
nunyabidness@brentg : automake --version
automake (GNU automake) 1.7
Written by Tom Tromey
.

Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
nunyabidness@brentg : libtool --version
ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54)
nunyabidness@brentg : uname -a
Linux nunyabidness 2.4.18-3 #1 Thu Apr 18 07:32:41 EDT 2002 i686 unknown
nunyabidness@brentg :

At this point, I recall carefully going through the CVS entries and
removing stuff layed down by my own experiments with automake/autoconf
just so that I can start fresh. Then I executed ./configure again and
got:

Working on pre-configure task: autoconf

configure.ac:17: error: possibly undefined macro: AC_LIBLTDL_INSTALLABLE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:18: error: possibly undefined macro: AC_LIBTOOL_DLOPEN
configure.ac:20: error: possibly undefined macro: AC_PROG_LIBTOOL
make[3]: *** [..../thirdParty/touchDir/.opencascade.preconfigure] Error 1
make[3]: Leaving directory `..../thirdParty/opencascade/opencascade'
make[2]: *** [force.opencascade.all] Error 2
make[2]: Leaving directory `..../thirdParty/opencascade/opencascade'
make[1]: *** [all] Error 2
make[1]: Leaving directory `..../thirdParty/opencascade/opencascade'
make: *** [all] Error 2

Compilation exited abnormally with code 2 at Sat Jan 4 20:58:48

Ok, after lots, and I mean lots, of reading through the info pages, I
discovered that aclocal (that comes with automake) is responsible for
plugging in the appropriate macros so that autoconf can expand them
when it creates the ./configure script. Back to the info pages once
again ... yep, gotta give aclocal the -I switch so that it can find
the definitions of things like AC_LIBLTDL_INSTALLABLE (which, by the
way, is found inside the libtool installation directory in the
share/aclocal subdirectory).

So, I then changed my "preconfigure" steps to:

cd ..../thirdParty/objdir/opencascade/Linux_2_4_18_3/OCC/OCC
aclocal -I $(INSTALL_DIR_libtool)/share/aclocal
autoupdate # automake
autoconf

Then the new ./configure script barks at me once again, but I'm making
progress now:

config.status: linking ./make/install-sh to libltdl/install-sh
config.status: linking ./make/depcomp to libltdl/depcomp
config.status: linking ./make/config.guess to libltdl/config.guess
config.status: linking ./make/config.sub to libltdl/config.sub
config.status: linking ./make/missing to libltdl/missing
config.status: linking ./make/mkinstalldirs to libltdl/mkinstalldirs
config.status: executing depfiles commands
configure: configuring in libltdl
configure: running /bin/sh './configure' --prefix=/net/nunyabidness/scratch1/opencascade/Linux_2_4_18_3 '--with-tcl=/net/nunyabidness/scratch1/tcl8.4.1/Linux_2_4_18_3/lib' '--with-tk=/net/nunyabidness/scratch1/tk8.4.1/Linux_2_4_18_3/lib' '--prefix=/net/nunyabidness/scratch1/opencascade/Linux_2_4_18_3' '--enable-static=no' --enable-ltdl-install=no --cache-file=/dev/null --srcdir=.
configure: error: cannot find sources (ltdl.c) in .
configure: error: /bin/sh './configure' failed for libltdl
make[3]: *** [..../thirdParty/touchDir/.opencascade.configure] Error 1
make[3]: Leaving directory `..../thirdParty/opencascade/opencascade'
make[2]: *** [force.opencascade.all] Error 2
make[2]: Leaving directory `..../thirdParty/opencascade/opencascade'
make[1]: *** [all] Error 2
make[1]: Leaving directory `..../thirdParty/opencascade/opencascade'
make: *** [all] Error 2

Hmmm, ltdl.c is missing. Why? Was that a CVS checkin mishap? I
don't know. Reading the libtool and libtoolize info pages I conclude
that I must blow away the CVS version of OCC/OCC/libltdl and run
libtoolize to repopulate it. I concluded that because my installation
of libtool has a file share/libtool/libltdl/ltdl.c relative to its
installation directory, and besides, I'm using a new automake and
libtool.

Here is the new preconfiguration steps I took ("The Fix2"):

cd ..../thirdParty/objdir/opencascade/Linux_2_4_18_3/OCC/OCC
aclocal -I $(INSTALL_DIR_libtool)/share/aclocal
autoupdate # automake
libtoolize --force --ltdl --copy
autoconf

I threw the --copy switch because soft-links in CVS directories give
me the eebeejeebees. That --ltdl switch populates the ./libltdl
directory and adds the missing ltdl.c file.

Good, we got past configure step. Hmmmm, that's really cute that the
gmake all step inside libltdl directory says it had nothing to
do. Thanks a lot, autoconf.

Ok, *finally* I've gotten past the "preconfigure" and ./configure
steps, and am running make. I'm getting compilation in the
subdirectories. That's good, but now I've got Red Hat gcc v2.96
problems it looks like (word wrapped for your reading pleasure):

g++ \
-DHAVE_CONFIG_H \
-I. \
-I. \
-I../.. \
-I../../inc \
-I../../drv/FSD \
-I../../drv/GraphDS \
-I../../drv/GraphTools \
-I../../drv/MMgt \
-I../../drv/OSD \
-I../../drv/Plugin \
-I../../drv/Quantity \
-I../../drv/Resource \
-I../../drv/SortTools \
-I../../drv/Standard \
-I../../drv/StdFail \
-I../../drv/Storage \
-I../../drv/TColQuantity \
-I../../drv/TColStd \
-I../../drv/TCollection \
-I../../drv/TShort \
-I../../drv/Units \
-I../../drv/UnitsAPI \
-I../../drv/Dynamic \
-I../../drv/Materials \
-I../../drv/IncludeLibrary \
-I../../drv/Dico \
-I../../drv/LibCtl \
-g \
-O2 \
-DCSFDB \
-MT \
Dico_DictionaryOfInteger_0.lo \
-MD \
-MP \
-MF \
.deps/Dico_DictionaryOfInteger_0.Tpo \
-c \
../../drv/Dico/Dico_DictionaryOfInteger_0.cxx \
\
-fPIC \
-DPIC \
-o \
Dico_DictionaryOfInteger_0.lo
In file included from ../../inc/Standard_TypeDef.hxx:22,
from ../../inc/Standard_Address.hxx:13,
from ../../inc/Standard.hxx:28,
from ../../inc/Dico_DictionaryOfInteger.hxx:20,
from ../../drv/Dico/Dico_DictionaryOfInteger_0.cxx:15:
../../inc/Standard_Stream.hxx:5:15: ios: No such file or directory
../../inc/Standard_Stream.hxx:6:19: istream: No such file or directory
../../inc/Standard_Stream.hxx:7:19: ostream: No such file or directory

Lots of searching the web -- found lots of whining about this #include
thing. I've concluded its Red Hat's fault, and am now
recompiling gcc v3.2.1 which is going along just fine (which is
strange given its complexity). Looking at
http://gcc.gnu.org/ml/libstdc++/2001-02/msg00131.html I concluded that
#include is probably valid, and saw
http://www-cpd.fnal.gov/personal/wb/boost/ISOcxx/ISOcxx/ios to
conclude others are trying to hacking around it on broken gcc's. Glad
I have the option of moving to a better gcc. Also, I recall v2.96
being shunned as bad religion by the gcc priests somewhere on the web.

I'll post the results of my attempt at getting the new gcc to compile
opencascade, after the new gcc finishes compiling.

Brent Goodrick's picture

> I'll post the results of my attempt at getting the new gcc to compile
> opencascade, after the new gcc finishes compiling.

Ok, I finished compiling and installing gcc-3.2.1, and verified it has
the ios header file at
/Linux_2_4_18_3/include/c++/3.2.1/ios, which
opencascade code is using (and that gcc 2.96 could not swallow).

Now I need to bind in this new gcc into my opencascade build somehow.
Should be as easy as exporting the CC and CXX environment variables
before executing the ./configure script, right? Nope. I got these
errors when the rebuilt (by the new autoconf) OCC/OCC/configure calls
into the old libltdl/configure:

configure: configuring in libltdl
configure: running /bin/sh \
'./configure' \
--prefix=/net/nunyabidness/scratch1/opencascade/Linux_2_4_18_3 \
\
'--with-tcl=/net/nunyabidness/scratch1/tcl8.4.1/Linux_2_4_18_3/lib' \
'--with-tk=/net/nunyabidness/scratch1/tk8.4.1/Linux_2_4_18_3/lib' \
'--prefix=/net/nunyabidness/scratch1/opencascade/Linux_2_4_18_3' \
'--enable-static=no' \
'CC=/net/nunyabidness/scratch1/gcc-3.2.1/Linux_2_4_18_3/bin/gcc' \
'CXX=/net/nunyabidness/scratch1/gcc-3.2.1/Linux_2_4_18_3/bin/g++' \
--enable-ltdl-install=no \
--cache-file=/dev/null \
--srcdir=.
configure: warning: CC=/net/nunyabidness/scratch1/gcc-3.2.1/Linux_2_4_18_3/bin/gcc: invalid host type
configure: warning: CXX=/net/nunyabidness/scratch1/gcc-3.2.1/Linux_2_4_18_3/bin/g++: invalid host type
configure: error: can only configure for one host and one target at a time
configure: error: /bin/sh './configure' failed for libltdl

Looking at the two configure scripts -- one is very old (libtoolize is
copying one generated by autoconf 2.13 which is incompatible with the
one I generated in the directory above it using autoconf 2.57, as 2.57
generated configure script expect all configure scripts to take the
CC=value as an argument). I would have thought that the new libtool
would be in sync with the new autoconf (maybe the authors aren't
having weekly meetings), as it's libtoolize script copies that
configure script there. Oh well, just have to run
aclocal/automake/autoconf in libltdl too.

You have to just remove libltdl everytime through, and rebuild it from
scratch, which involved this sequence of steps to be done BEFORE
running automake in the toplevel (OCC/OCC) directory. So, heres the
latest magic sequence of steps I had to take:

Rebuild the libltdl subdirectory:

cd ..../OCC/OCC
rm -rf libltdl
libtoolize --force --ltdl --copy
# fix a bug (I think) in libtoolize that doesn't copy the ltmain.sh:
cp /net/nunyabidness/scratch1/libtool-1.4.3/Linux_2_4_18_3/share/libtool/ltmain.sh ..../OCC/OCC/libltdl/ltmain.sh
chmod a+x ..../OCC/OCC/libltdl/ltmain.sh
# rebuild the libltdl/configure script that libtoolize copied,
# which is incompatible with the configure script in the directory
# above it (i.e., the libtoolize'ed version does not handle
# CC=... on its command line):
cd ..../OCC/OCC/libltdl
# automake isn't smart enough to yank in the libtool M4 macros yet, so we have to babysit it a bit:
aclocal -I /net/nunyabidness/scratch1/libtool-1.4.3/Linux_2_4_18_3/share/aclocal
autoupdate
# make sure automake doesn't whine about missing files (I don't
# know if this a good thing to do yet -- we'll see if I can even
# link opencascade at the end!)
automake --add-missing --copy
autoconf

Ok, now that libltdl is fresh, I can do the other preconfigure stuff:

cd ..../OCC/OCC;
# automake isn't smart enough to yank in the libtool M4 macros yet, so we have to babysit it a bit:
aclocal -I /net/nunyabidness/scratch1/libtool-1.4.3/Linux_2_4_18_3/share/aclocal
autoupdate
automake
autoconf

Now I can finally run the top level ./configure script (not inside libltdl):

cd ..../OCC/OCC;
CC=/net/nunyabidness/scratch1/gcc-3.2.1/Linux_2_4_18_3/bin/gcc \
CXX=/net/nunyabidness/scratch1/gcc-3.2.1/Linux_2_4_18_3/bin/g++ \
./configure \
--with-tcl=/net/nunyabidness/scratch1/tcl8.4.1/Linux_2_4_18_3/lib \
--with-tk=/net/nunyabidness/scratch1/tk8.4.1/Linux_2_4_18_3/lib \
--prefix=/net/nunyabidness/scratch1/opencascade/Linux_2_4_18_3 \
--enable-static=no

(Note the lack of semicolons (;) between CC= and ./configure above,
which says to export those variables to the ./configure process and
its children only).

Now I can run the make step:

cd ..../OCC/OCC; \
gmake
gmake[4]: Entering directory `..../OCC/OCC'
cd . && /bin/sh ..../OCC/OCC/make/missing --run autoheader
touch ./config.h.in
cd . && /bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
gmake all-recursive
gmake[5]: Entering directory `..../OCC/OCC'
Making all in libltdl
gmake[6]: Entering directory `..../OCC/OCC/libltdl'
gmake all-am
gmake[7]: Entering directory `..../OCC/OCC/libltdl'
gmake[7]: Nothing to be done for `all-am'.
gmake[7]: Leaving directory `..../OCC/OCC/libltdl'
gmake[6]: Leaving directory `..../OCC/OCC/libltdl'
Making all in src
gmake[6]: Entering directory `..../OCC/OCC/src'
Making all in TKernel
gmake[7]: Entering directory `..../OCC/OCC/src/TKernel'
if /bin/sh ../../libtool --mode=compile /net/nunyabidness/scratch1/gcc-3.2.1/Linux_2_4_18_3/bin/g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../inc -I../../drv/FSD -I../../drv/GraphDS -I../../drv/GraphTools -I../../drv/MMgt -I../../drv/OSD -I../../drv/Plugin -I../../drv/Quantity -I../../drv/Resource -I../../drv/SortTools -I../../drv/Standard -I../../drv/StdFail -I../../drv/Storage -I../../drv/TColQuantity -I../../drv/TColStd -I../../drv/TCollection -I../../drv/TShort -I../../drv/Units -I../../drv/UnitsAPI -I../../drv/Dynamic -I../../drv/Materials -I../../drv/IncludeLibrary -I../../drv/Dico -I../../drv/LibCtl -g -O2 -DCSFDB -MT Dico_DictionaryOfInteger_0.lo -MD -MP -MF ".deps/Dico_DictionaryOfInteger_0.Tpo" \
-c -o Dico_DictionaryOfInteger_0.lo `test -f '../../drv/Dico/Dico_DictionaryOfInteger_0.cxx' || echo './'`../../drv/Dico/Dico_DictionaryOfInteger_0.cxx; \
then mv ".deps/Dico_DictionaryOfInteger_0.Tpo" ".deps/Dico_DictionaryOfInteger_0.Plo"; \
else rm -f ".deps/Dico_DictionaryOfInteger_0.Tpo"; exit 1; \
fi
/net/nunyabidness/scratch1/gcc-3.2.1/Linux_2_4_18_3/bin/g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../inc -I../../drv/FSD -I../../drv/GraphDS -I../../drv/GraphTools -I../../drv/MMgt -I../../drv/OSD -I../../drv/Plugin -I../../drv/Quantity -I../../drv/Resource -I../../drv/SortTools -I../../drv/Standard -I../../drv/StdFail -I../../drv/Storage -I../../drv/TColQuantity -I../../drv/TColStd -I../../drv/TCollection -I../../drv/TShort -I../../drv/Units -I../../drv/UnitsAPI -I../../drv/Dynamic -I../../drv/Materials -I../../drv/IncludeLibrary -I../../drv/Dico -I../../drv/LibCtl -g -O2 -DCSFDB -MT Dico_DictionaryOfInteger_0.lo -MD -MP -MF .deps/Dico_DictionaryOfInteger_0.Tpo -c ../../drv/Dico/Dico_DictionaryOfInteger_0.cxx -fPIC -DPIC -o Dico_DictionaryOfInteger_0.lo
if /bin/sh ../../libtool --mode=compile /net/nunyabidness/scratch1/gcc-3.2.1/Linux_2_4_18_3/bin/g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../inc -I../../drv/FSD -I../../drv/GraphDS -I../../drv/GraphTools -I../../drv/MMgt -I../../drv/OSD -I../../drv/Plugin -I../../drv/Quantity -I../../drv/Resource -I../../drv/SortTools -I../../drv/Standard -I../../drv/StdFail -I../../drv/Storage -I../../drv/TColQuantity -I../../drv/TColStd -I../../drv/TCollection -I../../drv/TShort -I../../drv/Units -I../../drv/UnitsAPI -I../../drv/Dynamic -I../../drv/Materials -I../../drv/IncludeLibrary -I../../drv/Dico -I../../drv/LibCtl -g -O2 -DCSFDB -MT Dico_DictionaryOfTransient_0.lo -MD -MP -MF ".deps/Dico_DictionaryOfTransient_0.Tpo" \
-c -o Dico_DictionaryOfTransient_0.lo `test -f '../../drv/Dico/Dico_DictionaryOfTransient_0.cxx' || echo './'`../../drv/Dico/Dico_DictionaryOfTransient_0.cxx; \
then mv ".deps/Dico_DictionaryOfTransient_0.Tpo" ".deps/Dico_DictionaryOfTransient_0.Plo"; \
else rm -f ".deps/Dico_DictionaryOfTransient_0.Tpo"; exit 1; \
fi
.
.
.

The big deal here was the use of recent versions of the autotools
stuff. In hindsight, maybe that was overkill. Here are the versions
I used:

+ automake --version
automake (GNU automake) 1.7
Written by Tom Tromey
.

Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ autoconf --version
autoconf (GNU Autoconf) 2.57
Written by David J. MacKenzie and Akim Demaille.

Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ libtool --version
ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54)

Now its compiling C++ source files just great, without any whining
about missing the "ios" header, as the new gcc (gcc-3.2.1) has it
properly installed.

Brent Goodrick's picture

Sat Jan 11 14:41:21 PST 2003

I got to the link step and failed to link in things that were compiled
in the TKernel directory, but needed by things downstream of it like
TTOPOLOGY:

undefined reference to `TColStd_ListOfInteger::Extent() const'

Verified that TColStd_ListOfInteger::Extent is being compiled just
fine by the TKernel directory.

The libtool I am using is 1.4.3. but I am believing now that that
version is not good enough for use with the OCC stuff, as I see
references in the GNUmakefile.am files to linking with -objectlist
parameter. I checked out sources to the multi-language-branch
development branch of libtool and found that is the case. My guess is
that the libtool maintainers are working toward getting C++ shared
library linkage to work under libtool.

I'm now trying to decypher things at
http://savannah.gnu.org/cvs/?group_id=11 to see if I can get the new
libtool working. I bet I have to do something similar with autoconf
and automake by checking out those sources too. Its not apparent at
this time how to interlock autoconf and libtool via the CVS branch tag
mechanism, or even if there is some linkage. I bet that is explained
somewhere in the CVS info pages.

I'll post more about this effort later after my brain heals. Also,
having www.gnu.org not be responsive today is hampering my efforts.

Brent Goodrick's picture

That is what I'm trying to figure out. I may have to go to the contact listed at http://autoopencas.sourceforge.net/ and ask him how he set things up. My fear is that he had to make source code changes to keep libtool happy, which would mean that the two CVS trees are different and will stay different until the folks at www.opencascade.com/download/ decide to budget enough time to merge the autoopencas stuff into the mainline. Thats just a theory from my reading -- I have not talked to anybody over there yet.

bg

Scott KIes's picture

It has been a long night. I downloaded and installed the latest and greatest of tcl, tk, autconf, automake. I then went to sourceforge.net and did the cvs download. It appeared to go smoothly.

I now run the ./configure --enable-static=no \\
--prefix=/usr/share/OCC/OCC

It runs for a long time and then throws an error. Here is a snippet of the config.sh

configure:25440:WARNING: no configuration information is in libltdl

and basically quits. Ya think I might be missing something in that directory? How did yours turn out?

Accidentally replied to my open reply. Opps.

Daddy's picture

Sorry, I glazed over mid way through all of the postings here... It looks like the most recent was some weeks ago

1) Does the tarball from opencascade/download build ?
2) if so what information do I need to feed to ./configure ?

I'm running SUSE Linux 7.2 with gcc version 3.2.1