home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / sgi / 19027 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  2.0 KB
  1. Xref: sparky comp.sys.sgi:19027 comp.lang.c++:19718
  2. Path: sparky!uunet!munnari.oz.au!metro!basser.cs.su.oz.au!swift!otc!swdev!grahamd
  3. From: grahamd@swdev.research.otca.oz.au (Graham Dumpleton)
  4. Newsgroups: comp.sys.sgi,comp.lang.c++
  5. Subject: Re: C++ templates, link simulation.
  6. Message-ID: <7177@otc.otca.oz>
  7. Date: 21 Jan 93 23:52:17 GMT
  8. References: <14240@ecs.soton.ac.uk>
  9. Sender: news@otc.otca.oz
  10. Organization: Technical Development Group, OTC Australia
  11. Lines: 32
  12.  
  13. In article <14240@ecs.soton.ac.uk>, tpm@ecs (TP Monks) writes:
  14.  > 
  15.  > I'm using cfront on an sgi machine and have come across a problem.
  16.  > It appears that the link simulator is not capable of picking up
  17.  > undefined symbols in libraries.  I had a quick hunt through the doc 
  18.  > but didn't spot any mention of this... perhaps I was too quick..
  19.  >                               
  20.  > In a large project with several libraries, isn't it a reasonable to want to
  21.  > use libraries containing template definitions, and to link into these
  22.  > relying on a common repository to allow undefined symbols to be resolved.
  23.  > 
  24.  > Isn't it a pain to have lots of template definition files kicking around
  25.  > which aren't in a library?
  26.  >                                  
  27.  > Please could someone point me to a ref for this.
  28.  
  29. I assume that compiler you are using is based on AT&T 3.0 or 3.0.1. In both
  30. of these versions the compiler only looks in libraries which are linked on
  31. the command line using an explicit pathname. ie. .../libfoo.a. The compiler
  32. does not resolve a library link directive of the form -lfoo into an
  33. absolute pathname before passing it onto the link simulator. So if you are
  34. using -lfoo then you might want to try giving the pathname to the library
  35. instead. This is a real pain if you wanted to use a shared library. :-(
  36.  
  37. From what I have heard this problem will be fixed in the AT&T version 3.0.2
  38. compiler.
  39.  
  40. BTW, we have hacked our CC script to fix this. If your compiler still uses
  41. a shell script for CC and your interested in the fix then mail me.
  42.  
  43. -- 
  44. Graham Dumpleton (grahamd@swdev.research.otca.oz.au)
  45.