Build of v4.0.x fails : freeradius-devel/io/ring_buffer.h: No such file or directory => solved (+ more issues)

[Alan DeKok]

On Feb 16, 2018, at 1:31 PM, Chaigneau, Nicolas <nicolas.chaigneau at capgemini.com> wrote:
> 
> I solved my issue by making the following change:
> 
> In file: src/include/all.mk (line 136)
> 
> #       ${Q}[ -e src/include/io ] || ln -s src/lib/io ${top_srcdir}/src/include
>        ${Q}[ -e src/include/io ] || ln -s ${top_srcdir}/src/lib/io ${top_srcdir}/src/include

  That's a GNU Make thing... 3.81 is happy with the local path, 3.82 needs the full path.

  <sigh>

> Then it fails later, because of compilation warnings (I tried to configure with "--enable-werror"):

  That can be removed.  The warnings change drastically on different compilers.  So it's only really useful for developers and the automated build system.

  i.e. we want the build to be without C compiler warnings, so -Werror is used there.  Most people just using the server won't need it.

> 
> CC src/main/map.c
> src/main/map.c: In function ‘map_list_mod_apply’:
> src/main/map.c:1679:3: error: this statement may fall through [-Werror=implicit-fallthrough=]

  Yeah, that should be fixed.  I'll push a fix.

> src/main/map.c: In function ‘map_to_request’:
> src/main/map.c:2433:7: error: this statement may fall through [-Werror=implicit-fallthrough=]
>    if (map->rhs->type == TMPL_TYPE_LIST) {

  That needs fixing, too.

> src/main/map.c:2440:3: note: here
>   case T_OP_ADD:
>   ^~~~

  And that.

> So I tried removing  "--enable-werror" from configure.
> I go a bit farther now. Include issues, I guess:
> 
> CC src/protocols/dhcpv4/decode.c
> In file included from src/protocols/dhcpv4/decode.c:33:0:
> src/freeradius-devel/dhcpv4/dhcpv4.h:145:1: error: unknown type name ‘RADIUS_PACKET’; did you mean ‘AF_PACKET’?
> RADIUS_PACKET *fr_dhcpv4_udp_packet_recv(int sockfd);
> ^~~~~~~~~~~~~
> AF_PACKET

  Hmmm... I don't see that.

> src/protocols/dhcpv4/decode.c: In function ‘fr_dhcpv4_decode_option’:
> src/protocols/dhcpv4/decode.c:376:55: error: ‘FR_VENDOR_SPECIFIC’ undeclared (first use in this function); did you mean ‘_SC_DEVICE_SPECIFIC’?
>  parent = fr_dict_attr_child_by_num(packet_ctx->root, FR_VENDOR_SPECIFIC);
>                                                       ^~~~~~~~~~~~~~~~~~
>                                                       _SC_DEVICE_SPECIFIC

  It looks like the build is picking up *none* of the other header files.  Which is weird... it should either not find the header file and fail, or pick them up properly.

  Alan DeKok.