From mboxrd@z Thu Jan 1 00:00:00 1970 From: Caroline Tice Subject: Re: [PATCH v4] libmnl: Drop the EXPORT_SYMBOL() tags Date: Mon, 14 Dec 2015 09:34:23 -0800 Message-ID: References: <20151029190717.GE5154@vapier.lan> <20151214123731.GA26186@salvia> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Neutron Soutmun , 20151006012711.GA5372@oxygen.gentoo.org, netfilter-devel@vger.kernel.org, Mike Frysinger To: Pablo Neira Ayuso Return-path: Received: from mail-io0-f173.google.com ([209.85.223.173]:36480 "EHLO mail-io0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751223AbbLNRen (ORCPT ); Mon, 14 Dec 2015 12:34:43 -0500 Received: by iofo67 with SMTP id o67so51321102iof.3 for ; Mon, 14 Dec 2015 09:34:43 -0800 (PST) In-Reply-To: <20151214123731.GA26186@salvia> Sender: netfilter-devel-owner@vger.kernel.org List-ID: I did talk with some Clang developers initially, to try to determine if this was in fact a Clang bug and therefore would need to be fixed in Clang. The answer I got was a resounding no, this is not a Clang bug; it is, in fact a GCC bug -- an example of GCC being overly permissive (which, sadly, is not that uncommon). After a function has been *declared* (the header, but no code), it is still ok to change the visibility of the function. However after the function has actually been *defined*, changing the visibility of the function is illegal. That is why moving all of the EXPORT_SYMBOL statements from after the function code to before the function code fixes the problem, as far as Clang is concerned. -- Caroline cmtice@google.com On Mon, Dec 14, 2015 at 4:37 AM, Pablo Neira Ayuso wrote: > Cc'ing everyone that has sent patches to us to address libmnl > compilation problems with clang. > > On Sat, Nov 14, 2015 at 07:45:44AM +0700, Neutron Soutmun wrote: >> The initial problem for my proposed patch is the incompatible of >> symbols visibility in gcc and clang >> which libmnl is failed to build from source in clang and it's the one >> of another approaches that pass the build in both gcc and clang. >> >> I'll test your patch with clang and back to you ASAP. > > Did anyone consider going back to the clang community and ask why > EXPORT_SYMBOL() definition is not correct there? > > I understand removing this from our libraries is a quick solution, but > I think it would be to get feedback from them to see if it's something > that they can fix there (it would resolve problems for projects a using > similar definition without updating the code). > > Let me know, thanks.