On armv7hl, OCaml 4.08.0 beta 3 FTBFS with "warning: implicit declaration of function 'Saved_return_address'"

[rwmjones]

gcc -c -O2 -fno-strict-aliasing -fwrapv -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=armv7-a -mfpu=vfpv3-d16 -mtune=generic-armv7-a -mabi=aapcs-linux -mfloat-abi=hard -Wall -g -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DCAML_NAME_SPACE  -DOCAML_STDLIB_DIR='"/usr/lib/ocaml"'  -DNATIVE_CODE -DTARGET_none -DMODEL_default -DSYS_unknown   -o backtrace_n.o backtrace.c
backtrace_nat.c: In function 'caml_next_frame_descriptor':
backtrace_nat.c:51:13: warning: implicit declaration of function 'Saved_return_address' [-Wimplicit-function-declaration]
   51 |       *pc = Saved_return_address(*sp);
      |             ^~~~~~~~~~~~~~~~~~~~
backtrace_nat.c:59:44: warning: implicit declaration of function 'Callback_link' [-Wimplicit-function-declaration]
   59 |       struct caml_context * next_context = Callback_link(*sp);
      |                                            ^~~~~~~~~~~~~
backtrace_nat.c:59:44: warning: initialization of 'struct caml_context *' from 'int' makes pointer from integer without a cast [-Wint-conversion]

The full log is here:
https://kojipkgs.fedoraproject.org//work/tasks/23/34470023/build.log

[xavierleroy]

-DTARGET_none

That's the problem. Autoconfiguration did not recognize your platform as supported by the native-code compiler (ocamlopt). I agree it should have failed earlier, at the beginning of make opt. But the priority is to understand why your platform is not supported. What does

./config/gnu/config.guess 

reports?

(Paging @shindere .)

[rwmjones]

I chucked out all my ARM servers when I moved to RISC-V, so now I've got to do all this by submitting scratch builds to the Fedora build system :-( It took a bit of time but here's the answer:

Building for target armv7hl
...
+ ./config/gnu/config.guess
armv7l-unknown-linux-gnueabihf

(For aarch64 it prints: aarch64-unknown-linux-gnu)

Anyway while I was investigating this I found out something interesting: The Fedora build system searches over the tree and replaces any config.sub or config.guess files it finds with the upstream (I think GNU) versions. Not sure whether this is a good or a bad thing, but here we are.

The full build logs are here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=34473066

[rwmjones]

Sorry ignore all that, I understand why the configure test is failing. It's because I'm using:

./configure --host=

Now the reason I have to do that is because I had an earlier problem on x86_64. Normally Fedora sets --host automatically to (on x86_64) --host=x86_64-redhat-linux-gnu. However that causes the build to fail at:

x86_64-redhat-linux-gnu-gcc -c -DSYS_linux -I../runtime -DMODEL_default -o amd64.o amd64.S || \
{ echo "If your assembler produced syntax errors, it is probably";\
          echo "unhappy with the preprocessor. Check your assembler, or";\
          echo "try producing amd64.o by hand.";\
          exit 2; }
/bin/sh: x86_64-redhat-linux-gnu-gcc: command not found
If your assembler produced syntax errors, it is probably
unhappy with the preprocessor. Check your assembler, or
try producing amd64.o by hand.
make[2]: *** [Makefile:368: amd64.o] Error 2

So I'll stop setting --host= but there's still an issue with configure.

[rwmjones]

Let's close this, I'll investigate the host/GCC thing separately.

[rwmjones]

OK I see the problem. The configure.ac file assumes that if --host was set then you must be cross-compiling, but that's not actually a correct assumption. It only applies I think if build != host, but even better is to use the autoconf AC_CHECK_TOOL macros which already take into account the correct rules for cross-compiling.

[xavierleroy]

I confirm that armv7l-unknown-linux-gnueabihf is supported and selects the ARM back-end.

@shindere @dra27 : could you please check configure.ac in light of @rwmjones' comment?

[shindere]

Sorry for the late response here. rwmjones (2019/04/26 08:16 -0700):

OK I see the problem. The `configure.ac` file assumes that if `--host` was set then you must be cross-compiling, but that's not actually a correct assumption. It only applies I think if build != host, but even better is to use the autoconf `AC_CHECK_TOOL` macros which already take into account the correct rules for cross-compiling.

So where exactly in configure.ac do you think `AC_CHECK_TOOL` should be used?

[rwmjones]

Anywhere you need to check for a "tool" (eg. ‘as’). Probably best to read the autoconf documentation on this as it will explain it better than I can.

https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Generic-Programs.html

[rwmjones]

This bug is back again in 4.09:

https://kojipkgs.fedoraproject.org//work/tasks/546/39440546/build.log

[rwmjones]

I'm carrying this patch which removes the incorrect use of $host_alias. As mentioned before use AC_CHECK_TOOL instead.
-AS_IF([test -n "$host_alias"], [toolpref="${host_alias}-"], [toolpref=""]) +#AS_IF([test -n "$host_alias"], [toolpref="${host_alias}-"], [toolpref=""])

[rwmjones]

OK I fixed my workaround and got it to compile again. I need the patch in the previous comment, plus:

./configure --host=`build-aux/config.guess`

[shindere]

@rwmjones: in
#8647 (comment), you wrote
this:

OK I see the problem. The configure.ac file assumes that if --host was set then you must be cross-compiling, but that's not actually a correct assumption.

Well, that's not completely true. Cross-compiling is assumed only if the
argument of --host differs from the one of --build.

One tricky thing, though, is that autoconf's documentation says:

If you mean to override the result of 'config.guess', use '--build', not '--host', since the latter enables cross-compilation. For historical reasons, whenever you specify '--host', be sure to specify '--build' too; this will be fixed in the future.

I am not sure this has ever been fixed, so it may be a good idea to make
sure both --build and --host are specified.

[shindere]

I just opened PR #9315 to try to fix this problem.

[rwmjones]

I think I was referring to this code:

AS_IF(
  [test x"$host" = x"$target"],
    [cross_compiler=false],
    [cross_compiler=true])

Anyway I'll try out your patch in the other PR.

[rwmjones]

BTW using AC_MSG_CHECKING/AC_MSG_RESULT around your own tests really helps with debugging, ie:

--- a/configure.ac
+++ b/configure.ac
@@ -510,10 +510,12 @@ AS_IF(
 
 # Are we building a cross-compiler
 
+AC_MSG_CHECKING([if we are cross compiling])
 AS_IF(
   [test x"$host" = x"$target"],
     [cross_compiler=false],
     [cross_compiler=true])
+AC_MSG_RESULT([$cross_compiler])
 
 # Checks for programs

It will produce configure output like:

checking if we are cross compiling... false

[shindere]

rwmjones (2020/02/18 07:59 -0800):

I think I was referring to this code: ``` AS_IF( [test x"$host" = x"$target"], [cross_compiler=false], [cross_compiler=true]) ```

Ah. It turns out there are I think two notions of cross-compiler around. The autoconf one takes into account build and host and that one takes into acocunt host and target. It was introduced to enable a behaviour from the pre-autoconf configure script but so far I never ported this feature and nobody complained that it was missing. I think that code you mention is not relevant for your problem. *

Anyway I'll try out your patch in the other PR.

Thanks.