g-andrade/tls_certificate_check

error on Erlang/OTP 23

benoitc opened this issue · 14 comments

the code doesn't compile on ths version and return the following error:

src/tls_certificate_check.erl:99: http_uri:parse/1 is deprecated and will be removed in OTP 25; use use uri_string functions instead

Are you pulling from master? I'm able to compile on OTP 23 without warnings, even after deleting _build.

Edit: also, if you look at .travis.yml, 23.0 is being tested and CI is passing.

Sure. For reference, here's the output I get:

tls_certificate_check git:(master) ✗ rm -rf _buildtls_certificate_check git:(master) ✗ erl
Erlang/OTP 23 [erts-11.1.2] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe] [systemtap]

Eshell V11.1.2  (abort with ^G)
1> 
BREAK: (a)bort (A)bort with dump (c)ontinue (p)roc info (i)nfo
       (l)oaded (v)ersion (k)ill (D)b-tables (d)istribution
^C%                                                                                                                                                   tls_certificate_check git:(master) ✗ rebar3 compile
===> Verifying dependencies...
===> Fetching certifi v2.5.3
===> Fetching parse_trans v3.3.0
===> Fetching ssl_verify_fun v1.1.6
===> Analyzing applications...
===> Compiling ssl_verify_fun
===> Compiling parse_trans
===> Compiling certifi
===> Analyzing applications...
===> Compiling tls_certificate_checktls_certificate_check git:(master) ✗

Building OTP 23.1.5 now, to check whether I can reproduce the issue.

Building OTP 23.1.5 now, to check whether I can reproduce the issue.

Both make test check and rebar3 compile ran without issues, following full repo clean up with git clean -ffdx.

Strange...

@benoitc which rebar3 version are you using?

% rebar3 version
rebar 3.13.2 on Erlang/OTP 23 Erts 11.1.3

which rebar3 version are you using?

Things also work for me when using the latest version of rebar3:

% rebar3 version
rebar 3.14.3 on Erlang/OTP 23 Erts 11.1.3

The only way I see this issue happening is if the NO_URI_STRING macro is being defined by mysterious, outside forces.

Edit: ...or if the regex responsible for defining said macro is matching something unintended.

@benoitc I have a hunch this issue might be similar to rebar3's #2105.

If you run make shell within tls_certificate_check's repo and invoke rebar_utils:get_arch(), what does it return?

> rebar_utils:get_arch().
"23.1.5-x86_64-unknown-linux-gnu-64"

@benoitc I've pushed a tentative fix into the fix/compilation-errors-on-macos-bigsur branch.

Please let me know whether that fixes the issue.

@g-andrade bae3696 worked for me.

rebar 3.14.3 on Erlang/OTP 23 Erts 11.1

1> rebar_utils:get_arch().
"23.1-x86_64-apple-darwin20.1.0-64"

Fix released under 1.1.1 (published to Hex as well.)

Thanks for reporting the issue!

thanks :)

@g-andrade bae3696 worked for me.

rebar 3.14.3 on Erlang/OTP 23 Erts 11.1

1> rebar_utils:get_arch().
"23.1-x86_64-apple-darwin20.1.0-64"

:-) I once battled with "win" in "darwin". Good times!