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.
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.
So, I am working on an embedded project for a cortex m7 microcontroller (ATSAME70Q21). The code is written in Atmel Studio 7, but I want to build it in a Debian environment through Docker (gcc docker image is Debian-buster based if I'm not mistaken) so that I can work in a Continuous Integration workflow.
At the moment I am trying to manually construct a Makefile, based on the generated makefile by the IDE, but that seems like the wrong way to handle this problem. Maybe I am too tunnel-visioned to notice different solutions. So I would like some help from folks who maybe have struggled with this problem before.
Thanks in advance.
I solved this problem the following way by mimicking the output of Atmelstudio into a CMakeLists file.
First I analyzed the generated makefile from the debug build to discover what files were built, what compiler flags were used and what programs were called.
Then I compared the generated makefile from the release build with the debug build to discover the differences.
With this information, I made a CMake file. For now, I GLOB_RECURSE all my source files, but I could crawl the Atmelstudio *.cproj file to find out what files are required.
This might not be the ideal answer, but it solves my problem.
I'm trying to compile PyPy for use on an OpenWrt configuration, but I am having a really hard time doing it.
My main problems are:
Each time I change the Makefile I am forced to start the translating process of PyPy again. Is there a way to avoid this?
Would copying just the compiled pypy-c and lib*.so binaries do it, or would I have to copy everything from the compiled files of PyPy?
Here is the directory structure after running make on the files.
How do I specify the version of GCC to use? I've tried to do this without success.
How would I get the interpreter to run after installing it on OpenWrt?
One can also compile PyPy using PyPy itself, which gives a .tar file with a different structure (no Makefile, pypy executable etc). Can I use that instead of building it from the source?
Here is my Makefile.
include $(TOPDIR)/rules.mk
PKG_NAME:=PyPy
PKG_VERSION:=5.8.0
PKG_RELEASE:=1
PKG_MD5SUM:=504c2d522595baf8775ae1045a217a2b120732537861d31b889d47c340b58bd5
PKG_SOURCE_NAME:=pypy2
PKG_SOURCE_URL:=https://bitbucket.org/pypy/pypy/downloads/
PKG_SOURCE:=$(PKG_SOURCE_NAME)-v$(PKG_VERSION)-src.tar.bz2
PKG_BUILD_DEPENDS:=python
PKG_CAT:=bzcat
PKG_BUILD_DIR:=$(BUILD_DIR)/$(BUILD_VARIANT)$(PKG_SOURCE_NAME)-v$(PKG_VERSION)-src
include $(INCLUDE_DIR)/package.mk
$(call include_mk, python-package.mk)
define Package/PyPy
SECTION:=utils
CATEGORY:=Utilities
TITLE:=PyPy
URL:=https://pypy.org/index.html
DEPENDS:=+libffi +libexpat +libunwind
endef
define Package/PyPy/description
PyPy is an alternate implementation of the Python programming language written in Python.
This distribution is for Linux architecture, using Python 2.
endef
define Package/PyPy/install
$(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/pypy-c $(1)/usr/bin
$(CP) (PKG_BUILD_DIR)/*.so $(1)/usr/lib
$(INSTALL_BIN) $(PKG_BUILD_DIR)/pypy/bin/* $(1)/usr/bin
endef
define Build/Compile
$(MAKE) -C $(PKG_BUILD_DIR)
endef
$(eval $(call BuildPackage,PyPy))
I would need to see the entire process: the part of the Makefile above, the other pieces such as rules.mk, package.mk, command line arguments and environmental variables in order to understand what is not working
The Makefile in question is not supported, the developers do not use it, and as you discovered it does not work well. As described in the build page, building PyPy from source is a four part process, and the Makefile mashes three of those stages together so any changes currently require restarting from 0. Note that the underlying build process uses PYPY_USESSION_DIR, PYPY_USESSION_BASENAME, and a numbering system to ensure that each time the first stage (translation from RPython to C) puts the results in a new, clean directory. For this reason if you restart the process you will lose your previous work.
Python is both a binary interpreter and a stdlib of "battery included" modules. If you wish to use the binary interpreter, you need to install the binary and the stdlib support files together since they work as a unit. That is why we specify a fourth step in the build page, packaging. Please read that section carefully for methods of using the interpreter+stdlib
PyPy does not really support cross compiling, one method that used to work is described in the documentation of RPython. PyPy does support native gcc and/or clang. What compiler are you trying to use on what hardware?
Run the interpreter as you would any python interpreter; specify the path to the executable file, which (as stated above) needs to know how to find the support files such as the stdlib and the site-packages directory of third-party modules installed specifically for PyPy.
Using PyPy to build PyPy should be no different than using CPython to build PyPy, except it will be much faster. The differences you see must be an artifact of how you are building.
I would recommend you NOT use the unsupported Makefile until you understand the build, compile, package, install process, and then once you have a working installation help the PyPy project improve the process until it can be automated into a Makefile
If you are running OpenWRT on supported hardware and operating system, you would be much happier using a binary distribution and not compiling from source. In this case your Makefile should download a binary distribution and simply install it.
If you are using a different CPU, chances are PyPy will not work out-of-the-box on your hardware, you will have to run tests to make sure the JIT will actually make things faster.
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.
In Delphi 2009, how can I build a project using command line. I tried using the command line compiler and supplying -a -u -i -r in dcc32.cfg file. But compiler is not recognizing the paths and throwing the error required package xyzPack is not found.
-aWinTypes=Windows;WinProcs=Windows;DbiProcs=BDE;DbiTypes=BDE;DbiErrs=BDE
-u"C:\MyProj\Output\DCP"
-i"C:\MyProj\Output\DCP"
-r"C:\MyProj\Output\DCP"
and on command line i execute the command :
dcc32 "C:\MyProj\MyProject.dpr" -B -E"c:\MyProj\Output\EXE"
What am I doing wrong here?
Thanks & Regards,
Pavan.
Instead of invoking the compiler directly, consider using MSBuild on your .dproj, since that's what the IDE uses. Delphi MSBuild Build Configurations From Command Line might help you with that.
From the related answer (as shown below) ie:
Compiling with Delphi 2009 from a command line under Windows Vista 64-bit
I notice that you should be able to build a single package from the command line this way. I have used batch files (buildall.cmd) to launch dcc32, and have not yet used msbuild.
I have ultimately found both approaches frustrating, and have instead decided to opt for building a little GUI shell (a lite version of Final Builder, if you like) that basically works as a semi-graphical semi-command-line way of automating my builds and filtering the compiler output to produce results. I would be highly interested in anyone else's experiences with "tinder box" (daily or even continuous build) operations with Delphi.
You may end up where I'm heading... just buy Final Builder. :-)