Trying again; the mailer rejected my initial email. -- Caroline cmtice@xxxxxxxxxx On Mon, Dec 14, 2015 at 9:34 AM, Caroline Tice <cmtice@xxxxxxxxxx> wrote: > 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@xxxxxxxxxx > > > On Mon, Dec 14, 2015 at 4:37 AM, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
