OpenWrt cross compile build error in 0.2.6.8
Hi Everybody, I have for a while been maintaining an up-to-date Tor package for OpenWrt. In the latest stable 0.2.6.8 I get a build error (see below). I suspect this is actually autoconf related and I must admit I am not too familiar with autoconf. I have been trying to compare things with 0.2.5.12 (which compiled cleanly) but I have not been able to spot or fix the problem. Any ideas? I am sure I miss something blatantly obvious. ccache_cc -DHAVE_CONFIG_H -I. -I./src/ext -Isrc/ext -I./src/ext/trunnel -I./src/trunnel -I./src/common -Isrc/common -I./src/ext/trunnel -I./src/trunnel -I./src/or -Isrc/or -DSHARE_DATADIR="\"/usr/share\"" -DLOCALSTATEDIR="\"/var\"" -DBINDIR="\"/usr/bin\"" -I/home/lth/ionic-router/staging_dir/target-mips_34kc_uClibc-0.9.33.2/usr/include -I/home/lth/ionic-router/staging_dir/target-mips_34kc_uClibc-0.9.33.2/include -I/home/lth/ionic-router/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/usr/include -I/home/lth/ionic-router/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/include -I./src/common -I/home/lth/ionic-router/staging_dir/target-mips_34kc_uClibc-0.9.33.2/usr/include -I/home/lth/ionic-router/staging_dir/target-mips_34kc_uClibc-0.9.33.2/usr/include -Os -pipe -mno-branch-likely -mips32r2 -mtune=34kc -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -mips16 -minterlink-mips16 -std=c99 -MT src/common/address.o -MD -MP -MF $depbase.Tpo -c -o src/common/address.o src/common/address.c &&\ mv -f $depbase.Tpo $depbase.Po src/common/address.c: In function 'tor_addr_lookup': src/common/address.c:250:21: error: storage size of 'hints' isn't known struct addrinfo hints; ^ src/common/address.c:255:5: warning: implicit declaration of function 'getaddrinfo' [-Wimplicit-function-declaration] err = sandbox_getaddrinfo(name, NULL, &hints, &res); ^ src/common/address.c:260:45: error: dereferencing pointer to incomplete type for (res_p = res; res_p; res_p = res_p->ai_next) { ^ src/common/address.c:262:20: error: dereferencing pointer to incomplete type if (res_p->ai_family == AF_INET) { ^ src/common/address.c:265:27: error: dereferencing pointer to incomplete type } else if (res_p->ai_family == AF_INET6 && !best) { ^ src/common/address.c:268:35: error: dereferencing pointer to incomplete type } else if (family == res_p->ai_family) { ^ src/common/address.c:275:15: error: dereferencing pointer to incomplete type if (best->ai_family == AF_INET) { ^ src/common/address.c:276:65: error: dereferencing pointer to incomplete type tor_addr_from_in(addr, ^ src/common/address.c:279:22: error: dereferencing pointer to incomplete type } else if (best->ai_family == AF_INET6) { ^ src/common/address.c:281:55: error: dereferencing pointer to incomplete type &((struct sockaddr_in6*)best->ai_addr)->sin6_addr); ^ src/common/address.c:284:7: warning: implicit declaration of function 'freeaddrinfo' [-Wimplicit-function-declaration] sandbox_freeaddrinfo(res); ^ src/common/address.c:287:20: error: 'EAI_AGAIN' undeclared (first use in this function) return (err == EAI_AGAIN) ? 1 : -1; ^ src/common/address.c:287:20: note: each undeclared identifier is reported only once for each function it appears in src/common/address.c: In function 'tor_addr_parse_PTR_name': src/common/address.c:519:5: warning: implicit declaration of function 'strcasecmp' [-Wimplicit-function-declaration] if (strcasecmp(cp, "ip6.arpa")) ^ src/common/address.c: In function 'ifaddrs_to_smartlist': src/common/address.c:1243:26: error: 'IFF_UP' undeclared (first use in this function) if ((i->ifa_flags & (IFF_UP | IFF_RUNNING)) != (IFF_UP | IFF_RUNNING)) ^ src/common/address.c:1243:35: error: 'IFF_RUNNING' undeclared (first use in this function) if ((i->ifa_flags & (IFF_UP | IFF_RUNNING)) != (IFF_UP | IFF_RUNNING)) ^ src/common/address.c: In function 'ifreq_to_smartlist': src/common/address.c:1404:35: error: dereferencing pointer to incomplete type const struct sockaddr *sa = &r->ifr_addr; ^ src/common/address.c:1414:19: error: dereferencing pointer to incomplete type buf += _SIZEOF_ADDR_IFREQ(*r); ^ src/common/address.c: In function 'get_interface_addresses_ioctl': src/common/address.c:1429:17: error: storage size of 'ifc' isn't known struct ifconf ifc; ^ Makefile:2962: recipe for target 'src/common/address.o' failed make[4]: *** [src/common/address.o] Error 1 -- Lars Boegild Thomsen https://reclaim-your-privacy.com Jabber/XMPP: lth@reclaim-your-privacy.com
Lars Boegild Thomsen <lth@reclaim-your-privacy.com> writes:
Hi Everybody,
I have for a while been maintaining an up-to-date Tor package for OpenWrt. In the latest stable 0.2.6.8 I get a build error (see below).
I suspect this is actually autoconf related and I must admit I am not too familiar with autoconf. I have been trying to compare things with 0.2.5.12 (which compiled cleanly) but I have not been able to spot or fix the problem.
Any ideas? I am sure I miss something blatantly obvious.
Will you post the Makefile for the buildroot package? -- Shawn Nock (OpenPGP: 0x6FDA11EE 3BC412E3)
On Friday 22 May 2015 09:20:29 Shawn Nock wrote:
Will you post the Makefile for the buildroot package?
Sure - attached. The TARGET_CFLAGS += -std=c99 was added for this version - it was not necessary in the previous version. -- Lars Boegild Thomsen https://reclaim-your-privacy.com Jabber/XMPP: lth@reclaim-your-privacy.com
On Friday 22 May 2015 09:20:29 Shawn Nock wrote:
Will you post the Makefile for the buildroot package?
Sorry guys, I sorted this one out. The culprit was actually my added -std=c99 that made lots of other stuff break. Taking that out it boiled down to a few uses of: for (int i = 0; ...... Changing those to: int i; for (i = Fixed the build. I have attached a patch. -- Lars Boegild Thomsen https://reclaim-your-privacy.com Jabber/XMPP: lth@reclaim-your-privacy.com
On 05/24/2015 05:19 AM, Lars Boegild Thomsen wrote:
On Friday 22 May 2015 09:20:29 Shawn Nock wrote:
Will you post the Makefile for the buildroot package?
Sorry guys, I sorted this one out. The culprit was actually my added -std=c99 that made lots of other stuff break. Taking that out it boiled down to a few uses of:
for (int i = 0; ......
There is also patchless way by adding "-std=gnu99" to CFLAGS (aside from C99 it enables GNU extensions needed for compiling against uClibc on OpenWrt). I think it's better approach since you won't need to patch every C99-style loop initializer in the future. Ondrej
On Sun, May 24, 2015 at 2:32 PM, Ondrej Mikle <ondrej.mikle@gmail.com> wrote:
On 05/24/2015 05:19 AM, Lars Boegild Thomsen wrote:
On Friday 22 May 2015 09:20:29 Shawn Nock wrote:
Will you post the Makefile for the buildroot package?
Sorry guys, I sorted this one out. The culprit was actually my added -std=c99 that made lots of other stuff break. Taking that out it boiled down to a few uses of:
for (int i = 0; ......
There is also patchless way by adding "-std=gnu99" to CFLAGS (aside from C99 it enables GNU extensions needed for compiling against uClibc on OpenWrt).
I think it's better approach since you won't need to patch every C99-style loop initializer in the future.
+1 to Ondrej here. Going forward, I'm not interested in supporting pre-99 C. -- Nick
On Sunday 24 May 2015 20:32:41 Ondrej Mikle wrote:
There is also patchless way by adding "-std=gnu99" to CFLAGS (aside from C99 it enables GNU extensions needed for compiling against uClibc on OpenWrt).
Read my first message with this topic. That was my very first attempt. Unfortunately that resulted in a lot of new errors which I think was autoconf related mostly. I have no idea why that happened.
I think it's better approach since you won't need to patch every C99-style loop initializer in the future.
Would have been better if it worked I agree but obviously the best would be no patch needed at all as indeed has been the case up until the latest version. I know the C99 stuff can be handled in autoconf. -- Lars Boegild Thomsen https://reclaim-your-privacy.com Jabber/XMPP: lth@reclaim-your-privacy.com
On Sun, May 24, 2015 at 6:32 PM, Lars Boegild Thomsen <lth@reclaim-your-privacy.com> wrote:
On Sunday 24 May 2015 20:32:41 Ondrej Mikle wrote:
There is also patchless way by adding "-std=gnu99" to CFLAGS (aside from C99 it enables GNU extensions needed for compiling against uClibc on OpenWrt).
Read my first message with this topic. That was my very first attempt. Unfortunately that resulted in a lot of new errors which I think was autoconf related mostly. I have no idea why that happened.
I see -std=c99 in there, not -std=gnu99. If -std=gnu99 does not work, try adding -D_GNU_SOURCE=1 or -D_XOPEN_SOURCE=700. If neither of those work, root around in uClibc's header files for other macros named _SOMETHING_SOURCE to try. zw
On Sunday 24 May 2015 18:41:33 Zack Weinberg wrote:
I see -std=c99 in there, not -std=gnu99. If -std=gnu99 does not work, try adding -D_GNU_SOURCE=1 or -D_XOPEN_SOURCE=700. If neither of those work, root around in uClibc's header files for other macros named _SOMETHING_SOURCE to try.
Ah, you are absolutely right Sir, I was unaware of the difference between c99 and gnu99 and it worked with gnu99. Thanx! -- Lars Boegild Thomsen https://reclaim-your-privacy.com Jabber/XMPP: lth@reclaim-your-privacy.com
On 05/25/2015 12:32 AM, Lars Boegild Thomsen wrote:
On Sunday 24 May 2015 20:32:41 Ondrej Mikle wrote:
There is also patchless way by adding "-std=gnu99" to CFLAGS (aside from C99 it enables GNU extensions needed for compiling against uClibc on OpenWrt).
Read my first message with this topic. That was my very first attempt. Unfortunately that resulted in a lot of new errors which I think was autoconf related mostly. I have no idea why that happened.
You used "-std=c99" which is strict C99 mode, note that this is "-std=gnu99", C99 with GNU extensions. I've run into this as well with 0.2.6.x, took me a while to figure out why it was failing with uClibc. I've tried to crosscompile unpatched 0.2.6.8 in openwrt buildroot today and it worked with "-std=gnu99". Ondrej
participants (5)
-
Lars Boegild Thomsen -
Nick Mathewson -
Ondrej Mikle -
Shawn Nock -
Zack Weinberg