[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::gnu

Title:GNU Conference
Notice:What's GNU With You?
Moderator:TLE::FOSTER
Created:Tue Mar 18 1986
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:845
Total number of notes:4173

841.0. "C++ and linking image twice" by MGB::GILLOTT (Mark Gillott, 831-3172 (rkg)) Wed Apr 30 1997 06:23

We have a system that uses GCC to cross-compile onto a 68k platform.  We can
also  build  the  system  to  run  in  a  "simulated" enviroment on an alpha
(DUNIX).   The simulator is built with the same GCC compiler, but generating
native alpha code.  Everything works fine.

I've now  made  some changes to the simulator to include some C++ code.  The
new  code  compiles fine on the alpha, but when I come to link the image, it
seems that the linker is doing it twice:

No candidate in current view for "alpha"

======== Rebuilding "alpha" ========
        HUBLIB=/proj1019/hub_common/hub_common_d4.0b044/export/galpha_debug/lib ldfiles
/usr/bin/ld:
Warning: Linking some objects which contain exception information sections
        and some which do not. This may cause fatal runtime exception handling
        problems (last obj encountered without exceptions was gwserno.o).
/usr/bin/ld:
Warning: Linking some objects which contain exception information sections
        and some which do not. This may cause fatal runtime exception handling
        problems (last obj encountered without exceptions was gwserno.o).
========================================================

The image runs fine, it just takes a lot longer to link.  If I remove my new
C++  code,  I'm back to a single link.  After a lot of investigation I found
that  the  linker  did  the first link, then spat out some C code (in /tmp/)
which  it  compiled  and  then  re-did  the  link.  I managed to capture the
temporary C file:

typedef void entry_pt();

extern entry_pt x1 __asm__ ("_GLOBAL_$I$isdnsim_got_data");

entry_pt * __CTOR_LIST__[] = {
	(entry_pt *) 1,
	x1,
	0
};


entry_pt * __DTOR_LIST__[] = {
	(entry_pt *) 0,
	0
};

extern entry_pt __main;
entry_pt *__main_reference = __main;

Now "isdnsim_got_data"  is a "C" function in my C++ module.  I've used it as
a means to get from external C functions into one of my C++ function. 

I'm not  a  C++  programmer  (that  may  be  the problem...), I just cobbled
together  this  new  module  from  an existing one that gets used on the 68k
platform (a cut-n-past job).

Does anyone have any idea whats going on here?.  Any help appreciated, 

Mark

T.RTitleUserPersonal
Name
DateLines
841.1versionsmgb.rkg.dec.com::GILLOTTMark Gillott, 831-3172 (rkg)Wed Apr 30 1997 06:306
Forgot to  indicate  the  version  in  use.  Because of the way we build the
system  (we're  using clearcase), the C code gets compiled using GCC V2.6.0,
the C++ code gets built using GCC V2.7.2.1.  Soon it will be all built using
GCC V2.7.2. Does this make any difference?. 

Mark
841.2SPECXN::DERAMODan D'EramoWed Apr 30 1997 12:249
        Often C++ is linked in multiple passes, where the first one
        finds undefined symbols (from templates or from initializing
        or destroying objects with static storage duration) which the
        compiler drivers uses to create and compile template
        instantiations or whatever is needed to resolve the reference.
        
        What does your new code look like?
        
        Dan
841.3mgb.rkg.dec.com::GILLOTTMark Gillott, 831-3172 (rkg)Wed Apr 30 1997 12:5112
Rather than post the new code, you can get the .CXX & .HXX from MGB""::

Directory MGB""::SYS$SYSDEVICE:[FAL$SERVER]

ISDNSIM.CXX;1             50             [376,373]             (RWED,RWED,RE,)
ISDNSIM.HXX;1             41             [376,373]             (RWED,RWED,RE,)

As I say, I took an existing C++ module and just hacked away...

Thanks for any help, 

Mark
841.4SPECXN::DERAMODan D'EramoThu May 01 1997 13:0620
        'log' is a bad name for a global because it conflicts with the
        log function in <math.h>.
        
        The __CTOR_LIST__ array in .0 might be running the XXLOG::XXLOG()
        constructor to construct the object named 'log' -- perhaps the
        name _GLOBAL_$I$isdnsim_got_data was generated based on the
        first definition in the file instead of the filename or the
        object 'log' being constructed.
        
        If so, and if 'unsf' is a typedef of some unsigned integral
        type, then try the following:
        
        	remove member 'sep' from class XXLOG
        	get rid of the explicit XXLOG() constructor in ISDNSIM.HXX
        	change the three "= sep;" assingments in ISDNSIM.CXX
        		to "= ' ';" instead
        
        All this is just a guess.
        
        Dan
841.5Bingo!, buy that man a beer. mgb.rkg.dec.com::GILLOTTMark Gillott, 831-3172 (rkg)Thu May 01 1997 13:413
Many thanks Dan, that did the trick.

Mark