From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 1FED31387FD for ; Thu, 12 Jun 2014 10:45:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E48CAE088D; Thu, 12 Jun 2014 10:45:25 +0000 (UTC) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 01B31E0866 for ; Thu, 12 Jun 2014 10:45:24 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id im17so570246vcb.25 for ; Thu, 12 Jun 2014 03:45:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=E8lz2W239jfFWVcRoF83x+shZU7a8nnOv6ns/uC8B6A=; b=PH1CHOIOAmf7WXaHApH52wFVMC2UqT0Mcla8upT2kmMqP85Vl8P7qF2rnOCzKv/col kh2eKzYa8HeEMMfUOewreVOVa4eb8yNkmMtt54J5hemttsPIndvyYtt9fiiffTnd+cl1 XuOwuP+nJcErE3oNPI5Ouh2oKCBVbxRs9bqqzViCXxBEdQ9eoAA0YQCSGlfWHip9vxoF vL7Jcy2mWh6V4trQSYN2pE6oy5km84bvmes5u1RkkQ9hGjRnR53u/xPnd2ynt83BMg2B OTrF5jdWnatsbh1g7vhm1fVA0q2JcJYh29yKGqykgeeSZ4zwzav1sJxwESP6nJ33V54F H9zw== X-Gm-Message-State: ALoCoQmlfiz9K//JNtDKVMW/ylq0t4qJ2dnB/xmAV/ZEOm3+vYEi6DyLasmJzSRaT5nuQnnAqZVa Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.52.241.98 with SMTP id wh2mr769541vdc.37.1402569923744; Thu, 12 Jun 2014 03:45:23 -0700 (PDT) Sender: gmt@be-evil.net Received: by 10.220.141.207 with HTTP; Thu, 12 Jun 2014 03:45:23 -0700 (PDT) X-Originating-IP: [75.147.143.254] Date: Thu, 12 Jun 2014 03:45:23 -0700 X-Google-Sender-Auth: hRxXJbgXXGBBdyAVn-KltIwaZEI Message-ID: Subject: Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector From: Greg Turner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 6269eba2-d31a-4575-811e-5301405d85c5 X-Archives-Hash: aefa60978a7d05dcf6ba7a0dd23f87da On Wed, Jun 11, 2014 at 6:23 AM, Jeroen Roovers wrote: > > Will bug #332823 and its ilk somehow be mitigated? Emerging glibc with > -fstack-protector still leads to similar problems. There doesn't > currently seem to be a bug report about this that isn't marked INVALID. Is this a bug/limitation in glibc's actual code, or in glibc's build environment? Asked another (wordier) way -- should I understand -- assuming nobody adds some explicit -fno-stack-protector to the non-hardened profiles or the glibc ebuild -- and, of course, also that the user has not put it in make.conf or similar -- that this would break glibc compilation in the base configurations of the x86/amd64 non-hardened profiles?* If that's so... that doesn't sound so great, does it? Just thinking out loud, I guess, but, the fact -- if it is, indeed, still a fact (?) -- that, as of gcc-4.8.2, putting -fstack-protector in your CFLAGS breaks glibc.ebuild doesn't /necessarily/ mean that, as of gcc-4.8.3, leaving -fno-stack-protector out of your cflags would also break it, even if they are supposed to mean the same thing -- that would depend on the specific etiology of the problem. Sorry, perhaps Google Search would answer my question as readily as portage, in which case, by all means feel free to "lmgtfy" my ass. But if nobody knows the answer for sure, presumably you have the means to find out, Ryan? If for any reason you need a guinea-pig, I have a non-hardened triple-multilib (but mostly ABI_X86="64 32") workstation, here, that I'm not afraid to break. -gmt *Apologies for the horrific run-on sentence!