I downloaded Rebol/View (vesion 2.7.8) Linux x86 libc6 2.3 version from http://www.rebol.com/downloads.html and it is working all right as an interpreter on Linux (Debian Stable 9). Is it possible to compile the code to executables? I tried checking the options, and compile to executable option does not seem to be there:
$ rebol -v --help
The command line usage is:
REBOL <options> <script> <arguments>
All fields are optional. Supported options are:
--cgi (-c) Check for CGI input
--do expr Evaluate expression
--link url Connect to Link
--help (-?) Display this usage information
--nowindow (-w) Do not open a window
--noinstall (-i) Do not install (Link, View)
--quiet (-q) Don't print banners
--reinstall (+i) Force an install (Link, View)
--script file Explicitly specify script
--secure level Set security: allow ask throw quit
--trace (-t) Enable trace mode
--uninstall (-u) Uninstall REBOL (Link, View)
--version tuple Minimum version of script, when URL (View)
--noviewtop (-v) Do not start viewtop (view desktop)
Special command line options:
+q Force not quiet (Link, View)
-s No security
+s Full security
-- args Provide args without a script
Examples:
REBOL script.r
REBOL -s script.r
REBOL script.r 10:30 test#domain.dom
REBOL --do "verbose: true" script.r
REBOL -cswq
REBOL --cgi --secure throw --script cgi.r "debug: true"
REBOL --version 1.2.3 http://www.rebol.net/test.r ; view only
Can I compile Rebol code to executable code on Linux/Windows? Thanks for your help.
In theory there should be a commercial SDK for Rebol available that bundles the interpreter with your script to one file, no native compiler.
Red uses Rebol to compile Red and Red/System for all supported platforms (Windows, Linux, Mac, Android etc), even crosscompiling. The compiler is included in the stable builds and automated builds. How to compile see the README and also RedEd
Rebol/View can be packed with the interpreter using a product called Encap which was available from Rebol Technologies. I don't know if they still sell this, or even if the company still exists.
Red, a Rebol 2 clone with an enhanced GUI, can compile to binary as far as I know.
Ren-c, a Rebol3 derivative, can be compiled from C source so you can compile in any code you want. However, there is no GUI support at present though one branch in planning to add this.
Related
I'm trying to use pp (the perl compiler) to create an application that can run independent of the perl installed library and interpreter.
It successfully creates a compiled executable although I had to use the -x -c options to get it to find dependencies successfully. It will run on my machine but when I try it on another machine I get this error so clearly there is still some dependency:
501 Protocol scheme 'https' is not supported (LWP::Protocol::https not installed)
I am running it on MacOS 10.14.1 if that makes any difference. Thanks!
LWP::Protocol::https is loaded dynamically when needed, so pp has no way of knowing it's needed by default.
Solution 1
Pass -x to pp, and make sure the module is actually loaded in the run pp uses to determine the modules to include. This would probably be achieved by using LWP to make an HTTPS request during that run. --xargs=... might come in useful for this.
Solution 2
Pass -M LWP::Protocol::https to pp. You could also pass -M 'LWP::Protocol::**' to get all protocols handlers you have installed.
Solution 3
Add use LWP::Protocol::https (); to your script or an included module. Including a comment indicating why you are doing this would be appropriate.
You were building Net::SSLeay on MacOS 10.14 linking it to libssl.44.dylib which is not present on MacOS 10.12 where you try to run it.
I've found it annoying having to switch between build and test systems to find out which of the libraries are missing or incompatible and need to be packed.
I am now using the following strategy:
I use perlbrew instead of system perl.
For alien dependencies I use homebrew instead of the system libraries.
I build the packed executable using pp and run the resulting program with export DYLD_PRINT_LIBRARIES=YES being set (on the development machine)
I examine the list of loaded libraries and add all those referenced in the homebrew directory tree (/usr/local/opt/ and /usr/local/cellar/in my case) using pp -l /full/path/name -l ...
I rebuild the executable.
I still check on a target machine before deploying, but chances are very high now that it just works.
I would like to use pigz to compress massive tar archives.
I am using cygwin. Unfortunately, pigz is not one of the standard cygwin packages.
Anyone know how to install pigz under cygwin?
Below are the 2 techniques I tried without success:
1) The README on this webpage (or in the README file, if you download the source from here) says that you should be able to build it from source merely by
Type "make" in this directory to build the "pigz" executable.
When I do that on my machine, I get a ton of warnings starting with
pigz.c:2950:20: warning: unknown conversion type character 'j' in format [-Wformat=]
(intmax_t)g.in_tot, (intmax_t)len, tag);
and then this final error:
gcc -o pigz pigz.o yarn.o try.o deflate.o blocksplitter.o tree.o lz77.o cache.o hash.o util.o squeeze.o katajainen.o -lm -lpthread -lz
pigz.o:pigz.c:(.text+0xd4f8): undefined reference to `fsync'
collect2.exe: error: ld returned 1 exit status
make: *** [pigz] Error 1
That about exhausts my ability to build programs from source...
2) It looks like there is an old 2015 port of pigz version 2.3.3 to Cygwin Ports, the expanded cygwin package repository.
But that version out of date (the latest pigz is 2.4). Indeed, it looks like Cygwin Ports has migrated to github and searching there for pigz there finds nothing.
I am not even sure how to use Cygwin Ports! The project's homepage merely says
Follow the normal Cygwin installation instructions in order to install
any of the packages currently maintained by this project.
I assume that that means to run cygwin's setup-x86.exe, but when it asks you to "Choose A Download Site" you will need to enter some URL for Cygwin Ports.
Web searching found little information. This link says to use http://sourceware.org/cygwinports/ but setup-x86.exe soon generated an error for that URL. The instructions in this link also did not work for me.
The C99 standard specifies the j specifier for printf(). (Note that the 99 refers to 1999. It is now 2018.) You can force the pigz compilation to not assume C99 by changing __STDC_VERSION__-0 >= 199901L || __GNUC__-0 >= 3 to 0. Then it won't try to use j.
Please let me know what the values of __STDC_VERSION__, __GNUC__, and __GNUC_MINOR__ are for your compiler.
Also pigz requires POSIX compliance, which would provide the fsync() call. You can just delete the reference to fsync(), which would just result in the --synchronous and -Y options having no effect.
To follow up on comments above that I had with #varro and matzeri, I can now answer my own question: my suspicion was correct: RTools was the culprit. I found that if I temporarily removed all RTools elements from my Windows Path env var (for me: c:\Rtools\bin and c:\Rtools\mingw_32\bin), then I was able to get pigz make to work.
After doing this Path edit, I uninstalled my existing cygwin, reinstalled cygwin, installed my usual extra packages (chere, openssh, subversion, zip, unzip) and all their dependencies, installed make and all its dependencies, installed gcc-core (is the C compiler) and all its dependencies. At that point, I was able to make pigz perfectly.
There is a much easier way than compiling yourself. I had the same problem, and with a little bit of research found multiple ready-made .exe files (pigz.exe) for direct usage in Windows. I am using this one:
https://sourceforge.net/projects/pigz-for-windows/files/
The OP's main concern was: "I would like to use pigz to compress massive tar archives.", and I hope that this is a useful answer to that concern, although it does not explain how to get around the compiling problems.
Some additional notes:
The interesting thing that some folks may not be aware of is that nothing keeps us from using normal Windows binaries from within Cygwin, and vice versa. That is, even if the OP had sophisticated Cygwin / bash (or whatever) scripts which drive pigz and the whole process of compressing, he could use the ready-made pigz native Windows version linked above.
With or without Cygwin, there is no need to compile pigz yourself, unless you want the latest features or bug fixes.
Personally, I am using the native Windows pigz version from within Cygwin since a while. AFAIK, pigz has no progress bar, which is somehow inconvenient for me (from time to time I have to compress a single huge file (around 60 GB)). A convenient way to get around this is the pv utility. Since I haven't found a native Windows version of it, and since I am too lazy to compile it for Windows myself, I am using Cygwin's pv to display the progress when I let the native Windows pigz compress those huge files.
GPUMlib comes with a filed called CMakeLists.txt instead of Makefiles or configure scripts. I do not see any build instructions and I do not see a list of packages that need to be installed in order to build GPUMlib even in the sources.
This answer assumes that cmake and gcc et al are already installed.
First install the CULA tools. Their documentation doesn't seem mention it, but their installer (which is barely mentioned in their FAQ) worked for me.
Once the installer finishes, it'll report some important shell variables, namely CULA_LIB_PATH_32, CULA_LIB_PATH_64, and CULA_INC_PATH. Take note of their values.
Invoke cmake with the shell variables reported by the CULA installer. Using me as an example, I installed my CULA tools at /home/john/projects/gpumlib/cula and cloned the gpumlib code into a directory called gpumlib-code so then my cmake command looked like this:
CULA_LIB_PATH_32=/home/john/projects/gpumlib/cula/lib CULA_LIB_PATH_64=/home/john/projects/gpumlib/cula/lib64 CULA_INC_PATH=/home/john/projects/gpumlib/cula/include cmake gpumlib-code
make -j 8
I wrote a bash script to do this for me which looks like this:
#!/bin/bash
export CULA_LIB_PATH_32=/home/john/projects/gpumlib/cula/lib
export CULA_LIB_PATH_64=/home/john/projects/gpumlib/cula/lib64
export CULA_INC_PATH=/home/john/projects/gpumlib/cula/include
cmake gpumlib-code
make -j 8
Thanks to Noel de Jesus Mendonça Lopes (the author of gpumlib) for helping me.
how to use and install SystemC in terminal mac OS X?
I tried the Logic poet application, But i use os x 10.10 so it doesn't work.
so i want to know how can i compile and execute SystemC in terminal.
I could't find the detail of SystemC in terminal.
Thank you
The other answer is correct and perfectly fine, however, I thought I'd also answer and provide a little more detail.
Install Apple's "Command Line Tools"
You have two options: install Xcode (a big download), or just the command line tools (a much smaller download). If your goal is simply building SystemC applications at the command line, then I recommend the latter.
Install Apple's "Command Line Tools" by launching Terminal, entering
$ xcode-select --install
then clicking Install. After that, you'll have make, clang and more available at the command line.
Build and install Accellera's SystemC implementation
Download the latest release from the Accellera Downloads page (annoyingly, you'll have to provide a few personal details) and extract the contents of the .zip file.
I like to keep a copy of the SystemC source code available, because it can be useful for debugging or understanding how something works. Therefore, I move the extracted folder (systemc-2.3.1) into ~/Work/Other. That's where I keep source code for third party libraries. However, you can put it wherever you like.
Open Terminal, change into the extracted folder (systemc-2.3.1), and execute:
$ mkdir build
$ cd build
$ export CXX=clang++
$ ../configure --with-arch-suffix=
$ make install
The --with-arch-suffix= option prevents a -macosx64 suffix being add to the lib folder name, allowing your build scripts to be simpler.
After that process, the salient include and lib folders should be available within the systemc-2.3.1 folder.
Configure your build environment
There are many ways you can do this; I have a simple approach that I believe is close to what the SystemC maintainers envisioned. I define two environment variables in my .bash_profile (which is executed for every new Terminal session on OS X):
export CXX="clang++ -fcolor-diagnostics"
export SYSTEMC_HOME=~/Work/Other/systemc-2.3.1
Build a SystemC application
You could use Make, the quintessential build tool, which you get with Apple's "Command Line Tools", or any one of the plethora of other options. I use SCons with SConstruct files that look something like this:
import os
env = Environment(CXX=os.environ["CXX"],
SYSTEMC_HOME=os.environ["SYSTEMC_HOME"],
CPPPATH="$SYSTEMC_HOME/include",
LIBPATH="$SYSTEMC_HOME/lib")
env.Program("main.cpp", LIBS="systemc")
View trace (VCD) files
Scansion is a nice tool for this. GTKWave is another option, but it's a bit clunky.
Ensure you have xcode command line tools installed.
Follow instructions provided in the official repository.
From personal experience.
Compiling SystemC library with clang results in segmentation fault: 11
error every time I include systemc library into my code. To avoid this use gcc instead.
Note that I use gcc-8, installed with homebrew.
$ cd path/to/systemc-2.3.3
$ mkdir objdir
$ cd objdir
$ export CXX=g++-8
$ ../configure
$ make
$ make install
Use $ make check to launch examples compilation and unit tests.
To compile and run hello world example:
$ export SYSTEMC_HOME=path/to/systemc-2.3.3
$ g++-8 hello.cpp -o hello.o -L $SYSTEMC_HOME/lib-macosx64 -I $SYSTEMC_HOME/include/ -l systemc
$ ./hello.o
Tested on macOS 10.13.6; gcc version 8.2.0; systemc-2.3.3
Install
Go here click the first link and fill in your information to get the source code
http://www.accellera.org/downloads/standards/systemc
Then cd to the folder
Then run the following commands
./configure --with-unix-layout
gmake
sudo gmake install
gmake clean
After you do that it should all be saved in your use/local/(lib&include) directories
To Use
In code do this
#include "systemc.h"
I use a single makefile normally. But you could write the following to link the library. Given your cpp file is called main.
g++ -o main main.cpp -I/usr/local/include -L/usr/local/lib -lsystemc
I am trying to update the glfw package to use glfw 2.7 on the mac. The problem becomes that there is a new cocoa port which introduces 'm' files.
So I wanted to use the -x c option on just those files, but I can't figure out how to get it to operate just on these 'm' files.
The relevant section of my cabal file:
if os(darwin)
include-dirs: glfw/lib/cocoa
frameworks: AGL Cocoa OpenGL
cc-options: -msse2
ghc-options: -x c -- **** global not just local.
c-sources:
glfw/lib/cocoa/cocoa_enable.m
glfw/lib/cocoa/cocoa_fullscreen.m
glfw/lib/cocoa/cocoa_glext.m
glfw/lib/cocoa/cocoa_init.m
glfw/lib/cocoa/cocoa_joystick.m
glfw/lib/cocoa/cocoa_thread.m
glfw/lib/cocoa/cocoa_time.m
glfw/lib/cocoa/cocoa_window.m
Any ideas how I can fix this cabal issue?
My source code resides at https://github.com/iaefai/glfw-haskell if you want to test it.
Try the GLFW-b bindings instead. I've worked with the author of GLFW-b to make all the necessary changes to get 2.7 working on OSX. It even works in GHCI.
You can cabal install nehe-tuts to see a demo of it working.
There's no way to do it via a .cabal flag. You may need to do a pre-processing stage manually (e.g. cabal makefile mode or configure mode).