blt/port_compiler

issue compiling bcrypt with latest port compiler (v1.9.1)

Closed this issue ยท 19 comments

Hi,

With the v1.9.1 version published on hex we have an issue building bcrypt (a VerneMQ dependency). We get:

bcrypttest $ rebar3 compile
===> Verifying dependencies...
===> Package bcrypt-1.0.2 not found. Fetching registry updates and trying again...
===> Updating package registry...
===> Writing registry to /home/lhc/.cache/rebar3/hex/default/registry
===> Generating package index...
===> [appsignal:1.6.2], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.6.0], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.6.0-beta.1], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.6.1], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.6.0-alpha.1], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> Writing index to /home/lhc/.cache/rebar3/hex/default/packages.idx
===> Fetching bcrypt ({pkg,<<"bcrypt">>,<<"1.0.2">>})
===> Downloaded package, caching at /home/lhc/.cache/rebar3/hex/default/packages/bcrypt-1.0.2.tar
===> Fetching pc ({pkg,<<"pc">>,<<"1.9.1">>})
===> Downloaded package, caching at /home/lhc/.cache/rebar3/hex/default/packages/pc-1.9.1.tar
===> Compiling pc
===> Compiling bcrypt
===> Compiling /home/lhc/dev/erl.io/temp/bcrypttest/_build/default/lib/bcrypt/c_src/*.c
===> cc: fatal error: cannot specify -o with -c, -S or -E with multiple files
compilation terminated.

The above is reproducible with a clean erlang project with the following rebar.config file:

{erl_opts, [debug_info]}.
{deps, [
       {bcrypt, "1.0.2"}]}.

The last version i I could find is this:

{overrides,
[
 {override, bcrypt,
  [
   {plugins, [{pc, {git, "git://github.com/blt/port_compiler", {ref, "2ad49d339ae7a7f43ea3fed43d9bd321ad29a823"}}}]}
  ]
 }
]
}.

I used rebar v3.5.3.

kpy3 commented

Similar problem with jiffy, enif_protobuf and probably all other NIF projects which uses
something like

{port_specs, [
    {"priv/my_lib.so", [
        "c_src/*.c",
        "c_src/*.cc"
    ]}
]}.

Similar problems with stun module

04:33:52 ===> Compiling /home/deps/stun/c_src/*.c
04:33:52 ===> cc: error: c_src/*.c: No such file or directory
04:33:52 cc: fatal error: no input files
04:33:52 compilation terminated.```

Same issue with erlexec and gcc 4.8.x:

===> Compiling [...]/_build/default/lib/erlexec/c_src/*.cpp
===> g++: fatal error: cannot specify -o with -c, -S or -E with multiple files

Quick fix is to pin down the plugin version you're importing. Hex.pm shows pc 1.9.1 was released yesterday; 1.8.0 still works well for me.

{plugins,
 [{pc, "1.8.0"} % rather than just 'pc'
 ]}.

The problem seems to arise only for compiling dependencies. For example, if I try to compile erlexec directly, I have no problem. On the other hand if I put erlexec in dependence (of test in my case), the compilation fail.

@Tuncer ^. please next time you ask me to publish first test it on jiffy and bcrypt.

Should I publish a 1.9.2 that is just 1.8.0? or are people ok pinning for now?

@glejeune ah ok, @Tuncer please test them as dependencies of a project before the next release.

@tsloughter I suggest you to publish 1.9.2. Most projects are using unpinned pc since it is the recommended way according to rebar3 example: https://www.rebar3.org/docs/using-available-plugins#section-port-compiler

There is no way to ask all dependency maintainers to pin pc.

Ok, I've published 1.10.0 which is really 1.6.0. Please let me now that it is working, you'll need to do a rebar3 update to fetch the latest hex registry and rebar3 plugins upgrade pc

Ok, tested. It works now. Cheers!

Yep, this fixes the issue. I think we'll keep the port compiler pegged for the future (or until rebar3 can automatically lock plugins if that makes sense) to make our builds as reproducible as possible.

Thanks for the fast fix! Very much appreciated!

Sorry about the regression, will look into it. @tsloughter, can you hook up a CI service in the project settings so that tests can be added?

The regression was introduced in #37 (/cc @cjkjellander). Given the existing config files out there, let's revert it. See #49.

#50 is a compromise that merely warns but doesn't pass the pattern as is to CXX/CC.

Wider testing welcome.

Any negative test results? Otherwise, I will tag a new release.

Just tested using master (9412b2c) for compiling VerneMQ and that works. ๐Ÿ‘

Thanks, tagged v1.10.1, to be published on hex.pm.