jose_server.erl - syntax error before: 'catch', function handle_call/3 undefined

licaon-kter commented 2 months ago

Environment

Erlang version: Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 11.1.8 (from source)
OS: Debian Bullseye arm64
rebar built at https://github.com/erlang/rebar3/commit/b64d94f4e6fb738c4a3004faf833e0b9617d86a8 (from source)

Trying to build HEAD (13ebe89fdc8530986006c5fe628d9507588f4608)

...
===> Compiling yconf
===> Compiling jose
===> Compiling _build/default/lib/jose/src/jose_server.erl failed
_build/default/lib/jose/src/jose_server.erl:137: syntax error before: 'catch'

_build/default/lib/jose/src/jose_server.erl:32: function handle_call/3 undefined

make: *** [Makefile:215: _build/default/lib/.built] Error 1

Last good build that I had was dbf0fb8e8610aaff79c48675dd6f600303263db5

git bisect says:

da8c9f33572eb6c6ccff8f9fe71cd7b629bae575 is the first bad commit
commit da8c9f33572eb6c6ccff8f9fe71cd7b629bae575
Author: Badlop <badlop@process-one.net>
Date:   Tue Apr 23 13:45:14 2024 +0200

    rebar.lock: Track it, now that rebar3 uses loose dependency versioning

    This is recommended in Rebar3 documentation:
      [Lock files] should always be checked into source control.
      https://rebar3.org/docs/configuration/dependencies/#lock-files

 .gitignore |  1 -
 rebar.lock | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 87 insertions(+), 1 deletion(-)
 create mode 100644 rebar.lock

licaon-kter commented 2 months ago

Looks like those commits helped, HEAD (392d7ee30bed0efaaa9db54c3c3429b0817f43c1) builds fine now.

badlop commented 1 month ago

The problem explained in this issue is a follow up of the previous one, both related to rebar.lock tracking:

4212 involves dependencies that are disabled using ./configure
4213 involves dependencies that use different version depending on the Erlang/OTP version.

Erlang version: Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 11.1.8 (from source)

Ok, that is Erlang/OTP 23.2.

For erlang above 23, rebar.config says to use jose 1.11.10, which uses the new try catch Class:Reason:Stacktrace. And the rebar.lock file tracked in git mentions a commit in that version.

Otherwise (erlang not above 23), rebar.config says to use 1.11.1, which does not use the new try catch Class:Reason:Stacktrace. However, the rebar.lock file tracked in git does not mention a commit in that version.

This is fixed in https://github.com/processone/ejabberd/commit/f7dc4fa2ac604e46c20ca0353a6cadb76ffdf1c8

BTW, this problem was not detected by the CI or Runtime workflows because they explicitly called "make update", which gets the dependencies as stated in rebar.config. This is fixed in https://github.com/processone/ejabberd/commit/025e2a5760c8452b9541da67f6f391ad3e70772a

licaon-kter commented 1 month ago

Erlang version: Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 11.1.8 (from source)

Ok, that is Erlang/OTP 23.2.

Oh wait, I did a mistake :(

That's the system installed one, and erl is in path hence its output was pasted.

I actually built a newer one and forgot to use its erl which would say: Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 14.1.1

BTW, this problem was not detected by the CI or Runtime workflows because they explicitly called "make update", which gets the dependencies as stated in rebar.config.

But on a fresh clone I can't run make update, right?

Fresh clone I do: autogen/configure/make

If I update the local clone, then I do: git pull/autogen/make update/configure/make

This was learned from experience, aka updating a tree without doing make update would yield strange results.

badlop commented 1 month ago

I actually built a newer one ... emulator version 14.1.1

erts 14.1.1 was included in https://www.erlang.org/patches/otp-26.1.2

If you are using OTP 26, then the version of Jose that rebar3 downloads is not affected (or should not be affected) by commit https://github.com/processone/ejabberd/commit/f7dc4fa2ac604e46c20ca0353a6cadb76ffdf1c8 ...

But on a fresh clone I can't run make update, right? Fresh clone I do: autogen/configure/make

Well, it can be used anytime, either on clean build or when rebuilding. Of course, it makes little sense to run in on a clean build.

To test the build process, CI and Runtime test workflows should not use it (fixed in https://github.com/processone/ejabberd/commit/025e2a5760c8452b9541da67f6f391ad3e70772a ), that way they test the typical (and documented) build steps: ./autogen.sh && ./configure && make && make install/prod/whatever

If I update the local clone, then I do: git pull/autogen/make update/configure/make This was learned from experience, aka updating a tree without doing make update would yield strange results.

Right, make update is useful when rebuilding after rebar config files have changed (git pull or whatever), to get the dependencies versions that may now be required.

processone / ejabberd