- From: Charles-Edouard Ruault <ce_at_idtect.com>
- Date: Fri, 02 May 2003 14:05:02 +0200
David Schleef wrote: >On Tue, Apr 29, 2003 at 05:16:55PM +0200, Charles-Edouard Ruault wrote: > > >>>Using gcc 3.2.3/ld 2.13.90.0.18 to compile the comedilib cvs, I don't see >>>any of the problems you are reporting. Maybe it is a gcc 3.2.2 bug? >>> >>> >>> >>This is strange ... since from what i've seen the problem appears after >>the ld phase ... the simbols are present in the .o and disappear after >>the linkage. >> >> > >This is correct behavior, since Comedi uses a link map, and adds >versions to most symbols. Anything that doesn't match comedi_* >or _comedi_* are internally resolved and removed from the >dynamic symbol map, so they can't interfere with symbols from >other libraries. It's a somewhat common procedure, but I'm >willing to believe that Comedilib does it slightly wrong. However, >since it can't be reproduced, I'd likely look elsewhere for >problems first. > > > >dave... > > > Hi David, thanks for the reply. I guess i was not clear ... the symbols i'm talking about are the comedi_* symbols :-( the one that i find in my .so are the ones with version numbers ( ie comedi_*_at_version ), it's missing all the comedi symbols which don't have a version number. This causes all the applications that link against comedilib to fail. For example in the library compiled/linked with gcc 2.95 / ld 2.12.90.0.1 i have comedi_open_at_v0.7.18 comedi_open in the one compiled with gcc 3.2.2 / ld 2.13.90.0.18 i have only comedi_open_at_v0.7.18 comedi_open is missing. This prevents the "demo" and other programs from compiling since they're looking for the symbol name without the version. -- Charles-Edouard Ruault Idtect SA http://www.idtect.com +33-1-42-81-81-84
Received on 2003-05-02Z11:05:02