I wish to use an erlang client library to communicate with an mqtt broker for one of my projects. So I've started an application using rebar3's built-in templates and added emqttc as a dependency. Since erlang/otp 21 does not have support for gen_logger(emqttc depends on gen_logger) and the tuple_calls compiler options do not suffice, I had to downgrade to erlang#20 according to this post.
Now the issue with downgrading erlang is that, none of rebar3's commands(clean/compile/shell/report etc) work as expected and my previous projects built with rebar3 do not compile, I get to see this error message:
=ERROR REPORT==== 21-Aug-2018::12:54:29 === Loading of /usr/local/bin/rebar3/rebar/ebin/rebar3.beam failed: badfile escript:
exception error: undefined function rebar3:main/1 in function
escript:run/2 (escript.erl, line 759) in call from escript:start/1
(escript.erl, line 277) in call from init:start_em/1 in call from
init:do_boot/3
=ERROR REPORT==== 21-Aug-2018::12:54:29 === beam/beam_load.c(1863): Error loading module rebar3: This BEAM file was compiled for a later
version of the run-time system than 20. To fix this, please
recompile this module with an 20 compiler. (Use of opcode 160; this
emulator supports only up to 159.)
I've uninstalled and reinstalled rebar3, looked up on the web for this but nothing's clear and specific to rebar. Any help on this would be appreciated.
This may not be the exact answer for your question. But it may give you and idea.
What about using Docker. Its an easy way to keep your environment clean and neat.
If you use docker, you just have to include your new erlang version in Dockerfile as an environment variable.
ENV OTP_VERSION="20.3.6"
Check your _build/prod/rel/YOURAPPNAME/ directory. Most probably it has a release which doesn't match your erlang version. You can safely delete this directory and rebuild using rebar3 compile
Related
I have looked at many other posts related to this issue and have tried each solution. None have worked in my case, including copying over the makevars from Rcpp. Anyhow, when building on Travis I get the following error
undefined symbol: dpotrf_’
The interesting note is that the package installs fine on windows, macOS, and linux.
here is my repo R package
I can reproduce the failure on a very standard Debian testing system (which I use for the extensive reverse dependency checks on Rcpp and RcppArmadillo).
After installing packages bain and BFpack (I had the rest) I attempted to build the tar.gz from your pristine just-checked-out sources. And I get:
*** installing help indices
*** copying figures
** building package indices
** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for ‘BGGM’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/tmp/Rinst106c6ed5251a/00LOCK-BGGM/00new/BGGM/libs/BGGM.so':
/tmp/Rinst106c6ed5251a/00LOCK-BGGM/00new/BGGM/libs/BGGM.so: undefined symbol: dpotrf_
Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/tmp/Rinst106c6ed5251a/BGGM’
-----------------------------------
ERROR: package installation failed
This appears to be a moderately complex and large enough package so please pardon me for not diving in and debugging. I would suggest you simplify with smaller mock packages to see what may be wrong. (dpotrf is a fairly standard LAPACK routine so something somewhere calls it. Maybe you call it explicitly. Maybe you did a Fortran-to-C mapping wrong. Maybe you have something wrong in how you interface with RcppArmadillo. Hard to tell...)
Edit: You committed compiled code and a Windows library. "Don't do that." When Travis builds it also starts from a git checkout as I did. That may be the difference.
Edit 2: It wasn't, but your R code mixes .Call() with generated entry points (ie via RcppExports.cpp and RcppExports.R). I have seen that blow up for other people. That may be something to look into.
Disclaimer: I work with D_Williams, but I figured out the problem, and others may find it useful.
A functioning configure.ac was present, and a Makevars.in is present.
The problem is that the configure file was not yet generated. This is an autotools/autoconf setup. To resolve it, I ran autoconf in the package directory, which generated the configure file. That configure file is then executed when R builds the package. The configure file modifies the Makevars.in and creates Makevars. That Makevars file ultimately defines where to find libraries, includes, compilers, compiler options, etc.
If you do not generate the configure file from configure.ac using autoconf, then there is no configure file to be executed, and no Makevars to define the needed options at compile time. Therefore, the compiler is not fully configured, and it will fail.
TLDR: If you have an configure.ac, you must run autoconf on it, and commit that configure file to your repo. R needs to execute it to have a functioning Makevars.
I've always been able to compile sources from git repository https://github.com/GNOME/vala.git on my PC running "Linux Mint 18.3 Cinnamon 64-bit". I have the latest valac (0.42.4-0ubuntu1~16.04~valateam0) installed.
The last successful compile I did was from version 0.40.0.257-40b5-dirty. Today, I downloaded the latest vala.git, but when i run ./configure I get:
./configure: line 12579: syntax error near unexpected token `$flag,TEST_CFLAGS="$TEST_CFLAGS $flag"'
./configure: line 12579: ` AX_CHECK_COMPILE_FLAG($flag,TEST_CFLAGS="$TEST_CFLAGS $flag")'
Do I need to make additional environment changes? Not sure were to go from here.
Compiling Vala from source is a good start in contributing back to the Vala project. Vala currently uses autotools as its build system. For Ubuntu AX_CHECK_COMPILE_FLAG is provided by a separate package: autoconf-archive. See the autotools syntax error with ax_check_compile_flag answer on Stack Overflow for more details. So you should just need to install autoconf-archive.
By the way the main repository for Vala is in GNOME's GitLab instance: https://gitlab.gnome.org/GNOME/vala You may want to clone that one instead. The GitLab instance also allows issues to be raised and merge requests to be submitted.
I am running Yaws server version 2.0.2 with Erlang/OTP 18 [erts-7.3] on ubuntu 16.04 and installed it using apt. Now when i try to run this example i get
undef yaws_dynopts random_seed. I have verified that module yaws_dynopts is not loaded OR compiled.
error is:
{undef,[{yaws_dynopts,random_seed,[6885,441906,806568],[]},
{m1,'-out/1-fun-0-',1,
[{file,"/home/my_account/.yaws/yaws/default/m1.erl"},{line,16}]}]}
which corresponds to line in example:
yaws_dynopts:random_seed(erlang:phash(node(), 100000),
erlang:phash(A2, A3),
A3),
Do anyone have solution to this? And is it a bug?
Does l(yaws_dynopts). also cause an error? I'm starting to believe whoever packaged your version of Yaws didn't do it correctly, leaving out this critical module. You should look to see if version 2.0.3 is available, or alternatively consider building your own from source. We're currently at 2.0.4.
I am new to Erlang, I have been trying to install Erlang and ejabberd on EC2 ubuntu machine, everything went well till I started compiling some external modules in ejabberd. It started throwing error undefined parse transform 'lager_transform'.
I tried everything which is as below:
Did rebar get-deps, make clean, make deps, make install. After this I am able to see that lager_transform.beam is made and present in /lib/ folder.
Checked rebar.config file, it had lager deps on top, which is widely suggested, no help even after that.
Added -compile[{parse_tranform},{lager_transform}] on top of module, even then their is no luck.
I am really blocked on this, and not able to complete the installation. I have done this before on fedora with ejabberd 15.11 and otp 18.2, at that time it was using p1_logger instead of lager. But now when I am installing fresh with otp 18.2 and ejabberd 16.0 or 15.11, I am getting lager_transform undefined error.
Please make sure you compile ejabberd as described in documentation: http://docs.ejabberd.im/admin/guide/installation/#installing-ejabberd-from-source-code
For example, you can compile it with:
./configure --enable-lager --enable-mysql
make
You need to run configure and make to set properly the build chain.
Is it possible to use Erlang with ZMQ on Windows? I have tried to use erlzmq2, but rebar fails to compile it with cryptic linker errors. Of course i can invest some time and investigate makefiles, but maybe other way exists?
Update
Whose who are interested in compilation errors can download latest erlang for windows and try to build erlzmq2 (Visual Studio 2012 compiler, msys sh and make). Error looks like:
cl : Command line error D8021 : invalid numeric argument '/Wl,-DLL,-IMPLIB:.libs
\zmq.dll.lib'
Makefile:541: recipe for target 'libzmq.la' failed
make[3]: *** [libzmq.la] Error 2
Please note that other erlang libs are compiling with this setup without any problems.
Your problem lies in compiling ZeroMQ for Windows. You haven't actually gotten to any Erlang yet. Here are some of the clues that tell you this:
Makefile:541: recipe for target 'libzmq.la' failed
This line says there's a problem on line 541 of the Makefile. But in erlzmq2, you can see that neither the main Makefile nor the c_src Makefile (which is what would build libzmq.la) has anything close to that many lines.
make3: * [libzmq.la] Error 2
The [3] means that you're 3 invocations deep into Make. Specifically, you started at the top-level Makefile, which called Rebar, which ran make -C c_src, which downloads ZeroMQ version 3.2.2 and tries to do a ./configure && make
To fix this Unix-style, go into the deps directory of erlzmq2 and figure out how to correctly compile ZeroMQ. Hopefully, you will just need to pass some arguments to configure. Then you can edit c_src/Makefile and set ZMQ_FLAGS to whatever you had to do for configure, clean, and make.
To fix it more Windows-style, follow the Windows build instructions for ZeroMQ. Put the compiled libzmq under deps and just edit the c_src Makefile to a no-op.
Finally, if you don't actually need to run this code on Windows, but are just using Windows as your development environment, I think you'll have the easiest time by running the build inside a Linux VM (not a hard thing at all with tools like Vagrant). Sorry, but Unix is the real system for this stuff; Windows support is an afterthought.