Path: utzoo!attcan!uunet!cs.utexas.edu!milano!cadillac!vaughan@mcc.com
From: vaughan@mcc.com (Paul Vaughan)
Newsgroups: comp.lang.c++
Subject: Re: patches to compile ET++ 2.0 with g++ (incomplete)
Message-ID: <13068@cadillac.CAD.MCC.COM>
Date: 12 Nov 90 19:46:22 GMT
References: <2544@lupine.NCD.COM>
Sender: news@cadillac.CAD.MCC.COM
Reply-To: vaughan@mcc.com (Paul Vaughan)
Organization: MCC VLSI CAD Program
Lines: 29
In-reply-to: rfg@lupine.ncd.com (Ron Guilmette)

From: rfg@lupine.ncd.com (Ron Guilmette)

. . .
   I did this because the -r option of the GNU linker caused me all
   sorts of problems, e.g. the vtables being wrong.


I had problems with that more than a year ago.  I had found cases in
our stuff where having a group of files first compiled into a
relocatable module using -r caused problems where having the same group
of files linked directly into the executable worked fine.  I never
isolated exactly what the problem was and because it was buried in
100K lines of proprietary code, I wasn't able to send it to Tiemann to
get it fixed.  I was able to get around the problem by simply
restructuring our makefiles

   I have since seen numerous patches for the GNU linker posted to
   gnu.utils.bug and one or more of these may alieviate the -r problem(s).
. . .


I haven't checked for patches for this problem, but like you said, I
don't think it's a 4.1 related problem.  Anyway, it's comforting to
know that someone else noticed a problem there, but it's not too nice
to learn that it's still there.


 Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639
 Box 200195, Austin, TX 78720  | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan