home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / linux / 23256 < prev    next >
Encoding:
Text File  |  1993-01-08  |  2.6 KB  |  58 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!wupost!newsfeed.rice.edu!rice!corywest
  3. From: corywest@is.rice.edu (Cory West)
  4. Subject: Re: libg++.a problem with Regex.o
  5. In-Reply-To: dingbat@diku.dk's message of 8 Jan 93 10:30:50 GMT
  6. Message-ID: <CORYWEST.93Jan8124821@brazos.is.rice.edu>
  7. Sender: news@rice.edu (News)
  8. Organization: Well, none really, but I know where my socks are!
  9. References: <1993Jan8.103050.18355@odin.diku.dk>
  10. Date: Fri, 8 Jan 1993 18:48:21 GMT
  11. Lines: 45
  12.  
  13. In article <1993Jan8.103050.18355@odin.diku.dk> dingbat@diku.dk 
  14. (Niels Skov Olsen) writes:
  15.  
  16. >  A slight problem with g++ 2.3.3 and the latest libs and the binutils
  17. >  found on the latest hlu base disks.
  18. >  When I compile this program:
  19. [...]
  20. >  ld gives me these errors:
  21. >  Undefined symbol re_compile_pattern(const char *, int, re_pattern_buffer *)
  22. [...]
  23. >  I have checked that these symbols are in fact in libg++.a with nm.
  24.  
  25.     This is the same question that I have been asking without
  26. much luck,  I have two suspicions and I'm not sure which one is
  27. right.  The last time I tried to build libg++ under linux, all of
  28. it would compile, except for the regex stuff.  I believe that the
  29. 'fix' for it at that point was to leave regex out, but I'm not sure.
  30. It's quite possible that this is still the case and that regex is
  31. not in the current libg++ (meaning that Strings are also not usable).
  32.  
  33.     The other possibility is that HJ built libg++ with a cross compiler
  34. of the DEC.  If he is using a compiler older than gcc-2.3.3, then the
  35. symbol mangling for some virtual class functions has been changed
  36. and the symbols will not match. 
  37.  
  38.     At any rate, here is the fix for both problems:  recompile
  39. libg++ under linux with g++ 2.3.3 and make sure that all parts of
  40. it compile.  This is exactly what I am trying to do, with the inention
  41. of correcting and problems that still may or may not exist in the
  42. regex code for linux.  
  43.     The problem that I am having is that the (!#$@#$) configuration 
  44. setup for libg++-2.3 doesn't seem to work with GNU sed 1.09 or GNU sed 
  45. 1.13.  I'm building libg++ of a sun right now so that I can follow the
  46. configuration and see what I have to do on the linux machine to get it go
  47. (I'll be the  first to admit that I can't debug cryptic sed statements).  
  48. If anyone would like to send me an alternate version of sed, or point me 
  49. to different linux compatible source (I don't want to port a different sed, 
  50. too), I'd be happy to try it.
  51.  
  52.     I'm in the process of reporting things to Cygnus and the FSF
  53. and working out what I can to make libg++ more linux friendy.  If you
  54. want to help send me email.  I might be able so that I can export an
  55. NFS partition to someone with the stuff on it.
  56.  
  57.                 Cory West
  58.