rebar3 tar fails with custom system libs

[elbrujohalcon]

According to the docs, this is a valid configuration for relx:

{include_erts, "/path/to/erlang"},
{system_libs, "/path/to/erlang"},

But running rebar3 tar with that configuration, leads me to…

===> Uncaught error: {case_clause,"../erts/erlang"}
===> Stack trace to the error location:
[{rlx_tar,maybe_system_libs,4,
          [{file,"/opt/rebar3/_build/default/lib/relx/src/rlx_tar.erl"},
           {line,106}]},
 {lists,flatmap,2,[{file,"lists.erl"},{line,1250}]},
 {lists,flatmap,2,[{file,"lists.erl"},{line,1250}]},
 {rlx_tar,make_tar_opts,4,
          [{file,"/opt/rebar3/_build/default/lib/relx/src/rlx_tar.erl"},
           {line,71}]},
 {rlx_tar,make_tar,3,
          [{file,"/opt/rebar3/_build/default/lib/relx/src/rlx_tar.erl"},
           {line,16}]},
 {relx,build_tar,3,
       [{file,"/opt/rebar3/_build/default/lib/relx/src/relx.erl"},{line,164}]},
 {rebar_relx,do,2,[{file,"/opt/rebar3/src/rebar_relx.erl"},{line,57}]},
 {rebar_core,do,2,[{file,"/opt/rebar3/src/rebar_core.erl"},{line,154}]}]

Which comes from this case statement.

[rcc]

I'm also seeing this. Going back to 3.13.2 is working. Have not bisected further.

[tsloughter]

@rcc how were you using this feature?

[rcc]

@tsloughter I'm building an Erlang release for the Raspberry Pi in a Buildroot environment.

[tsloughter]

@rcc so the system libs are the same as the erts? Just not having system_libs should work if you set include_erts to the path. I think...

[rcc]

@tsloughter I'll be honest that my knowledge is a little rusty here. This is a project I built 3 years ago and was just dusting off. When I updated packages, several things broke. Here's what I think is happening.

Buildroot builds an erts and set of system_libs for the rpi. This is what the release will run on when it's on the target. The build machine is an x86 linux host (cross compilation environment). The OTP and erts versions between the host and target are not in sync. rebar3/relx is running against the host installation, so you have to set the target paths when packaging a release for the target.

Here are parts of my rebar.config.script that modify the paths. STAGING_DIR is an env variable that buildroot sets for the cross compilation environment.

%% if STAGING_DIR environment set, return a modified path to the erlang
%% system. otherwise, return the passed Default.
StagedSystemFun =
    fun(Default) ->
        case os:getenv("STAGING_DIR") of
            false -> Default;
            [] -> Default;
            Dir -> lists:flatten([Dir,"/usr/lib/erlang"])
        end
    end.

FilterRelxFun =
    fun({release, {Relname, Ver}, Apps}) ->
            case ReposVer of
                false -> {release, {Relname, Ver}, Apps};
                [] -> {release, {Relname, Ver}, Apps};
                V -> {release, {Relname, V}, Apps}
            end;
       ({include_erts, true}) -> {include_erts, StagedSystemFun(true)};
       ({system_libs, true}) -> {system_libs, StagedSystemFun(true)};
       (T) -> T
    end.

[rcc]

I find that I get errors like the following if I don't also set the path for system_libs. ERROR: architecture for "/usr/local/erlrel/lib/runtime_tools-1.12.3/priv/lib/trace_file_drv.so" is "Advanced Micro Devices X86-64", should be "ARM"

Both need to be set to the staging install.

[tsloughter]

@rcc interesting, ok, thanks. It sounds like there may be a deeper bug where the OTP for the erts dir is not used for system libs.

[rcc]

Looks like 3.14.0-rc1 is the first tag where it breaks.

[tsloughter]

I was looking into this and it is more complicated than I first thought.

The issue is relx no longer searches for applications itself but relies on what rebar3 tells it to use. Rebar3 doesn't read the system_libs config option out of relx and thus passes the currently used system libs and not ones in that directory.

I guess I need to change rebar_relx module to check for that config option and do a new search for system libs.