Shore Project Frequently Asked Questions

Index

• Bugs
  • B1: Link Error
  • B2: Missing Header Files
  • B3: Failure Building the Stree Test
  • B4: Version Skew with TCL
  • B5: Version Skew with Flex
  • B6: Problem with Make Install
• Porting Shore to Other Platforms
  • P1: Linux Ports
  • P2: HPUX and Irix Ports
  • P3: Windows NT Port
• Unsupported Features
  • U1: OQL
  • U2: Multiple Inheritance in SDL

    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

• comm.h
• srvid_t.h
• scomm.hh
• ns_client.hh

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

    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.

    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 -ldl

    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 1

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

    cd $SRCDIR/src
    make install

    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.

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)

    make make
    make install

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

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

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

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

1. When an interface inherits from two other interfaces, trying to invoke the second (i.e. the second interface listed in the super-interface list) super-interface's method after casting the sub-interface to the second super-interface will cause a segmentation fault. The attached simple program illustrate this problem.
2. After a reference to a sub-interface is casted to a reference to the sub-interface's second super-interface (either explicitly as shown in the attached program or implicitly by calling a function that has a formal argument of type Ref<2nd-super-interface> with an actual parameter of type <Ref>sub-interface) and the casted referenced is used, a segmentation fault also occurs.

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.

Last Modified: