Still not in bed, (but already sleeping, have to rise in four hours...),

Where does this leave me as regards to building packages? I can't
possiby edit all main() functions in all c++ projects in KDE... (or even
if the only thing I want to do is to play with QT). Maybe if I hire a
kid or a student.

How about libraries? I assume this is a once-per-app case, so it won't
affect libraries.

Is this only libg++.so? If so will I get a working one soon (please...)
If it is the runtime linker - will it be fixed soon?

Thanx anyway,

Harald.


> -----Original Message-----
> From:	Simon Burge [SMTP:simonb@telstra.com.au]
> Sent:	13. august 1998 02:11
> To:	Harald Bjoroy
> Cc:	'port-pmax@netbsd.org'
> Subject:	Re: C++ compiler wackyness. 
> 
> Ok, I've got a solution that works (from Michael Hitch) that I won't
> even pretent to understand.  Add:
> 
> 	/*
> 	 * Workaround an ld shared library bug:  define these dummy
> entries to
> 	 * satisify __do_global_ctors() instead of the entries in
> libg++.so.
> 	 */
> 	int *__CTOR_LIST__[] = {0};
> 	int *__DTOR_LIST__[] = {0,0};
> 
> somewhere.  With these couple of lines, the main.cpp does nothing (not
> even a core dump :), and the hello.c prints "hello world" - both of
> which are good things!  Here's a snippet from what Michael explains is
> wrong:
> 
> 	defined dummy __CTOR_LIST__ and __DTOR_LIST__ arrays to get
> 	around the problem of ld not creating relocation information
> 	for the ones defined in the shared libraries.  [Even if ld
> 	did generate the correct relocation information, I suspect
> 	the way these are being used is incorrect.
> 
> FWIW, my -current system (as of late May) doesn't even compile the
> test
> program.  I'll try upgrading it to a current -current and see if I can
> at least compile the program.
> 
> Simon.