g++ -O -g -I/home/myname/Shore_1.1/include -o build build.o partimpl.o part.o /home/myname/Shore_1.1/lib/libshore.a -lnsl Undefined first referenced symbol in file __10ostrstreamiRC10ostrstream /home/myname/Shore_1.1/lib/libshore.a(errlog.o) ld: fatal: Symbol referencing errors. No output written to build make: *** Error code 1
A: This is a problem with version skew. The Shore binary release 1.1 was created using the include files from release 2.7.1 of libg++. Unfortunately, that makes it incompatible with release 2.7.2 of the library. For now, the only workaround is either to install release 2.7.1 of libg++ or to rebuild Shore from the source release. Release 1.1 is built with the latest versions of the GNU compilers and libraries (gcc 2.7.2.3 and libg++ 2.7.2).
See Also:
B4: Version Skew with TCL
B2: Missing Header Files
Q:
We tried today to compile the sources. Unfortunately, several
include files are missing:
All are detected as missing when make enters src/sm. We reused the first two from the previous version, but could not find the latter two.
Could some kind soul from the developer team send the missing files (or put a complete version on the server)?
A: This sounds like you edited config.h to define MULTI_SERVER (about line 257). This feature is not supported. See the comment at line 163 of config.h. Even if you get the old 1.0 versions of those include files, it won't help you, since this feature is simply not implemented.
Note also that the configuration process has changed radically, so you cannot
use Makefiles generated from the 1.0 distribution to build the 1.1* sources.
B3: Failure Building the Stree Test
Q:
When I tried to compile 'stree' examples in shore-1.1 release, I got
following error.
tokyo:[~/pkg/shore-1.1/examples/stree] pwd /usr/cobase/dongwon/pkg/shore-1.1/examples/stree tokyo:[~/pkg/shore-1.1/examples/stree] make rm -f -f stree.h /usr/cobase/dongwon/pkg/shore-1.1/bin/sdl -f -s stree.sdl -B -L -o stree.h localhost: RPC: Program not registered Server failure in new_svas_client(), reason=10000b fatal error: 1. error in ObjCache.C:3674 Remote operation failed called from: 0) Shore.C:137 1) Shore.C:149 2) meta_init.C:214 2. error in newvas.C:110 Error in Remote Procedure Call called from: 0) ObjCache.C:232 *** Signal 6 - core dumped make: Fatal error: Command failed for target `stree.h'
A: These symptoms seem to indicate that the server was not running when you tried to make stree. At the beginning of the section Building and Running the Example Program of the document Getting Started with Shore you will find the sentence,
To build the example program, you must have a copy of the Shore server running.That's because the SDL compiler stores the compiled SDL interface definitions in the database.
g++ -DDEBUG -O -fno-inline -g -I. -I../../../config -fno-implicit-templates -DSparc -DSOLARIS2 -DSERVER_ONLY -I../include -I../common -I../../common -I../../fc -I../../sthread -I../../sm -I/usr/sww/tcl/include -o shore main.o libserver.a ../common/libcommon.a ../../sm/libsm.a ../../sthread/libst.a ../../common/libcommon.a ../../fc/libfc.a /usr/sww/lib/libtcl.a -lm -lnsl -lsocket -lposix4 Undefined first referenced symbol in file dlsym /usr/sww/lib/libtcl.a(tclLoadDl.o) (symbol belongs to implicit dependency /usr/lib/libdl.so.1) dlopen /usr/sww/lib/libtcl.a(tclLoadDl.o) (symbol belongs to implicit dependency /usr/lib/libdl.so.1) dlerror /usr/sww/lib/libtcl.a(tclLoadDl.o) (symbol belongs to implicit dependency /usr/lib/libdl.so.1) ld: fatal: Symbol referencing errors. No output written to shore
A: This appears to be a problem with version skew between Shore release 1.1 and TCL release 8.0. It is fixed in release 1.1.1. The patch to release 1.1 is as follows: In config/Imake.vars about line 99, change the definition of GlobalLibraries to
#define GlobalLibraries PurifyLibrary -lm -lnsl -lsocket -lposix4 -ldlThen rerun
cd src make make make
===START making all in /home1/marcel/uni/shore/src/sdl flex -+ oql_gram.l cat lex.yy.cc | sed '/^#line/s=lex.yy.cc=oql_lex.C=' > oql_lex.C rm lex.yy.cc g++ -DDEBUG -O -fno-inline -g -I. -I../../config -fno-implicit-templates -DSparc -DSOLARIS2 -Iinclude -I../lil/oc -I../vas/include -I../vas/client -I../common -I../fc -I../sm -I../sthread -c oql_lex.C -o oql_lex.o oql_lex.C: In method `yyFlexLexer::yyFlexLexer(istream *, ostream *)': oql_lex.C:1817: `yy_more_offset' undeclared (first use this function) oql_lex.C:1817: (Each undeclared identifier is reported only once oql_lex.C:1817: for each function it appears in.) oql_lex.C:1817: `yy_prev_more_offset' undeclared (first use this function) gmake[1]: *** [oql_lex.o] Error 1We have flex version 2.5.4, maybe you have an idea what the problem is.
A:
The Shore directory src/sdl/include includes a copy of the
header file FlexLexer.h which is included with flex.
Unfortunately, the version of this file from flex 2.5.2, which is included
with Shore, is incompatible with flex 2.5.4. It was a mistake to include
this file with Shore rather than use the copy installed on your system.
This is fixed in release 1.1.1. You can
work around this problem in release 1.1 simply by copying
FlexLexer.h from
wherever it is installed on your system into
src/sdl/include/FlexLexer.h.
B6: Problem with Make Install
Q:
The source compiles fine. The problem occurs when I'm trying
cd $SRCDIR/src make installwhich results in the following message:
cp -p COPYRIGHT /local.farmer/alain/shore-1.1/installed//COPYRIGHT make: *** No rule to make target `../releasedoc/readme/README.bin', needed by `/ local.farmer/alain/shore-1.1/installed//README'. Stop.the ``releasedoc'' directory doesn't seem to appear in either doc.tar.gz or src.tar.gz. Can't find README.bin either.
A: Sorry about that. This a rather serious bug in the release configuration. Fortunately, the fix is simple.
In the $SRCDIR/src directory, edit Imakefile to remove the last line:
%GEN install_as(,README,../releasedoc/readme/README.bin)Then
make make make installThis is fixed in release 1.1.1.
A: Shore was specifically designed to be portable across many platforms. For example, Shore uses it's own threads package rather than Solaris threads. A port to a new platform requires changing only a small amount of code. Earlier versions of Shore ran successfully on Ultrix, HPUX, AIX, Linux, and some other versions of Unix. The reason the current release is only ``supported'' on Solaris is limitations on resources from the Shore support team -- staff time to merge changes into all versions and test them out and suitable platforms to do the testing.
Release 1.1.1 has been ported to Linux with the help of
Liujian Qian at Penn State University.
P2: HPUX and Irix Ports
Q:
I am an interested reader of your research progress documents
on the shore project. Shore is supposed to be a multiple
platform software, and yet, there is only one Solaris release.
When do you expect another release on another system
(HP-UX or IRIX 5 for instance)?
A: Shore has run ok on HPUX (and, I belive, Irix) in the past. The the two main things preventing me from including ports to multiple platforms in this release were lack of time to update and test all the ports and lack of a convenient machine for doing it. If you'd like to attempt a port, I'll be happy to provide ``support'' in the form advice and answers to your questions.
I recall that our main problem with the HPUX version was that there wasn't
a good g++ on that platform at the time, and the HPUX C++ compiler was
significantly incompatible. If that's changed by now, you shouldn't
have too much trouble.
P3: Windows NT Port
Q:
Is there a shore release available for Windows NT 4.0?
A: Not at this time. However, we have recently received funding from Microsoft to help with an NT port. Work has just started, and I cannot give a precise release date at this time.
The trickiest part is likely to be the threads package, and the diskrw program from the src/sthreads directory. Adapting the threads package from the Solaris X86 version may not be too hard. The result would be that all the Shore threads would run as one NT thread, with non-preemptive scheduling among them. This would not be able to take effective advantage of multi-processor systems, but would be adequate for some purposes. The problem with diskrw is that it uses ``System V-style'' shared memory segments. It might be easier to convert this program from a stand-alone process to another thread (or threads) in the storage manager.
A much more ambitious port would involve replacing Shore threads with NT
threads altogether.
The problem is that Shore threads are non-preemptive, and much of the
code depends on that for correctness.
Replacing Shore threads with NT threads would entail inserting mutual-exclusion
locks in many places.
Unsupported Features
U1: OQL
Q:
We have however one question for which we could not find any answer in the
documentation. In the sdl directory there are various files (scanner, parser,
etc.) for an oql compiler which is also built. However, it is not installed in
the bin directory. Is this because it is still not quite ready or just an
ommission from make install? Also, is the query facility only to be used
stand-alone or can embedded oql be used as well? We could not locate any
information on the query facility in the docs and would be very interested to
use it.
A: The OQL implementation was written by a staff member here, but never completed to the standards of the rest of the project: There is no documentation, and it has not been tested beyond the most minimal of tests. We really don't know how complete it is, and we're afraid we don't have must information beyond what you can learn from browsing through the code. You are welcome to play around with it as see if it is of any use to you. We would be very interested in hearing of your experiences with it.
See Also:
B2: Missing Header Files
U2: Multiple Inheritance in SDL
Q:
The following problem occurs on both version 1.0 and 1.1.
A: There are known problems with the current implementation of multiple inheritance in SDL, so I'm not surprised that you are having problems with it. I will look into the problem further, but for now, your best bet is to use only single inheritance. The problems are rather deep and are not likely to be fixed in the near future. Sorry I cannot be more helpful.
Marvin Solomon / solomon@cs.wisc.edu.