From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19228 invoked by alias); 23 Apr 2004 23:41:57 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 19160 invoked from network); 23 Apr 2004 23:41:54 -0000 Received: from unknown (HELO bluesmobile.specifixinc.com) (64.62.200.227) by sources.redhat.com with SMTP; 23 Apr 2004 23:41:54 -0000 Received: from localhost.localdomain (bluesmobile.corp.specifixinc.com [10.0.0.1]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 2CA0D1650E; Fri, 23 Apr 2004 16:41:54 -0700 (PDT) Subject: Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols From: Jim Wilson To: Arnaud Charlet Cc: "H. J. Lu" , gcc-patches@gcc.gnu.org, David Mosberger , gcc@gcc.gnu.org In-Reply-To: <20040423090751.B3740@dublin.act-europe.fr> References: <4085A6D9.2000003@specifixinc.com> <20040420232802.GB657@lucon.org> <16517.46034.449201.262407@napali.hpl.hp.com> <20040420234152.GA966@lucon.org> <16517.46957.842543.155986@napali.hpl.hp.com> <1082507163.1062.51.camel@leaf.tuliptree.org> <20040421055729.GA6998@lucon.org> <20040421090400.A8193@dublin.act-europe.fr> <20040421143327.GA15381@lucon.org> <1082684237.1052.57.camel@leaf.tuliptree.org> <20040423090751.B3740@dublin.act-europe.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 24 Apr 2004 00:41:00 -0000 Message-Id: <1082763733.1163.62.camel@leaf.tuliptree.org> Mime-Version: 1.0 X-SW-Source: 2004-04/txt/msg01165.txt.bz2 I find this message to be very puzzling. The only way I can interpret it is as an insult. However, I am trying to help you by investigating and solving an Ada related problem. You should not be insulting someone who is trying to help you. Maybe there is a language related issue here, or maybe you are venting general frustrations or something, or maybe you don't understand what I am trying to accomplish here. By the way, what I am trying to do here is reconcile differing statements made by you and HJ. Your statements conflict. Repeating the conflicting statements does not solve anything. What we need is to investigate the issues without preconceptions, and without taking sides. That is what I am trying to do. Since, I have mostly confirmed that your statements are correct, I can't understand why you are responding to me this way. On Fri, 2004-04-23 at 00:07, Arnaud Charlet wrote: > gthr-gnat.c is no longer needed at all, except on VMS. I know. You said that in an earlier message, and I agreed with you. So why are restating the obvious? That could be misconstrued as an insult. > No, you missed the fact that gthr-gnat.c is using pointers to functions, You are mistaken. I did not miss this fact. The only way I could have missed this fact is if I was incompetent, and I am not incompetent. If you had asked if maybe possibly I had accidentally missed something obvious, then that would have been OK. I am human, and I do make mistakes. But to state as a fact that I missed something obvious is to make a strong implication that I am incompetent, and hence the only way I can interpret the above statement is as an insult. I am offended by it, and hope that you do not make this mistake again. > Because no file is referencing these symbols. Do you know this for a fact? Or are you making an logical assumption? If you are making a logical assumption, then I would agree with you. However, statements from HJ contradict this. It is possible that there is some obscure subtle interaction that is IA-64 specific and which has gone unnoticed so far. Since I am trying to keep an open mind, I must admit that this is a possibility however remote. It is also possible that HJ made a mistake. The only way to be sure if to perform an experiment. That is what I am doing. Performing an experiment to verify the facts. It is the right thing to do in this case. > No, gthr-gnat.c should only be there at this point for VMS. It would be > removed for all other targets, not added. You are confusing issues here. That gthr-gnat.c should only be there for VMS is true. However, if you look at the sources, you can clearly see that it is there for all targets except ia64-linux. Therefore, we have an obvious problem, because ia64-linux is different from other targets when it should not be. This needs to be investigated. That is what I am doing. Even if it is wrong for ia64-linux to use gthr-gnat.c, it might be necessary to add it to resolve this inconsistency. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com