[SOLVED] Various ipv6 related struct redefinition errors when building

Well, probably solved. I found the default setting for MUSL for the toolchain build in menuconfig (I hadn't explictly set it) and changed to glibc. There may still be a redefine problem; re-making now on a slow machine. If this doesn't work then I'll look into making other headers override kernel headers by way of make, gcc, or editing if necessary.

After doing some research I find that the redefines correlate with using MUSL but I'm unsure howto interpret them in the context of LEDE builds. I figure this has come up before so am posting here to get a better picture of what I'm dealing with and the right way to fix it rather that just me "making them go away somehow". The errors from make are below. I think I understand the nature of the error being that the structs are redefined across .h files. Where I'm stumped is what caused this in the chain of events that varied from a normal build and the easiest fix. Did I install something wrong? Did I miss a step? Did I make a bad selection in 'make menuconfig'? Is my Include path wacked? Or is this a known issue with a fix required not mentioned in the docs that are git'd with the LEDE build env? Anyway, that is the problem, any help appreciated! Marty

In file included from /home/marty/lede/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-5.4.0_musl_eabi/include/linux/if_bridge.h:18:0,
from /home/marty/lede/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/netifd-2017-02-11-f1076561/system-linux.c:36:
/home/marty/lede/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-5.4.0_musl_eabi/include/linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
In file included from /home/marty/lede/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-5.4.0_musl_eabi/include/linux/if_bridge.h:18:0,
from /home/marty/lede/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/netifd-2017-02-11-f1076561/system-linux.c:36:
/home/marty/lede/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-5.4.0_musl_eabi/include/linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
In file included from /home/marty/lede/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-5.4.0_musl_eabi/include/linux/if_bridge.h:18:0,
from /home/marty/lede/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/netifd-2017-02-11-f1076561/system-linux.c:36:
/home/marty/lede/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-5.4.0_musl_eabi/include/linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'

Possible duplicate include of "in6.h".

When i have this problem i usually set chmod 0 on the file when trying to spot who's first opening the file. Other ways to trace file access is inotifywait/lsof, strace or kfsmd which is my favorite.

You can also enable preprocessor tracing or use tools like ccpclean or doxygen but all this usually requires modification of the build tools and related files and is the reason why I'm only using this as a last resort

Btw, the subject says "[SOLVED]". Did you spot the error?

Yes, and no. Google revealed this happens to a lot of people across a lot of compiles / cross-compiles on linux and not just with the structs I had issue with. Basically, these structures end up defined twice as they are defined in the kernel headers and also often in other places, like MUSL headers. I don't know what the best solution is but I went from musl in the build tools to glibc as implied in link below (thus avoiding editing of kernel headers). Which leaves dangling how to build with MUSL. I'm deferring that to another time.

I'm not seeing how knowing who's opening the file helps. The build / compile process is processing header files and a struct is redefined. I'm assuming it is the compiler or precompiler accessing the include files.

I did find this:

Which appears to be an effort to provide "sanitized" headers to get MUSL to work on various platforms to deal specifically with MUSL use on linux but it doesn't address the non-MUSL cases. I see an "ARM" directory there which may work for me but I don't have time to traverse a rabbit hole right now.

Yeah, "header" problems can be really messy and take ages to sort out /-)

Well, basically correct but it depends I would say.

It might help if the reason is that the same file is included twice during the compilation and is missing "include" controls (i.e.ifnotdefined ipvi6 define ipv6 etc) in combination with preproccessor flags that doesn't allow a redefinition even if it's exactly the same.

If the problem relates to different definitions in different files is another matter. I guess this might be the issue in your case.

Ok, understood. Thanks for responding, btw. I thought it was just me and the crickets, ha ha.

Yes, if I go down the rabbit hole, I'll probably modify the MUSL headers with ifnotdefined like you point out. If you google "linux redefinition of struct" you will see this apparently is a systemic problem. A hack was put in for glibc by the kernel devs as noted in that other link I posted, but generally there seems to be a lack of will to really address the issue. I still think I got off the beaten path somehow in my build and triggered this otherwise I'd have gotten more response to this post. I will likely start from scratch setting up the environment and be more attentive this time. But this has to wait until I can get another SATA drive as I'm getting read errors. And it could be those read errors that ended up corrupting something that trickled down to a problem with the build config that ended up causing the redefinition problem. Anyway, onward through the fog, and thanks again.