From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12879 invoked by alias); 16 Jan 2012 09:31:14 -0000 Received: (qmail 12871 invoked by uid 22791); 16 Jan 2012 09:31:13 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mx02.qsc.de (HELO mx02.qsc.de) (213.148.130.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Jan 2012 09:30:59 +0000 Received: from mail.yager.de (mail.yager.de [212.60.243.130]) by mx02.qsc.de (Postfix) with ESMTP id F36DE1EF54 for ; Mon, 16 Jan 2012 10:30:57 +0100 (CET) Received: from hermes.corp.yager.de ([fe80::8de:db45:75d8:9f78]) by hermes.corp.yager.de ([fe80::8de:db45:75d8:9f78%12]) with mapi; Mon, 16 Jan 2012 10:30:57 +0100 From: Markus Henschel To: "gcc-help@gcc.gnu.org" Date: Mon, 16 Jan 2012 10:47:00 -0000 Subject: RE: freebsd gcc cross compiler creates binaries that crash when using c++ exceptions Message-ID: References: <4F0F2E4B.8030305@redhat.com> <4F100A13.1040104@redhat.com> In-Reply-To: <4F100A13.1040104@redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2012-01/txt/msg00098.txt.bz2 > On 01/12/2012 07:25 PM, Markus Henschel wrote: > >> On 01/12/2012 06:55 PM, Markus Henschel wrote: > >>> Is there some flaw in the way I built this toolchain? Where could I > >> try to start looking for the source of the problem? I can add all > >> sorts of other outputs from the created toolchains if it helps. > >> > >> I wouldn't put the installed compiler (i.e. the prefix=3D) into the > >> same directory as the sysroot. The sysroot should be a clean & > >> pristine copy of the root directories on your target. It isn't > >> written to, only read from. Once you have done your make install > you > >> should have a set of target libraries that work in your prefix/lib. > > > > I did this because I had problems building a relocatable toolchain. > > When "prefix" was different from "sysroot" the compiler used an > > absolute path to some files in sysroot. >=20 > Well, surely that's exactly what you want, otherwise how could it ever > find sysroot? > >> You can't mix the c++ and libgcc libraries you just built with the > >> versions on your target system. It should be possible to install > the > >> newly-created ones side by side with the versions on your target > >> system. > > > > May be I should explain better: >=20 > > Usually I link libgcc and libstdc++ statically to not interfere with > > whatever is installed on the target system. >=20 > This is a bad idea: statically-linked libgcc doesn't play well with any > shared libraries. In our case this is desired. We do not link any C++ libraries because the t= arget systems OS (which is not under our control) is ancient as well as the= default system compilers. So all we use is libc and some other libraries w= ith C-API to be able to upgrade our compilers and dependencies as we like. = But as far as I can see it isn't part of the problem. The simple test case = only linked to libgcc and libstdc++ (and libc,libm). > > Because I got these crashes I started playing around. I linked my > test > > app dynamically against libgcc.so and libstdc++.so. Then I copied my > > test app to the target system and used the installed versions of > these > > libraries. This seems to work. I just did this by accident. This > > brought me to my conclusion that something must be wrong with these > > libs that I created while building the cross compiler. >=20 > Perhaps so. >=20 > > I should also mention that the versions of the compiler support > > libraries on the target system come from gcc 4.2.1 so they are > > "similar enough" to what my binaries needed. > > > > So I started to build my toolchain on the target system as a native > > compiler with exactly the same configure switches. This also produced > > working versions of libgcc and libstdc++. >=20 > As you'd expect. >=20 > Like I said, you've got to break out the debugger to find out what is > wrong. >=20 > Andrew. What I did so far was attaching gdb and seeing that it crashes in libgcc in= __cxa_end_catch. I guess I'll have to build libgcc with debug symbols then. Thanks for the tips so far. Any further input is welcome. Markus.