🚀 go-pugleaf

I am running gcc 2.2.2 on the rs6000 and on the NeXT and have encountered this bug  
in both environments.

I have a large C++ application that has been successfully compiled and run using  
cc++ (1.36.4) on the NeXT. When compiled with 2.2.2, however, the application  
crashes during execution of one of the constructors for a global object. In trying  
to find out what was happening, I printed out the CTOR_LIST, from within  that  
constructor and correlated it back to a dump generated by the "nm -p" command. When  
the application was compiled with 1.36.4, this is what I got:

INIT 3a242	0003a242 T __GLOBAL_$I$theErrorObject
INIT 3997a	0003997a T __GLOBAL_$I$__8WSString
INIT 38198	00038198 T __GLOBAL_$I$theDBAManager
INIT 34c1c	00034c1c T __GLOBAL_$I$_DBTransactionData$theTableInitialized
INIT 33906	00033906 T __GLOBAL_$I$_DBChangeData$theTableInitialized
INIT 32b84	00032b84 T __GLOBAL_$I$_DBStopData$theTableInitialized
INIT 304d6	000304d6 T __GLOBAL_$I$_DBRouteData$theTableInitialized
INIT 2dbb8	0002dbb8 T __GLOBAL_$I$_DBDeliveryData$theTableInitialized
INIT 2a8d4	0002a8d4 T __GLOBAL_$I$_DBItemData$theTableInitialized
INIT 2829e	0002829e T __GLOBAL_$I$_DBProductData$theTableInitialized
INIT 265a8	000265a8 T __GLOBAL_$I$_DBClientData$theTableInitialized
INIT 22ae8	00022ae8 T __GLOBAL_$I$theDBManager
INIT 1f680	0001f680 T __GLOBAL_$I$_PSDeliveryRecord$newID
INIT 17424	00017424 T __GLOBAL_$I$thePSManager
INIT 17170	00017170 T __GLOBAL_$I$__6PSTask
INIT 15c9c	00015c9c T __GLOBAL_$I$__10PSStopTask
INIT 13d86	00013d86 T __GLOBAL_$I$__11PSRouteTask
INIT 109ea	000109ea T __GLOBAL_$I$__14PSDeliveryTask
INIT be12	0000be12 T __GLOBAL_$I$__10PSItemTask
INIT 9742	00009742 T __GLOBAL_$I$__13PSProductTask
INIT 748a	0000748a T __GLOBAL_$I$__12PSClientTask

When, however the application was compiled with 2.2.2, this is what I got:

INIT 7f3a	00007f3a T __GLOBAL_$I$__12PSClientTask
INIT a210	0000a210 T __GLOBAL_$I$__13PSProductTask
INIT c904	0000c904 T __GLOBAL_$I$__10PSItemTask
INIT 11404	00011404 T __GLOBAL_$I$__14PSDeliveryTask
INIT 14770	00014770 T __GLOBAL_$I$__11PSRouteTask
INIT 166ac	000166ac T __GLOBAL_$I$__10PSStopTask
INIT 17c00	00017c00 T __GLOBAL_$I$__6PSTask
INIT 17f5c	00017f5c T __GLOBAL_$I$thePSManager
INIT 1a8f2	0001a8f2 T __GLOBAL_$I$_16PSDeliveryRecord$newID
INIT 22372	00022372 T __GLOBAL_$I$theDBManager
INIT 25644	00025644 T __GLOBAL_$I$_12DBClientData$theTableInitialized
INIT 26fb2	00026fb2 T __GLOBAL_$I$_13DBProductData$theTableInitialized
INIT 291ee	000291ee T __GLOBAL_$I$_10DBItemData$theTableInitialized
INIT 2be8a	0002be8a T __GLOBAL_$I$_14DBDeliveryData$theTableInitialized
INIT 2e340	0002e340 T __GLOBAL_$I$_11DBRouteData$theTableInitialized
INIT 305ee	000305ee T __GLOBAL_$I$_10DBStopData$theTableInitialized
INIT 312be	000312be T __GLOBAL_$I$_12DBChangeData$theTableInitialized
INIT 32446	00032446 T __GLOBAL_$I$_17DBTransactionData$theTableInitialized
INIT 35c40	00035c40 T __GLOBAL_$I$theDBAManager
INIT 37720	00037720 T __GLOBAL_$I$__8WSString
INIT 38ce6	00038ce6 T __GLOBAL_$I$theErrorObject

You will notice that the constructors are being called in exactly the reverse  
order. Investigating the dependencies of the constructors, I believe that 2.2.2 is  
wrong and should be executing the constructors in reverse order. 


For now, I intend to patch collect2.c to remedy the problem. Could some please let  
me know if either my interpretation of the problem is wrong, or my approach to the  
fix is flawed.


Marcel Samek
marcel%mlogic.uucp@usc.edu