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 |
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.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
841.1 | versions | mgb.rkg.dec.com::GILLOTT | Mark Gillott, 831-3172 (rkg) | Wed Apr 30 1997 06:30 | 6 |
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.2 | SPECXN::DERAMO | Dan D'Eramo | Wed Apr 30 1997 12:24 | 9 | |
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.3 | mgb.rkg.dec.com::GILLOTT | Mark Gillott, 831-3172 (rkg) | Wed Apr 30 1997 12:51 | 12 | |
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.4 | SPECXN::DERAMO | Dan D'Eramo | Thu May 01 1997 13:06 | 20 | |
'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.5 | Bingo!, buy that man a beer. | mgb.rkg.dec.com::GILLOTT | Mark Gillott, 831-3172 (rkg) | Thu May 01 1997 13:41 | 3 |
Many thanks Dan, that did the trick. Mark |