home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!csn!qwerty-gw.fsl.noaa.gov!kestrel.fsl.noaa.gov!bear
- From: bear@kestrel.fsl.noaa.gov (Bear Giles)
- Subject: Re: Weird problem under Sun/C++
- Message-ID: <1992Dec30.182156.16470@fsl.noaa.gov>
- Sender: news@fsl.noaa.gov (USENET News System)
- Organization: Forecast Systems Labs, NOAA, Boulder, CO USA
- References: <1992Dec30.003304.4131@fsl.noaa.gov>
- Date: Wed, 30 Dec 1992 18:21:56 GMT
- Lines: 40
-
- Since several people have suggested a problem with specifying the
- library, let me make it clear that this is _not_ the cause.
-
- % cc -o pgm pgm.o sagebrush.a
-
- causes the error
-
- TupleFile::find ([4 lines of parameters deleted]) not found
-
- However, if we extract the object file containing TupleFile::find()
- from the library and attempt to link:
-
- % ar r sagebrush.a tuple.o
- % cc -o pgm pgm.o sagebrush.a tuple.o
-
- the "TupleFile::find () not found" error message goes away, although
- we now get a large number of "multiply defined" errors.
-
- (The object file must follow the library since the object file is
- pretty deep in the call tree of the RDBMS).
-
- The fact that the link works with an object file but not with the
- same object file embedded in a library is what worries us. We could
- make a workaround, but what else will break? (BTW, I can link without
- problems, but my coworker can't even though we are using the same
- NSF-mounted compiler!)
-
- FYI, The exact form of TupleFile::find() provided by nm++ is:
-
- 00002794 T TupleFile::find(int(*)(unsigned const char* const,unsigned const
- char* const),unsigned const char* const,long&,DBStatus(*)
- (unsigned const char* const,unsigned const char* const,const
- long,const long,unsigned char*),unsigned char*)
- [_find__9TupleFileFPFCPCUcT1_iCPCUcRlPFCPCUcT1ClT3PUc_8DBStatusPUc]
-
- (Note the mangled name!)
-
-
- Bear Giles
- bear@fsl.noaa.gov
-