On Thu, Oct 1, 2015 at 5:12 AM, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > We have more libraries using this approach, which resembles kernel > coding. So we would need to update them all, which is a bit annoying. Ah, I see. I try to find many approaches to easy fix this but not success. Refer to [1] which the reporter proposes the patch == 8< == ifeq ($(shell $(CC) --version | grep -c "clang version"),1) CFLAGS += -fvisibility=default endif == 8< == I have tested, the symbols exported but I think It will override the visibility attributes, therefore, I have prepared my proposed patch. > Though this warning results in a real problem since symbols will not > be exported. > Why is clang rejecting this? I'm not sure. It seems that clang expands the EXPORT_SYMBOL() as a redefined of it's exported symbol function which is far different from gcc implementation. I try to seek more info [2] and see the export.h source [3] but I have no idea for what's next -_-'' Best regards, Neutron Soutmun [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789480 [2] http://llvm.linuxfoundation.org/index.php/Main_Page [3] http://lxr.free-electrons.com/source/include/linux/export.h -- 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
