From owner-freebsd-toolchain@FreeBSD.ORG Sun Feb 3 20:45:17 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 71D18CA9; Sun, 3 Feb 2013 20:45:17 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 2FCFE9AA; Sun, 3 Feb 2013 20:45:17 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:a952:1158:bfb6:380] (unknown [IPv6:2001:7b8:3a7:0:a952:1158:bfb6:380]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 33E145C5A; Sun, 3 Feb 2013 21:45:15 +0100 (CET) Message-ID: <510ECC5A.3010600@andric.com> Date: Sun, 03 Feb 2013 21:45:14 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Yamaya Takashi Subject: Re: [patch]r246028, libcxxrt's Version.map is broken References: <510AF84C.2080702@kbh.biglobe.ne.jp> <510BDF20.8010502@kbh.biglobe.ne.jp> In-Reply-To: <510BDF20.8010502@kbh.biglobe.ne.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 20:45:17 -0000 On 2013-02-01 16:28, Yamaya Takashi wrote: > On 2013/02/01 08:03, Yamaya Takashi wrote: >> After r246028, make buildworld with -stdlib=libc++ -std=c++11 is failed. >> libcxxrt's Version.map is broken, because some needed symbols are removed. > Add missing symbol and refine. Thank you very much. I have verified that your patch makes building world with -stdlib=libc++ work. I have committed it in r246297. -Dimitry From owner-freebsd-toolchain@FreeBSD.ORG Sun Feb 3 22:33:57 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A97D3B8; Sun, 3 Feb 2013 22:33:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 19315DAD; Sun, 3 Feb 2013 22:33:57 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id ACC8E5C5A; Sun, 3 Feb 2013 23:33:55 +0100 (CET) Message-ID: <510EE5D2.4050409@FreeBSD.org> Date: Sun, 03 Feb 2013 23:33:54 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Pedro Giffuni , Andriy Gapon Subject: Re: base gcc and _GLIBCXX_USE_C99 References: <5106953E.2020907@FreeBSD.org> <510BBCAD.3070705@FreeBSD.org> <510BD53D.1070209@FreeBSD.org> In-Reply-To: <510BD53D.1070209@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------070202030408030402030001" Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 22:33:57 -0000 This is a multi-part message in MIME format. --------------070202030408030402030001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2013-02-01 15:46, Pedro Giffuni wrote: > On 02/01/2013 08:01, Andriy Gapon wrote: >> on 28/01/2013 17:11 Andriy Gapon said the following: >>> I wonder why the following is the case for the base gcc. >>> /usr/include/c++/4.2/bits/c++config.h: >>> >>> /* Define if C99 functions or macros from , , , >>> , and can be used or exposed. */ >>> /* #undef _GLIBCXX_USE_C99 */ >>> >>> Because of this undef there is no e.g. std::strtoll(). >>> Ditto for other things in stdlib.h. >>> > I looked at this very briefly and it looks like it would fix a nasty > issue we have been working around in OpenOffice. > > I suggest to enable it first on a gcc port though (it's tied to a > configure flag, but don't remember which). I had a bit more in-depth look at our current libstdc++ configuration. I took the original gcc 4.2.1 release tarball, modified a few autoconf related scripts to cope with "freebsd10.0" being the current version, and did a full three-stage build, though only targeting C and C++. The libstdc++ configure script in 4.2.1 does detect a few new features that are not in our shipping config.h, but is does not detect any different settings regarding C99. The reason it does not turn on _GLIBCXX_USE_C99, is that not all of the C99 requirements are met, specifically checks fail: checking for ISO C99 support in ... yes checking for ISO C99 support in ... no checking for ISO C99 support in ... yes checking for ISO C99 support in ... yes checking for ISO C99 support in ... yes checking for fully enabled ISO C99 support... no The exact failure testcase goes like this: configure:7435: checking for ISO C99 support in configure:7492: /home/dim/obj/gcc-4.2.1/./gcc/xgcc -shared-libgcc -B/home/dim/obj/gcc-4.2.1/./gcc -nostdinc++ -L/home/dim/obj/gcc-4.2.1/i386-unknown-freebsd10.0/libstdc++-v3/src -L/home/dim/obj/gcc-4.2.1/i386-unknown-freebsd10.0/libstdc++-v3/src/.libs -B/home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/bin/ -B/home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/lib/ -isystem /home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/include -isystem /home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/sys-include -c -g -O2 conftest.cc >&5 conftest.cc: In function 'int main()': conftest.cc:41: error: 'clogf' was not declared in this scope conftest.cc:47: error: 'cpowf' was not declared in this scope conftest.cc:54: error: 'clog' was not declared in this scope conftest.cc:60: error: 'cpow' was not declared in this scope conftest.cc:64: error: 'ccosl' was not declared in this scope conftest.cc:65: error: 'ccoshl' was not declared in this scope conftest.cc:66: error: 'cexpl' was not declared in this scope conftest.cc:67: error: 'clogl' was not declared in this scope conftest.cc:68: error: 'csinl' was not declared in this scope conftest.cc:69: error: 'csinhl' was not declared in this scope conftest.cc:71: error: 'ctanl' was not declared in this scope conftest.cc:72: error: 'ctanhl' was not declared in this scope conftest.cc:73: error: 'cpowl' was not declared in this scope configure:7498: $? = 1 So until we actually implement and declare those functions, we should probably not enable _GLIBCXX_USE_C99_COMPLEX and _GLIBCXX_USE_C99. I have attached a diff of the other changes that can be applied on our current libstdc++ config file, as detected by the configure script. I will probably commit that soonish, if there are no objections. As to the missing complex functions, I am not sure. Maybe these can be imported from somewhere else, e.g. NetBSD? This is probably something to ask the lib/msun specialists... -Dimitry --------------070202030408030402030001 Content-Type: text/x-diff; name="libstdcxx-reconfig-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="libstdcxx-reconfig-1.diff" Index: gnu/lib/libstdc++/config.h =================================================================== --- gnu/lib/libstdc++/config.h (revision 246297) +++ gnu/lib/libstdc++/config.h (working copy) @@ -22,7 +22,7 @@ #define HAVE_ATAN2F 1 /* Define to 1 if you have the `atan2l' function. */ -/* #undef HAVE_ATAN2L */ +#define HAVE_ATAN2L 1 /* Define to 1 if you have the `atanf' function. */ #define HAVE_ATANF 1 @@ -67,7 +67,7 @@ #define HAVE_EXPF 1 /* Define to 1 if you have the `expl' function. */ -/* #undef HAVE_EXPL */ +#define HAVE_EXPL 1 /* Define to 1 if you have the `fabsf' function. */ #define HAVE_FABSF 1 @@ -100,7 +100,7 @@ #define HAVE_FMODF 1 /* Define to 1 if you have the `fmodl' function. */ -/* #undef HAVE_FMODL */ +#define HAVE_FMODL 1 /* Define to 1 if you have the `fpclass' function. */ /* #undef HAVE_FPCLASS */ @@ -134,7 +134,7 @@ #define HAVE_HYPOTF 1 /* Define to 1 if you have the `hypotl' function. */ -/* #undef HAVE_HYPOTL */ +#define HAVE_HYPOTL 1 /* Define to 1 if you have the `iconv' function. */ /* #undef HAVE_ICONV */ @@ -293,7 +293,7 @@ #define HAVE_SQRTF 1 /* Define to 1 if you have the `sqrtl' function. */ -/* #undef HAVE_SQRTL */ +#define HAVE_SQRTL 1 /* Define to 1 if you have the header file. */ #define HAVE_STDBOOL_H 1 @@ -304,6 +304,12 @@ /* Define to 1 if you have the header file. */ #define HAVE_STDLIB_H 1 +/* Define if strerror_l is available in . */ +/* #undef HAVE_STRERROR_L */ + +/* Define if strerror_r is available in . */ +#define HAVE_STRERROR_R 1 + /* Define to 1 if you have the header file. */ #define HAVE_STRINGS_H 1 @@ -316,6 +322,9 @@ /* Define to 1 if you have the `strtold' function. */ #define HAVE_STRTOLD 1 +/* Define if strxfrm_l is available in . */ +/* #undef HAVE_STRXFRM_L */ + /* Define to 1 if you have the header file. */ #define HAVE_SYS_FILIO_H 1 --------------070202030408030402030001-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Feb 4 03:09:12 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 76296514 for ; Mon, 4 Feb 2013 03:09:12 +0000 (UTC) (envelope-from giffunip@yahoo.com) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) by mx1.freebsd.org (Postfix) with SMTP id F185A99A for ; Mon, 4 Feb 2013 03:09:11 +0000 (UTC) Received: from [98.139.212.150] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 04 Feb 2013 03:09:11 -0000 Received: from [98.139.212.219] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 04 Feb 2013 03:09:11 -0000 Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 04 Feb 2013 03:09:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 109245.76782.bm@omp1028.mail.bf1.yahoo.com Received: (qmail 13357 invoked by uid 60001); 4 Feb 2013 03:09:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1359947351; bh=H+qEPgud5hWVT4va2oul3ZUb2B12PN5VcEJ62iXSPzw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=H55qKnL5c8SPf1QoGt4s/FbUxoZxbrvPWAsFZzHbXS+FmsorPSbOsJT9Lx1IyW2LEJ5nTIbm+AfRQBpRyX5//UyjxzNXGlyA4RqDzejWPTKK+bGKkxHp2kIhuyIugdGSTHYuhlysEFvR0fVzjeQ8JzHgOlHSBpNp8XhKdvHhvVM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PBlgq0k/SFoKbCXBYNuFNyb5uVtySvErG6e1xJNozGy0d0ZKJXcqEmJnTD69jUt3s7v7AVFQbXfZOdm3D2n6GE1M/abEEOf0DZWN9iiXFGKzNG154Jbln+XLE9MXTd3/82w6s0MYXyza3bB9nkcJP9wLbQeGvy907rRSsg323CQ=; X-YMail-OSG: xQE4AwEVM1megDpnoljjioory5NVUaqZS3BC3VBQ9.VKypN sQJa8i198lZvYxKXMBIBexk45lwDGSHzhpivGl03ZHiCXgA2ud5zZznVsFM. xm2ZJQKxewfXpDQ7ZoHLaBDCdb3bU976NufxAoZ0VADBuIlTCxY7v5EenFyi nMG3I4_dsTiVFTVsLGmrNzjzL2lME8AKqQ0hI2X_n_wg1rgiMFQgKlcPHkGf zLM49IOooX0BPbNphWBuLChHkQ4IiE_zzy01gQbELvsB2Q5gDMUfUsAsqh8v wG82w6NEdMn41JZXGWxFcCYlk4aylpMjevxwB710S8NafXbUseV8IY5HFeOj 5M4zrxp9OZdgV4_q6.FATgZXerPBlymh8CNcmbJoNykahYkCAbO8fhCG1Hnz w5gurVSMpX36o3FPQipqAm22w93qVUdr2Coq3ZNFs9n63sKea4BnrGLQuEtG hD7omAMabPGiUhJ6Pf9pj0RNUPk0QnaM4ifR0g4E1_ocvJhr0v3cQwDokF4l 9q4T6IXBO8CFzV.XhMBRMWFc1ImXXtFLafSntu14QxpiSRlhF7p_sS7ce8zE 3omHE1rJJToloaZXPGNmAInP9pkiM8gdd_HtmnkqJu875ULTzP1YD7fU2wju OcOJxBCFp7r6qSpAGBEw6zJvP Received: from [200.118.157.7] by web162105.mail.bf1.yahoo.com via HTTP; Sun, 03 Feb 2013 19:09:10 PST X-Rocket-MIMEInfo: 001.001, SGVsbG8gRGltaXRyeTsKCgotLS0tLSBNZXNzYWdnaW8gb3JpZ2luYWxlIC0tLS0tCj4gRGE6IERpbWl0cnkgQW5kcmljwqAKCj4gSSBoYWQgYSBiaXQgbW9yZSBpbi1kZXB0aCBsb29rIGF0IG91ciBjdXJyZW50IGxpYnN0ZGMrKyBjb25maWd1cmF0aW9uLgo.IAo.IEkgdG9vayB0aGUgb3JpZ2luYWwgZ2NjIDQuMi4xIHJlbGVhc2UgdGFyYmFsbCwgbW9kaWZpZWQgYSBmZXcgYXV0b2NvbmYKPiByZWxhdGVkIHNjcmlwdHMgdG8gY29wZSB3aXRoICJmcmVlYnNkMTAuMCIgYmVpbmcgdGhlIGN1cnJlbnQgdmVyc2kBMAEBAQE- X-RocketYMMF: giffunip X-Mailer: YahooMailWebService/0.8.131.499 References: <5106953E.2020907@FreeBSD.org> <510BBCAD.3070705@FreeBSD.org> <510BD53D.1070209@FreeBSD.org> <510EE5D2.4050409@FreeBSD.org> Message-ID: <1359947350.91372.YahooMailNeo@web162105.mail.bf1.yahoo.com> Date: Sun, 3 Feb 2013 19:09:10 -0800 (PST) From: Pedro Giffuni Subject: Re: base gcc and _GLIBCXX_USE_C99 To: Dimitry Andric , Andriy Gapon In-Reply-To: <510EE5D2.4050409@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "toolchain@FreeBSD.org" , "stephen@FreeBSD.org" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Pedro Giffuni List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 03:09:12 -0000 Hello Dimitry;=0A=0A=0A----- Messaggio originale -----=0A> Da: Dimitry Andr= ic=A0=0A=0A> I had a bit more in-depth look at our current libstdc++ config= uration.=0A> =0A> I took the original gcc 4.2.1 release tarball, modified a= few autoconf=0A> related scripts to cope with "freebsd10.0" being the curr= ent version,=0A> and did a full three-stage build, though only targeting C = and C++.=0A> =0A> The libstdc++ configure script in 4.2.1 does detect a few= new features=0A> that are not in our shipping config.h, but is does not de= tect any=0A> different settings regarding C99.=0A>=0A=0ANot sure if libstdc= ++ from gcc42 sets --enable-c99 by default.=0A=A0=A0=0A> The reason it does= not turn on _GLIBCXX_USE_C99, is that not all of the=0A> C99 requirements = are met, specifically checks fail:=0A> =0A> =A0 checking for IS= O C99 support in ... yes=0A> =A0 checking for ISO C99 support in ... no=0A> =A0 checking for ISO C99 support in ... yes=0A= > =A0 checking for ISO C99 support in ... yes=0A> =A0 checking fo= r ISO C99 support in ... yes=0A> =A0 checking for fully enabled IS= O C99 support... no=0A> =0A> The exact failure testcase goes like this:=0A>= =0A> =A0 configure:7435: checking for ISO C99 support in =0A> = =A0 configure:7492:=A0 /home/dim/obj/gcc-4.2.1/./gcc/xgcc -shared-libgcc = =0A> -B/home/dim/obj/gcc-4.2.1/./gcc -nostdinc++ =0A> -L/home/dim/obj/gcc-4= .2.1/i386-unknown-freebsd10.0/libstdc++-v3/src =0A> -L/home/dim/obj/gcc-4.2= .1/i386-unknown-freebsd10.0/libstdc++-v3/src/.libs =0A> -B/home/dim/ins/gcc= -4.2.1/i386-unknown-freebsd10.0/bin/ =0A> -B/home/dim/ins/gcc-4.2.1/i386-un= known-freebsd10.0/lib/ -isystem =0A> /home/dim/ins/gcc-4.2.1/i386-unknown-f= reebsd10.0/include -isystem =0A> /home/dim/ins/gcc-4.2.1/i386-unknown-freeb= sd10.0/sys-include -c -g -O2=A0 =0A> conftest.cc >&5=0A> =A0 conftest.cc: I= n function 'int main()':=0A> =A0 conftest.cc:41: error: 'clogf' was not dec= lared in this scope=0A> =A0 conftest.cc:47: error: 'cpowf' was not declared= in this scope=0A> =A0 conftest.cc:54: error: 'clog' was not declared in th= is scope=0A> =A0 conftest.cc:60: error: 'cpow' was not declared in this sco= pe=0A> =A0 conftest.cc:64: error: 'ccosl' was not declared in this scope=0A= > =A0 conftest.cc:65: error: 'ccoshl' was not declared in this scope=0A> = =A0 conftest.cc:66: error: 'cexpl' was not declared in this scope=0A> =A0 c= onftest.cc:67: error: 'clogl' was not declared in this scope=0A> =A0 confte= st.cc:68: error: 'csinl' was not declared in this scope=0A> =A0 conftest.cc= :69: error: 'csinhl' was not declared in this scope=0A> =A0 conftest.cc:71:= error: 'ctanl' was not declared in this scope=0A> =A0 conftest.cc:72: erro= r: 'ctanhl' was not declared in this scope=0A> =A0 conftest.cc:73: error: '= cpowl' was not declared in this scope=0A> =A0 configure:7498: $? =3D 1=0A>= =A0=0A=0AThose are surely in this list:=0Ahttps://wiki.freebsd.org/MissingM= athStuff=0A=0AI think we are using stubs for libc++.=0A=0A> So until we act= ually implement and declare those functions, we should=0A> probably not ena= ble _GLIBCXX_USE_C99_COMPLEX and _GLIBCXX_USE_C99.=0A> =0A> I have attached= a diff of the other changes that can be applied on our=0A> current libstdc= ++ config file, as detected by the configure script.=A0 I=0A> will probably= commit that soonish, if there are no objections.=0A>=A0=0A=0AThanks, that = looks useful. Of course if=A0GLIBCXX_USE_C99 didn't necessarily=0Aimply=A0_= GLIBCXX_USE_C99_COMPLEX it would be useful too.=0A=0A> As to the missing co= mplex functions, I am not sure.=A0 Maybe these can be=0A> imported from som= ewhere else, e.g. NetBSD?=A0 This is probably something=0A> to ask the lib/= msun specialists...=0A>=A0=0A=0A=0AThere is a freebsd-numerics list for peo= ple working on it.=0A=0AI am using the C++ complex stuff from boost and the= re were=0Arecent fixes done by Stephen Montgomery-Smith (CC'd)=0Aand it loo= ks like he has a FreeBSD implementation in the works.=0A=0AI will open a PR= as a reminder ;).=0A=0Acheers,=0A=0APedro.=0A From owner-freebsd-toolchain@FreeBSD.ORG Mon Feb 4 22:04:16 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6875166D; Mon, 4 Feb 2013 22:04:16 +0000 (UTC) (envelope-from honglilai@gmail.com) Received: from mail-ia0-x230.google.com (ia-in-x0230.1e100.net [IPv6:2607:f8b0:4001:c02::230]) by mx1.freebsd.org (Postfix) with ESMTP id 28E0831A; Mon, 4 Feb 2013 22:04:16 +0000 (UTC) Received: by mail-ia0-f176.google.com with SMTP id i18so8641460iac.21 for ; Mon, 04 Feb 2013 14:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=2yf3Duj2fVhjfHBFrP/3tAAFDrv5O6tmsi9fybyTY7M=; b=FzfyhhnbROyzS6DCA08OUFg2cOC0J7OqAzORYEnwLJRIeTL4Y8VFh25+9rGMZ2OoHD LNlux4SQntzgLwsRkPBUQDyYaauMeKfTe2tRVrtzTiqo1soVyhcDW/SPquufZR6mz+4/ kAZo3ZAAe7YSHPPGCU3ZORvi+p+cbWwgU+WvT7PKs3GUi2QOV6LoC7y47DqYQ5d/UbSO A4BLtcvzBmyPjJkpBGR/XOrPinwByBrccBXZDR5lM5O6YdJXUhfdcOIGt3CMCeUHT79d c3FulzU60EiYSTSAnS0w3p5DAEx5Z5X9G4tYY1h/xe3hEv3ZtOMgmIJcF6WV5SJZ8iaJ 1Vzg== X-Received: by 10.50.34.131 with SMTP id z3mr9328999igi.30.1360015455703; Mon, 04 Feb 2013 14:04:15 -0800 (PST) MIME-Version: 1.0 Sender: honglilai@gmail.com Received: by 10.64.73.33 with HTTP; Mon, 4 Feb 2013 14:03:35 -0800 (PST) In-Reply-To: <20130121174555.GK2522@kib.kiev.ua> References: <201301201652.r0KGq0d1042817@red.freebsd.org> <20130121014745.GD2522@kib.kiev.ua> <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> <20130121044912.GE2522@kib.kiev.ua> <398F1CB4-D4B0-4C21-BA05-59DDE77C5DA6@FreeBSD.org> <20130121165427.GG2522@kib.kiev.ua> <2C83B09F-5504-4848-8EB8-877305684254@FreeBSD.org> <20130121172409.GJ2522@kib.kiev.ua> <20130121174555.GK2522@kib.kiev.ua> From: Hongli Lai Date: Mon, 4 Feb 2013 23:03:35 +0100 X-Google-Sender-Auth: QpsyKdX2QJGnZKSD8z_EOVDp_cA Message-ID: Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: "toolchain@freebsd.org" , Pedro Giffuni X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 22:04:16 -0000 Any progress on fixing this issue? On Mon, Jan 21, 2013 at 6:45 PM, Konstantin Belousov wrote: > On Mon, Jan 21, 2013 at 05:26:29PM +0000, David Chisnall wrote: >> On 21 Jan 2013, at 17:24, Konstantin Belousov wrote: >> >> > So can you provide self-contained test.tgz with Makefile and neccessary >> > .c files which demonstrate exactly the behaviour you see ? >> >> I don't have one, this is the behaviour that I see from C++ programs linked to libstdc++. > > I understand that you do not have one. Can you write it ? > > [This is my last mail on the subject, it seems] -- Phusion | Ruby & Rails deployment, scaling and tuning solutions Web: http://www.phusion.nl/ E-mail: info@phusion.nl Chamber of commerce no: 08173483 (The Netherlands) From owner-freebsd-toolchain@FreeBSD.ORG Mon Feb 4 22:14:59 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2A97EB0A for ; Mon, 4 Feb 2013 22:14:59 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm2.bullet.mail.bf1.yahoo.com (nm2.bullet.mail.bf1.yahoo.com [98.139.212.161]) by mx1.freebsd.org (Postfix) with SMTP id 860753CA for ; Mon, 4 Feb 2013 22:14:58 +0000 (UTC) Received: from [98.139.212.146] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 04 Feb 2013 22:12:15 -0000 Received: from [98.139.213.3] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 04 Feb 2013 22:12:15 -0000 Received: from [127.0.0.1] by smtp103.mail.bf1.yahoo.com with NNFMP; 04 Feb 2013 22:12:15 -0000 X-Yahoo-Newman-Id: 669054.92973.bm@smtp103.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DqsiEbsVM1kmuy4tiUJSKs7E9USePQpCvwJewqdmT3nnfaI 03FhioJuoYrLrA7EgStwP3JsfpWoh64Ybl4CXKpZX.TnDHoJG14wkM2h4JN. q2QHH2IW0uxILlQseX2QVYnkriDb84P1uWPhkl.ppf8bzlTXU3eLHj60DyM5 nKvsd4z1xQ6CAjzcq5Jh2XnDav68XrjVT2nNYUGJTwKcLINw5MVF.ZA.tdNZ 9pFQaZDKLJZ4U07yKig4s.4d4PBV8NFy9QHT7NyDwjtVUIzZcbMojk3Yys1u puEokRk_5zXES6vs7IeRQq84prnL7HCPFMI6XT4Y4hdM0OidAEzY_fNSNV0D 7gMs8_2BdG53_EXxDyBdNGi9Dyfe0lvQryzrjy_Yh4uGh82heoIO3.Mat.oU WNZytcgKwb1Imp6FqVB12pCUAFXgqAwDvmZxF9Ck1XcGhym70JfmpCQ014u2 .ixRddi2W X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.102] (pfg@200.118.157.7 with plain) by smtp103.mail.bf1.yahoo.com with SMTP; 04 Feb 2013 14:12:15 -0800 PST Message-ID: <51103243.6090500@FreeBSD.org> Date: Mon, 04 Feb 2013 17:12:19 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Hongli Lai Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 References: <201301201652.r0KGq0d1042817@red.freebsd.org> <20130121014745.GD2522@kib.kiev.ua> <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> <20130121044912.GE2522@kib.kiev.ua> <398F1CB4-D4B0-4C21-BA05-59DDE77C5DA6@FreeBSD.org> <20130121165427.GG2522@kib.kiev.ua> <2C83B09F-5504-4848-8EB8-877305684254@FreeBSD.org> <20130121172409.GJ2522@kib.kiev.ua> <20130121174555.GK2522@kib.kiev.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "toolchain@freebsd.org" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 22:14:59 -0000 On 02/04/2013 17:03, Hongli Lai wrote: > Any progress on fixing this issue? I think there is a fix (and a fix to the fix) in -current. Pedro. > On Mon, Jan 21, 2013 at 6:45 PM, Konstantin Belousov > wrote: >> On Mon, Jan 21, 2013 at 05:26:29PM +0000, David Chisnall wrote: >>> On 21 Jan 2013, at 17:24, Konstantin Belousov wrote: >>> >>>> So can you provide self-contained test.tgz with Makefile and neccessary >>>> .c files which demonstrate exactly the behaviour you see ? >>> I don't have one, this is the behaviour that I see from C++ programs linked to libstdc++. >> I understand that you do not have one. Can you write it ? >> >> [This is my last mail on the subject, it seems] > > From owner-freebsd-toolchain@FreeBSD.ORG Tue Feb 5 19:13:00 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9EF423ED; Tue, 5 Feb 2013 19:13:00 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5DB5313C; Tue, 5 Feb 2013 19:13:00 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:e15d:6e9c:4028:a235] (unknown [IPv6:2001:7b8:3a7:0:e15d:6e9c:4028:a235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 673F85C5A; Tue, 5 Feb 2013 20:12:53 +0100 (CET) Message-ID: <511159B2.50806@andric.com> Date: Tue, 05 Feb 2013 20:12:50 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Pedro Giffuni , Hongli Lai Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 References: <201301201652.r0KGq0d1042817@red.freebsd.org> <20130121014745.GD2522@kib.kiev.ua> <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> <20130121044912.GE2522@kib.kiev.ua> <398F1CB4-D4B0-4C21-BA05-59DDE77C5DA6@FreeBSD.org> <20130121165427.GG2522@kib.kiev.ua> <2C83B09F-5504-4848-8EB8-877305684254@FreeBSD.org> <20130121172409.GJ2522@kib.kiev.ua> <20130121174555.GK2522@kib.kiev.ua> <51103243.6090500@FreeBSD.org> In-Reply-To: <51103243.6090500@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "toolchain@freebsd.org" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 19:13:00 -0000 On 2013-02-04 23:12, Pedro Giffuni wrote: > On 02/04/2013 17:03, Hongli Lai wrote: >> Any progress on fixing this issue? > I think there is a fix (and a fix to the fix) in -current. I have merged the necessary fixes to stable/9 in r246368. From owner-freebsd-toolchain@FreeBSD.ORG Wed Feb 6 10:14:53 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EECD6508 for ; Wed, 6 Feb 2013 10:14:53 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id B3707E94 for ; Wed, 6 Feb 2013 10:14:53 +0000 (UTC) Received: from mxin3-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MHS00JUUN4SK650@smtp4.clear.net.nz> for freebsd-toolchain@freebsd.org; Wed, 06 Feb 2013 23:14:53 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin32.paradise.net.nz with ESMTP; Wed, 06 Feb 2013 23:14:52 +1300 Date: Wed, 06 Feb 2013 23:14:01 +1300 From: Andrew Turner Subject: Link issue with clang and ARM EABI To: freebsd-toolchain@freebsd.org Message-id: <20130206231401.30953f4a@bender> MIME-version: 1.0 Content-type: multipart/mixed; boundary="MP_/ZSFc84MBJQShx33Pmhr/YOl" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 10:14:54 -0000 --MP_/ZSFc84MBJQShx33Pmhr/YOl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I've been updating clang to support ARM EABI on FreeBSD. The problem I've found is libc & compiler-rt are dependent on each other. The current link order for a static binary is to append -lgcc -lc -lgcc to the end of the link command. The __aeabi_mem* are implemented by calling their equivalent function in libc, for example __aeabi_memmove calls the libc memmove. The problem is clang can place calls to these __aeabi_mem* functions in libc. If we are building a static program libc will call into the second copy of libgcc which is then unable to find the required symbol. This doesn't appear to be a problem for the run-time linker so shared binaries work without changing the libraries linked against. The attached patch fixes this by changing the link order to -lc -lgcc -lc -lgcc. This means the program will use the symbol in the first copy of libc which will call into the first libgcc and that calls into the second libc. Can anyone see any problems doing this? I would like to send it upstream and commit it to our tree to help get ARM EABI clang builds working. (CC me, I'm not on the list) Andrew --MP_/ZSFc84MBJQShx33Pmhr/YOl Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=clang_libc.diff Index: contrib/llvm/tools/clang/lib/Driver/Tools.cpp =================================================================== --- contrib/llvm/tools/clang/lib/Driver/Tools.cpp (revision 246368) +++ contrib/llvm/tools/clang/lib/Driver/Tools.cpp (working copy) @@ -5574,10 +5574,24 @@ } // FIXME: For some reason GCC passes -lgcc and -lgcc_s before adding // the default system libraries. Just mimic this for now. - if (Args.hasArg(options::OPT_pg)) + + // On some architectures and ABIs, for example ARM EABI, libc and libgcc + // can call into each other. An example is when clang generates calls + // to __aeabi_memcpy, which may then call memcpy. As __aeabi_memcpy is + // probided by compiler-rt and memcpy is provided by libc this means + // libc is looking for a symbol in compiler-rt which in turn is looking + // for a symbol in libc. This is only a problem with static linking + // so in this case we link against libc, compiler-rt, libc and compiler-rt + // in that order. + if (Args.hasArg(options::OPT_pg)) { + if (Args.hasArg(options::OPT_static)) + CmdArgs.push_back("-lc_p"); CmdArgs.push_back("-lgcc_p"); - else + } else { + if (Args.hasArg(options::OPT_static)) + CmdArgs.push_back("-lc"); CmdArgs.push_back("-lgcc"); + } if (Args.hasArg(options::OPT_static)) { CmdArgs.push_back("-lgcc_eh"); } else if (Args.hasArg(options::OPT_pg)) { --MP_/ZSFc84MBJQShx33Pmhr/YOl-- From owner-freebsd-toolchain@FreeBSD.ORG Sat Feb 9 16:03:19 2013 Return-Path: Delivered-To: freebsd-toolchain@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 72C9D9E7; Sat, 9 Feb 2013 16:03:19 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4B1B0101; Sat, 9 Feb 2013 16:03:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r19G3JPe088422; Sat, 9 Feb 2013 16:03:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r19G3Je7088418; Sat, 9 Feb 2013 16:03:19 GMT (envelope-from linimon) Date: Sat, 9 Feb 2013 16:03:19 GMT Message-Id: <201302091603.r19G3Je7088418@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-toolchain@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: bin/175930: clang does not define __STDC_ISO_10646__, despite having Unicode in wchar_t X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 16:03:19 -0000 Old Synopsis: CLang does not define __STDC_ISO_10646__, despite having Unicode in wchar_t New Synopsis: clang does not define __STDC_ISO_10646__, despite having Unicode in wchar_t Responsible-Changed-From-To: freebsd-bugs->freebsd-toolchain Responsible-Changed-By: linimon Responsible-Changed-When: Sat Feb 9 16:02:36 UTC 2013 Responsible-Changed-Why: let's see if anyone on toolchain@ has an opinion. http://www.freebsd.org/cgi/query-pr.cgi?pr=175930 From owner-freebsd-toolchain@FreeBSD.ORG Sat Feb 9 17:53:02 2013 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A68E65E; Sat, 9 Feb 2013 17:53:02 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5EC2B6E0; Sat, 9 Feb 2013 17:52:58 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a] (spaceball.andric.com [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 42BE85C43; Sat, 9 Feb 2013 18:52:50 +0100 (CET) Message-ID: <51168CF6.4030204@FreeBSD.org> Date: Sat, 09 Feb 2013 18:52:54 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-toolchain@FreeBSD.org Subject: Re: bin/175930: clang does not define __STDC_ISO_10646__, despite having Unicode in wchar_t References: <201302091603.r19G3Je7088418@freefall.freebsd.org> In-Reply-To: <201302091603.r19G3Je7088418@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 17:53:02 -0000 On 2013-02-09 17:03, linimon@FreeBSD.org wrote:> Old Synopsis: CLang does not define __STDC_ISO_10646__, despite having Unicode in wchar_t > New Synopsis: clang does not define __STDC_ISO_10646__, despite having Unicode in wchar_t > > Responsible-Changed-From-To: freebsd-bugs->freebsd-toolchain > Responsible-Changed-By: linimon > Responsible-Changed-When: Sat Feb 9 16:02:36 UTC 2013 > Responsible-Changed-Why: > let's see if anyone on toolchain@ has an opinion. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=175930 I don't think this has anything to do with clang (or gcc, for that matter). It is a potential issue with our system headers, specifically . Our wchar_t is either int or unsigned int (on armeabi), so I guess it should not be a problem to define a sensible value for the __STDC_ISO_10646__ macro there. As to what the exact value should be, I have no idea really. The C99 standard says only this: __STDC_ISO_10646__ An integer constant of the form yyyymmL (for example, 199712L), intended to indicate that values of type wchar_t are the coded representations of the characters defined by ISO/IEC 10646, along with all amendments and technical corrigenda as of the specified year and month. GNU libc has this: /* wchar_t uses ISO 10646-1 (2nd ed., published 2000-09-15) / Unicode 3.1. */ #define __STDC_ISO_10646__ 200009L So maybe that is a good value for us too?