Re: R19-rc2 compilation error on FreeBSD 10.3-p4 in unix_efile

Should we take this discussion to bugs.erlang.org?
More inline...

On Sun, Jun 5, 2016 at 2:05 AM, Mikael Pettersson <[email protected]> wrote:
> Garret Smith writes:
>  > Going back, this error was present in rc1 as well.
>  > I'm on FreeBSD 10.3-p4, trying to compile with both GCC 4.8 and clang
>  > 3.4.  I get the same error with both compilers
>  >
>  > compile command (clang)
>  >
>  > ./otp_build setup -a --prefix=/home/gsmith
>  > --with-wx-config=/usr/local/bin/wxgtk2u-3.0-config
>  >
>  > compile command (gcc)
>  >
>  > env CC=gcc48 CXX=g++48 ./otp_build setup -a --prefix=/home/gsmith
>  > --with-wx-config=/usr/local/bin/wxgtk2u-3.0-config
>  >
>  > error message:
>  >
>  > In file included from beam/sys.h:105:0,
>  >                  from drivers/unix/unix_efile.c:32:
>  > sys/unix/erl_unix_sys.h: In function 'erts_check_fpe_thorough':
>  > sys/unix/erl_unix_sys.h:424:5: error: implicit declaration of function
>  > 'finite' [-Werror=implicit-function-declaration]
>  >      return erts_check_fpe(fp_exception, f) || !isfinite(f);
>  >      ^
>
> There is a configuration-time check for having isfinite() or finite(),
> and I'd be very surprised of a recent FreeBSD didn't have at least one
> of them.
>

FreeBSD has the "isfinite" call, but not "finite".  Some comments in
erl_unix_sys.h
mention that gcc emits assembler for calls to "finite" which is
"significantly faster".
The configure logs for clang show that "finite" is present, and the generated
"erl_compile_flags.h" confirms this with both HAVE_FINITE 1 and HAVE_ISFINITE 1.

Seems to me that HAVE_FINITE should be 0, and HAVE_ISFINITE should be 1 in
order to trigger the appropriate behavior from the IFDEF chain in erl_unix_sys.h

Any pointers for how to figure out where the configure script or the
make_compiler_flags
is going wrong?

> However, the check is a linkage check, so it's possible that finite()
> isn't declared, which would trigger the above warning.
>
> The code in erts/emulator/sys/unix/erl_unix_sys.h to choose which one to
> use (finite or isfinite) is a bit convoluted, and it's possible it makes
> the wrong choice sometimes.
>
>  > In file included from beam/erl_threads.h:268:0,
>  >                  from beam/erl_smp.h:28,
>  >                  from beam/sys.h:467,
>  >                  from drivers/unix/unix_efile.c:32:
>  > beam/erl_term.h: At top level:
>  > beam/erl_term.h:57:8: error: #error Hipe on 64-bit needs a real mmap
>  > as it does not support the literal tag
>  >  #      error Hipe on 64-bit needs a real mmap as it does not support
>  > the literal tag
>  >         ^
>
> This means that ERTS_HAVE_OS_PHYSICAL_MEMORY_RESERVATION isn't set in your
> environment.  Can you check if FreeBSD's <sys/mman.h> has MAP_FIXED and
> MAP_NORESERVE, perhaps with slightly different names?

My /usr/include/sys/mman.h has:

#define MAP_FIXED        0x0010 /* map addr must be exactly as requested */
#define MAP_NORESERVE    0x0040 /* Sun: don't reserve needed swap area */

>
> As far as I can tell from git log, this change is due to some changes in
> erts and not directly caused by HiPE (as the messages would imply).
>

Agree, the HiPE error is only the latest error in the log.  The error
appears a few
times in the compilation.  Hoping to get this fixed generally, since
it seems to affect
more than HiPE.


>  > cc1: some warnings being treated as errors
>  > x86_64-unknown-freebsd10.3/Makefile:697: recipe for target
>  > 'obj/x86_64-unknown-freebsd10.3/opt/smp/unix_efile.o' failed
>  >
>  > I'll be happy to assist in testing out patches if necessary.
>
> You may be able to silence both errors by configuring with --disable-hipe,
> but the real problem isn't in HiPE but in the areas I described above.
_______________________________________________
erlang-bugs mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-bugs