Problems compiling the NIST STEP Class Library (SCL)

103 views
Skip to first unread message

Bryan Bishop

unread,
Jun 21, 2010, 9:23:40 AM6/21/10
to Open Manufacturing, Bryan Bishop
Hey all,

I am having some trouble compiling the NIST STEP Class Library (SCL).

SCL
http://www.mel.nist.gov/msid/scl/SCL.htm
download: http://www.mel.nist.gov/msid/scl/scl3-2.tar.Z

"The NIST STEP Class Library (SCL) is a set of C++ class libraries
which are capable of representing information conforming to the
EXPRESS (ISO 10303-11) data specification. The libraries may be used
to build executable C++ applications which make use of information
contained in an EXPRESS file. They contain such features as a
dictionary of EXPRESS schema information and functionality for
representing and manipulating instances of EXPRESS objects. Simple
applications, such as ones which read and write EXPRESS data in the
form of STEP Part 21 files, can be easily written and are included in
the SCL release. "

components:
* fedex_plus - parses an EXPRESS file and generates a C++ class
library representation based on the STEP Data Access Interface (SDAI)
C++ language binding (ISO 10303-23). Using the -c option fedex_plus
outputs TIE implementation objects for building an Orbix (see
Disclaimer) CORBA server based on the SDAI IDL language binding (ISO
10303-26).
* fedex_idl - translates EXPRESS into idl based on the STEP Data
Access Interface IDL language binding (ISO-10303-26).
* fedex_os - parses an EXPRESS file and generates C++ necessary
for adding persistence to the classes output from fedex_plus.
Persistence is implemented using ObjectStore OODBMS (see Disclaimer).
* mkProbe - takes an EXPRESS file and generates a Data Probe
editor/schema browser. The Data Probe is a graphical tool which allows
a user to visually browse the information contained in an EXPRESS
schema and to create and edit instances of entities defined in the
schema. It also allows input and output of files based on the EXPRESS
file which conform to the STEP Part 21 (ISO 10303-21) encoding method.
* STEP core library - library of C++ classes providing STEP
related functionality including early and late-bound attribute access,
reading and writing of STEP Part 21 files, classes implementing
EXPRESS base types, etc.
* data access interface library - library of C++ classes providing
a partial implementation of the SDAI Session Schema.
* editor library - library of C++ classes implementing the
functionality associated with an editor for instances of entities
defined in EXPRESS.
* utils library - library of C++ classes providing generic C++
functionality.
* ivfasd library - library of C++ classes providing
general-purpose InterViews user interface objects.
* probe-ui library - library of C++ classes providing InterViews
user interface objects for implementing an editor of EXPRESS
instances.
* fedex - syntax and semantic checker for EXPRESS. Based on the
NIST EXPRESS Toolkit.
* exppp - pretty printer for formatting EXPRESS. Based on the NIST
EXPRESS Pretty Printer Toolkit.

In particular, fedex_plus looks pretty interesting to me. So, I've
been trying to compile- I get the same errors with the configure and
make scripts with the ones provided, as well as the ones that automake
and autoconf generate. I suspect this is going to take some massaging
to get working, it was developed on SPARC and tested on Solaris and
SunOS but someone got it to compile on Microsoft Windows at some
point. Does anyone have some insight into the following errors and
problems? Maybe they are related to typical Solaris-to-Linux cross
platform compatibility issue goodness.

First, I get some weirdness in ./configure -- which doesn't halt the
show -- but it's still weird:

Replacing flex with it's complete path /usr/bin/flex
checking for bison... bison -y
YACC is bison -y
checking for bison... /usr/bin/bison
Replacing bison -y with it's complete path /usr/bin/bison -y
./configure: line 4773: YACC: command not found
./configure: line 4773: YACCFLAGS: command not found
./configure: line 4776: UTIL: command not found
./configure: line 4784: UTIL: command not found
./configure: line 4786: BISONTOKENS: command not found
./configure: line 4789: BISON: command not found
./configure: line 4789: YACCFLAGS: command not found
./configure: line 4791: UTIL: command not found
./configure: line 4793: BISONTOKENS: command not found
./configure: line 4795: CC: command not found
./configure: line 4795: CCFLAGS: command not found
./configure: line 4802: BISON: command not found
./configure: line 4802: YACCFLAGS: command not found
./configure: line 4804: UTIL: command not found
./configure: line 4806: BISONTOKENS: command not found
./configure: line 4808: CC: command not found
./configure: line 4808: CCFLAGS: command not found
./configure: line 4808: PROFILE: command not found
configure: WARNING: "No InterViews info specified... to use InterViews
specify the IV root directory using
--with-iv=specify-iv-root-directory-here"
./configure: line 4893: IVROOT: command not found
./configure: line 4913: IVROOT: command not found

I don't know why a configure script would be looking for YACC, CC,
etc., in all caps. Then, it goes on to try to run a program called "o"
?

Running the script: setup-arch - creates directory
/home/kanzure/local/stepcl/scl3-2/arch
Running the script: sclbuild - builds scl under
/home/kanzure/local/stepcl/scl3-2/arch
rm -f *.~*~ *.o libexpress.a expparse.tok*.h expparse.h expparse.c
expparse.tab.output expscan.c
/bin/rm -f symbol.o
/usr/bin/gcc -g -DREAL_MALLOC -DYYDEBUG -DFLEX -DHAVE_CONFIG_H -I.
-I/home/kanzure/local/stepcl/scl3-2/src/express/
-I/home/kanzure/local/stepcl/scl3-2/arch -c symbol.c
In file included from symbol.h:51,
from symbol.c:38:
basic.h:145:1: warning: "_POSIX_SOURCE" redefined
In file included from /usr/include/stdio.h:28,
from basic.h:75,
from symbol.h:51,
from symbol.c:38:
/usr/include/features.h:199:1: warning: this is the location of the
previous definition
o expparse.tab.c expparse.y
make: o: Command not found
make: [expparse.c] Error 127 (ignored)

Immediately after that:

cp /bison.errors bison.sub
cp: cannot stat `/bison.errors': No such file or directory
make: *** [expparse.c] Error 1

.. which doesn't make sense to me. Why would bison.errors be on / in
the first place? Next, I get some complaints about multiple
definitions in some header files, blah blah blah. Then some other
interesting errors:

error.c: In function 'ERRORreport':
error.c:269: warning: incompatible implicit declaration of built-in
function 'abort'
error.c:271: warning: incompatible implicit declaration of built-in
function 'exit'
error.c: In function 'ERRORreport_with_symbol':
error.c:396: warning: incompatible implicit declaration of built-in
function 'abort'
error.c:398: warning: incompatible implicit declaration of built-in
function 'exit'
error.c:414: warning: incompatible implicit declaration of built-in
function 'abort'
error.c:416: warning: incompatible implicit declaration of built-in
function 'exit'
error.c: In function 'ERRORabort':
error.c:539: warning: incompatible implicit declaration of built-in
function 'abort'

In file included from classes_wrapper.cc:9:
complexSupport.h:82: error: a class-key must be used when declaring a friend
complexSupport.h:82: error: friend declaration does not name a class or function
complexSupport.h:83: error: a class-key must be used when declaring a friend
complexSupport.h:83: error: friend declaration does not name a class or function
complexSupport.h:84: error: a class-key must be used when declaring a friend
complexSupport.h:84: error: friend declaration does not name a class or function
complexSupport.h:85: error: a class-key must be used when declaring a friend
complexSupport.h:85: error: friend declaration does not name a class or function
complexSupport.h:86: error: a class-key must be used when declaring a friend
complexSupport.h:86: error: friend declaration does not name a class or function
complexSupport.h:94: error: ISO C++ forbids declaration of
'operator==' with no type
complexSupport.h:96: error: ISO C++ forbids declaration of 'operator<'
with no type
complexSupport.h:98: error: ISO C++ forbids declaration of 'operator>'
with no type

In file included from ../../../src/clstepcore/sdaiApplication_instance.cc:17:
../../../src/clstepcore/sdai.h:358:1: error: pasting "::" and
"Application_instance" does not give a valid preprocessing token
../../../src/clstepcore/sdai.h:358:1: error: pasting "SDAI" and "::"
does not give a valid preprocessing token
../../../src/clstepcore/sdai.h:365:1: error: pasting "::" and
"Application_instance" does not give a valid preprocessing token
../../../src/clstepcore/sdai.h:365:1: error: pasting "SDAI" and "::"
does not give a valid preprocessing token
../../../src/clstepcore/sdai.h:366:1: error: pasting "::" and
"Application_instance" does not give a valid preprocessing token
../../../src/clstepcore/sdai.h:366:1: error: pasting "SDAI" and "::"
does not give a valid preprocessing token
../../../src/clstepcore/sdai.h:369:1: error: pasting "::" and
"Application_instance" does not give a valid preprocessing token

In file included from ../../../src/cleditor/instmgr.h:46,
from ../../../src/clstepcore/sdaiApplication_instance.cc:19:
../../../src/cleditor/mgrnode.h:60:1: error: pasting "::" and
"Application_instance" does not give a valid preprocessing token
../../../src/cleditor/mgrnode.h:60:1: error: pasting "SDAI" and "::"
does not give a valid preprocessing token

Any thoughts?

- Bryan
http://heybryan.org/
1 512 203 0507

Bryan Bishop

unread,
Jun 21, 2010, 9:30:06 AM6/21/10
to Open Manufacturing, Bryan Bishop
On Mon, Jun 21, 2010 at 8:23 AM, Bryan Bishop wrote:
> point. Does anyone have some insight into the following errors and
> problems? Maybe they are related to typical Solaris-to-Linux cross
> platform compatibility issue goodness.

I should add that I am running Debian lenny/testing/unstable/volatile
with kernel 2.6.30-bpo.1-686.

Paul D. Fernhout

unread,
Jun 21, 2010, 10:53:26 AM6/21/10
to openmanu...@googlegroups.com
Bryan Bishop wrote:
> I don't know why a configure script would be looking for YACC, CC,
> etc., in all caps. Then, it goes on to try to run a program called "o"
> ?

Maybe it is looking for shell script variables? (Often in all upper case.)

Maybe the script was written for a different version of a shell? csh vs bash
etc.?

Possibly some other part of a path is messed up by a missing shell variable
setting? So the path gets short?

The "o" command could be a similar problem?

> error.c: In function 'ERRORreport':
> error.c:269: warning: incompatible implicit declaration of built-in
> function 'abort'
> error.c:271: warning: incompatible implicit declaration of built-in
> function 'exit'
> error.c: In function 'ERRORreport_with_symbol':
> error.c:396: warning: incompatible implicit declaration of built-in
> function 'abort'
> error.c:398: warning: incompatible implicit declaration of built-in
> function 'exit'
> error.c:414: warning: incompatible implicit declaration of built-in
> function 'abort'
> error.c:416: warning: incompatible implicit declaration of built-in
> function 'exit'
> error.c: In function 'ERRORabort':
> error.c:539: warning: incompatible implicit declaration of built-in
> function 'abort'

A porting issue with library definitions? You can probably just change the
code with some ifdefs? Probably void vs. int issues, or maybe int vs. long?

> In file included from classes_wrapper.cc:9:
> complexSupport.h:82: error: a class-key must be used when declaring a friend
> complexSupport.h:82: error: friend declaration does not name a class or function
> complexSupport.h:83: error: a class-key must be used when declaring a friend
> complexSupport.h:83: error: friend declaration does not name a class or function
> complexSupport.h:84: error: a class-key must be used when declaring a friend
> complexSupport.h:84: error: friend declaration does not name a class or function
> complexSupport.h:85: error: a class-key must be used when declaring a friend
> complexSupport.h:85: error: friend declaration does not name a class or function
> complexSupport.h:86: error: a class-key must be used when declaring a friend
> complexSupport.h:86: error: friend declaration does not name a class or function
> complexSupport.h:94: error: ISO C++ forbids declaration of
> 'operator==' with no type
> complexSupport.h:96: error: ISO C++ forbids declaration of 'operator<'
> with no type
> complexSupport.h:98: error: ISO C++ forbids declaration of 'operator>'
> with no type

More porting issues of different compiler expectations? Or maybe some
missing header file issue?

> Any thoughts?

These are all just guesses.

Seems like a great idea to be getting it to work and to be able to leverage
anything from NIST though.

If the issues is with your current Debian configuration (unstable), you
might keep a VirtualBox system around configured in stable or testing, just
to see if the issue is there.
http://www.virtualbox.org/
But, I think you'd be more likely to see linker issues then, not so much
what you outline.

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies of
abundance in the hands of those thinking in terms of scarcity.

Bryan Bishop

unread,
Jul 6, 2011, 6:22:49 PM7/6/11
to mark pictor, Bryan Bishop, Open Manufacturing
On Wed, Jul 6, 2011 at 10:40 AM, Mark Pictor <mpi...@gmail.com> wrote:
I just happened to find this post on google. If you're still
interested, see https://github.com/mpictor/StepClassLibrary

Thank you.
 
I hope to find people who understand STEP, EXPRESS, and the flex/bison
parser in SCL, because SCL needs some work. Hopefully this version

I understand the concepts and the toolchain, but I haven't successfully implemented anything with EXPRESS. I haven't generated any AMIs or the SDAI.
 
will compile for you. Whether it will currently work with your express
schema depends on the schema.

I am looking through my notes.. I keep links to where I download most of this crap, so you might find something useful in here.

ftp.cme.nist.gov:pub/step/npttools/exptk.tar.Z
ftp.cme.nist.gov:pub/step/npttools/exppp.tar.Z
ftp://interviews.stanford.edu:pub/3.1.tar.Z

I also have copies of some of these, should you need them. In addition, I have uploaded some files that you might find useful over here:


After poking around in BRLCAD and OpenCASCADE for years, I decided to write my own simple NURBS-based modeling program called `lolcad`. It's over here:


Due to a momentary lapse of lucidity, I wrote my own STEP file generator in python. I didn't use EXPRESS to generate the python code. As a result, it's pretty messy and the output method sucks a lot. But it seems to generate valid STEP. The main point of lolcad is to provide a simple, python-based NURBS manipulation library for CAD; so, temporarily, my messy STEP generator is probably fine until it becomes a bottleneck.

OpenCASCADE is terribly written and will never improve. I doubt any of the remaining employees at OpenCASCADE S.A.S know how to debug their own NURBS code; their STEP import/export code looks like it was manually written. PythonOCC was nice to play around with for a while. But a dependency on OpenCASCADE is probably not the smartest idea anyway since the upstream library is such a hack. OCE might end up rewriting large chunks, but I feel effort could be spent writing a simpler, more concise library. I have a lot of code in SKDB that depends on pythonOCC, if you're interested in poking around:


BRLCAD has been a source of stability for years, but their NURBS support (OpenNURBS) is minimal. Their (non-working) boolean operation library is based on a small rewrite of BOOLE (an academic NURBS library with a few papers written up about it) as part of Google Summer of Code in 2009/2010, but it never went anywhere. Anyone wanting to implement NURBS reliably would have to start from scratch in their codebase. In the lolcad codebase, you can see my beginnings of a rewrite of BOOLE and ESOLID, as well as swig and cython wrappers for one or the other (I'm p. sure the cython wrapper is for ESOLID).

Right now the hangup on lolcad is not so much STEP (as this seems to be a "solved" problem) but rather the visualization, believe it or not. I am getting different results on different computers. And apparently it takes longer to do remote debugging.. i.e. getting people to be around when I have time for debugging.

So that's my current state-dump. Hope this helps somehow.

Bryan Bishop

unread,
Jul 6, 2011, 9:41:40 PM7/6/11
to John Griessen, Bryan Bishop, Open Manufacturing
On Wed, Jul 6, 2011 at 8:34 PM, John Griessen <jo...@industromatic.com> wrote:

BRLCAD has been a source of stability for years, but their NURBS support (OpenNURBS) is minimal.

Hi Bryan,

What do you think is the limiting thing with CAD code like this?  Is it all just too

Nobody working on these problems in the open source community has prior experience writing NURBS manipulation code. This is the biggest issue.
 
much to do for small groups of people, or is there going to be a library

It's the sort of problem that a single person has to solve first, and then a group can move in and work on it. Making "half" of a boolean operation isn't helpful at all; so until someone sits down and writes out all of the code in a simple, understandable, maintainable, documented way, we're going nowhere fast. So far the problem isn't really "sit down and write code for an entire weekend and you're done"; in March I went on this 10-day (>10 hours/day) coding binge for a re-implementation of ESOLID and while I made some progress, I didn't get to the point where a simple demo of functionality was possible. The whole thing has to be written before it starts working, which is drastically different from other programming problems where you write code for 10min and then you're able to start testing if it works or not.
 
or modeling method that simplifies it enough that a FOSS tool will be able to
do boolean operations on 3D data that is open?

Some people say lua language is helpful.  I've not looked at it,
and my favorite for scripts is python since I can read my old writings
in it, and I can't read my old perl writings.

The language doesn't really matter.
Reply all
Reply to author
Forward
0 new messages