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
