I have just got my pcduino. I want to write my programs using Erlang and want to use version R16B (so I can use web sockets). When I download and builds R16 the pcduino runs out of virtual memory so the make fails. Has anyone succeeded to install R16 or later versions on an Pcduino?
Erlang-Solutions has done some work on embedded Erlang. They don't mention the pcduino as one of the platforms they've successfully run on, but their general advice is to cross-compile, rather than build directly on the target. (Conquering Embedded Devices
with Erlang)
Here's an example of cross-compiling Erlang from that paper.
$ ./configure -host=arm-linux --with-ssl=/home/development/arm-lib/ --prefix=/opt/erlangR13B04 --without-termcap --disable-hipe --disable-smp-support --disable-megaco-flex-scanner --disable-megaco-reentrant-flex-scanner
make noboot
sudo make install
They also suggest removing the +debug_info flag from makefiles before building, running beam_lib:strip_release(code:root_dir())., and having the compiler optimize for space (-Os) to produce small binaries.
Related
I'm trying to compile the examples under cpp starting with minimal_build. I don't have much cmake experience. Must this be run under docker, or can it just be compiled in a Linux shell? I'm running Centos7 on a AWS EC2 instance, and I've installed cmake 3.20.2. Executing sudo ./run.sh, errors immediately with "cd: /io: No such file or directory". When I try and make what I think are the necessary changes to the scripts, I keep hitting errors. So I just want to see is this is even possible before proceeding further.
Thanks.
Yes, it is possible. I recently built Arrow on CentOS 7. With any C++ project there are going to be challenges switching amongst Linux distributions. The docker image is a way to provide a single example that the Arrow project can verify. You will need to adapt your Linux environment based on the issues you encounter. #Tsyvarev is also correct, you will want to use run_static.sh instead of run.sh. In order to do this you will need to dive a bit further into the details.
The build script has two steps. First, it will build the Arrow project itself. This is probably going to be the more challenging step. This guide is helpful for this step and provides a lot more detail into how Arrow builds and what options there are. The second step will be to compile and build the example.
Specifically for CentOS 7 one of the challenges you will face is that you will need a newer version of CMake. I ended up building CMake from source. If you go this route you also need to make sure that CMake is built with curl/https support. I used the --system-curl option for this.
That is all I remember having to do special for CentOS 7 at the moment. As you go about this task if you run into further, more specific, issues, feel free to ask them here or on the Arrow dev/user mailing list.
I'm new to Debian packaging and I believe this is a fairly basic question, but I am embarrassed to say I've struck out on Google.
I have a C++ project which builds with CMake and packages a debian with CPack. This project has a service component (systemd style). My goal is to have the service enabled & auto-started upon installation of the package.
My research has yielded two approaches:
1) Run various systemctl commands inside the {pre,post}{inst,rm} scripts in the Debian. Care is required to handle install, remove, and upgrade scenarios properly.
2) Simply put the project.service inside the debian directory and let debhelper (with dh_systemd_enable) handle service installation and start 'automagically'.
Option #2 is obviously preferred because the {pre,post}{inst,rm} is very manual and thus error-prone, but I cannot figure out whether there's a well supported way to leverage debhelper from within CPack.
The Question: I'd like to avoid rewriting the debian packaging stuff in my project's CMake as it's been around for some time and works well. The relationship (if any) between CPackDeb and debhelper is not clear to me -- can CPack take advantage of the dh_systemd_enable features or must I manage the service manually in {pre,post}{inst,rm} scripts?
I'm writing simple C++ code (one "cpp" file). Now I compile my program by manually running g++ from command line. But I was wondering if there is any way to do automatic g++ compilation after each save of file.
I'm using Ubuntu and Sublime Text 3.
There are also much fancier solutions available:
YouCompleteMe compiles and analyses the code in background while you type, for Vim
Emacs-ycmd is one of several ports to Emacs
RStudio IDE does the for C++ code (when though it is an R environment)
You can 'cook' similar things much simpler by using Linux kernel hooks in userspace to react whenever a file you watch is saved. Here you'd simply call g++, or as others already said, you probably want make.
One of the hooks is inotify; there are several Ubuntu packages accessing this (which I have yet to use). Here is one:
edd#max:~$ apt-cache show entr
Package: entr
Priority: optional
Section: universe/misc
Installed-Size: 61
Maintainer: Ubuntu Developers <ubuntu-devel-discuss#lists.ubuntu.com>
Original-Maintainer: Yuri D'Elia <wavexx#thregr.org>
Architecture: amd64
Version: 2.6-1
Depends: libbsd0 (>= 0.6.0), libc6 (>= 2.4)
Filename: pool/universe/e/entr/entr_2.6-1_amd64.deb
Size: 11310
MD5sum: 818b54114577b8d15d619577acf52c97
SHA1: b8422ee12546843f3357c1114bf1f5eeea8c863e
SHA256: ada9aa2ea218fc9f7a255b576d5069dda06da369ecc4000bb596e398b04eeafd
Description-en: Run arbitrary commands when files change
The Event Notify Test Runner (entr) runs arbitrary commands when
files change. Changes are detected through the kqueue/inotify
kernel interface.
Description-md5: 52fe22e37b3719b7c736bf46a6d8c9b7
Homepage: http://entrproject.org/
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
edd#max:~$
Create a makefile. Most editors have a shortcut keypress that executes make.
You can use make command.
Example: Imagine the file name is test.cpp then you can execute the following command:
make test
It will automatically compile using g++ as the extension is .cpp
If you are using VS Code, you can install the extension C/C++ Compile Run for the VS Code.
Once you change the code, just click F6 for executing it without passing any additional arguments, or F7 to type the passing arguments in the Command Palette, which will be passed to the code at the beginning of the execution.
C/C++ Compile Run
Use a proper build system that integrates with your IDE/editor.
There are many to choose from. My personal preference is SCons (http://scons.org/) but there are also options like CMake (https://cmake.org/) or autotools (https://en.m.wikipedia.org/wiki/GNU_Build_System) available or simply a plain Makefile.
And there are many more less known ones as well.
Check them out and pick what suits your needs best.
I'm working on a multi-platform project that is composed of a service/daemon which runs on Windows, Linux, and Mac OSX.
The code I have is portable, and the application runs fine (from the command line) on all the systems. As this application is designed to run in the background, I made it a Windows service on Windows and a Linux daemon (with the appropriate scripts in init.d) for Linux.
Now my problem is Mac OSX: I have little experience with this operating system, and I am having hard times figuring out the best practices for it regarding my situation:
I'd like to have an installer for my project (I believe a .dmg file, that would likely install an .app; please correct me if there is a better alternative).
Here some information about this project of mine:
It is build entirely in C++ (it uses boost, curl, iconv)
The current build system is not XCode (however If there is a way of keeping my current code layout while integrating and building everything into XCode, I don't mind. I've done something similar for Windows anyway).
There is no graphical user interface
The daemon should start on startup automatically (or even better: make that a user's choice).
The daemon requires root access during its execution.
That's probably a lot of context to consider for a single question, so I will try to make it easier to read:
How would you package/create an installer for a pure-C++ daemon on Mac OSX ?
Since this doesn't have a UI, I wouldn't package it as a .app -- that's the preferred format for double-clickable GUI apps, not for daemons. If it's just a single binary (no support files except maybe things like config files, etc), I'd follow unix conventions and put the binary someplace like /usr/local/libexec (or wherever you put it on Linux). Note that /usr/local doesn't exist by default on OS X, so your installer will need to create it if it doesn't exist.
For getting it to execute: I'll agree with James Bedford's suggestion of using launchd. The launchd .plist file should be installed in /Library/LaunchDaemons (LaunchDaemons run as root at startup, while LaunchAgents run as normal users when that user logs in). Make sure the daemon does not drop itself into the background -- launchd keeps watch over the programs it launches, and if they background themselves it thinks they've crashed, and generally tries to relaunch them, which doesn't work very well. You can adjust the settings to work with background programs, but it's best to have it run in the foreground.
For packaging: Here, I agree with mah -- use an installer package. I actually still like the old GUI PackageMaker tool (deprecated, but it still works), but the new CLI tools are probably better to learn at this point. If you follow my recommendation about /usr/local/libexec, your package should actually contain the "local" directory (with libexec subdir and your binary in that), and install that into /usr -- if /usr/local already exists, it'll just merge with what's already there, but if not it'll create the entire thing. On the other hand, /Library/LaunchDaemons is guaranteed to exist, so your package only needs to contain the actual .plist file to put in it.
Packaging as a .app makes some sense if what you're distributing is more than just a command line (for example, if it has resources such as static configuration data, images, frameworks/dylibs) that need to come along with it).
Regardless of what exactly is getting distributed, you can create an installer using tools that you already have -- pkgbuild and productbuild, both in /usr/bin. Making OS X Installer Packages like a Pro - Xcode Developer ID ready pkg can get you started using these tools.
Have you checked out the Daemons and Services Programming Guide provided by Apple? I think that would be very helpful as an introduction to the platform and should point you in the right direction (if not show you how to do exactly what you want).
You should also check out launchd (which is discussed in that programming guide). launchd is the official deamon launcher/manager for OSX, and is heavily integrated with the operating system. It should be easy enough to wrap your existing cross-platform deamon into a launched deamon, and you can integrate with OS X so that the deamon will start up automatically.
http://code.google.com/r/hectorchu-go-windows/source/list
If you could compile it successfully, I like to know the procedures of how to.
Assuming you are using Hector's source tree:
Install MinGW and MSYS, along with MSYS Bison and any other tools you think you'll find useful (vim, etc).
Install ed from the GNUWin32 project.
Install Python and Mercurial.
Clone the [hectorchu-go-windows mercurial repository](https://hectorchu-go-windows.googlecode.com/hg/ hectorchu-go-windows) to C:\Go.
Run an MSYS shell (or rxvt). The rest of these are bash commands...
mkdir $HOME/bin
export PATH=$HOME/bin:$PATH
export GOROOT=C:\\Go
export GOARCH=386
export GOOS=mingw
cd /c/Go/src
./all.bash
Correct errors as it spits them out at you, repeat step 10 until it starts building.
It's the same idea as on Linux or MacOS, basically.
However, I still stand by what I said in my comment above: this isn't necessarily going to generate anything that actually works yet. You'd be better served by waiting until this effort has merged into the main Go tree before tackling it, unless your interest is in assisting with the porting effort.
Update: there is now a mostly-functional pre-built windows port available, for those not interested in building the compiler themselves. However, given the rate of change of the project, the lack of formal releases (other than the hg "release" tag), and the possibility of Hector's changes being merged into the main branch soon, keeping up with development via source builds is likely to produce better results over time.
Just FYI, there is seems official one now.
http://code.google.com/p/go-windows/
Hector said he was only able to get as far as being able to compile and run an empty main. See issue 107:
http://code.google.com/p/go/issues/detail?id=107
There is still a lot of work to do in porting that, especially since the code has lots of dependencies on ptrace and syscall, not to mention the different threading models between Linux/BSD and Windows.
Update:
There's a new thread on golang-nuts (started 26.03.2010) with a link to a recent build and some current building instructions (using MinGW+MSYS).