Thanks. That's interesting. So below are the flags `configure --help` offers. I don't see anything specific to link racket statically. Any hint?
`configure' configures this package to adapt to many kinds of systems. Usage: ./configure [OPTION]... [VAR=VALUE]... To assign environment variables (e.g., CC, CFLAGS...), specify them as VAR=VALUE. See below for descriptions of some of the useful variables. Defaults for the options are specified in brackets. Configuration: -h, --help display this help and exit --help=short display options specific to this package --help=recursive display the short help of all the included packages -V, --version display version information and exit -q, --quiet, --silent do not print `checking ...' messages --cache-file=FILE cache test results in FILE [disabled] -C, --config-cache alias for `--cache-file=config.cache' -n, --no-create do not create output files --srcdir=DIR find the sources in DIR [configure dir or `..'] Installation directories: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] By default, `make install' will install all the files in `/usr/local/bin', `/usr/local/lib' etc. You can specify an installation prefix other than `/usr/local' using `--prefix', for instance `--prefix=$HOME'. For better control, use the options below. Fine tuning of the installation directories: --bindir=DIR user executables [EPREFIX/bin] --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --mandir=DIR man documentation [DATAROOTDIR/man] --docdir=DIR documentation root [DATAROOTDIR/doc/PACKAGE] --collectsdir=DIR collects documentation [DOCDIR] --appsdir=DIR apps documentation [DOCDIR] System types: --build=BUILD configure for building on BUILD [guessed] --host=HOST cross-compile to build programs to run on HOST [BUILD] --target=TARGET configure for building compilers for TARGET [HOST] Optional Features: --disable-option-checking ignore unrecognized --enable/--with options --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] --enable-gracket build GRacket as well as Racket (enabled by default) --enable-jit support JIT compiler (enabled by default) --enable-foreign support foreign calls (enabled by default) --enable-places support places (3m only; usually enabled by default) --enable-futures support futures (usually enabled by default) --enable-float support single-precision floats (enabled by default) --enable-floatinstead use single-precision by default (NOT RECOMMENDED) --enable-extflonum support extflonums (enabled by default, if available) --enable-racket=<path> use <path> as Racket to build; or "auto" to create --enable-origtree install with original directory structure --enable-pkgscope=<s> set `raco pkg' default: installation, user, or shared --enable-docs build docs on install (enabled by default) --enable-usersetup setup user-specific files on install --enable-natipkg add "-natipkg" to library subpath --enable-shared create shared libraries (ok, but not recommended) --enable-dynlib same as --enable-shared --enable-lt=<prog> use <prog> instead of libtool; disable to use bundled --enable-libs install static libraries (enabled by default for Unix) --enable-libffi use installed libffi (enabled by default for Unix) --enable-sdk=<path> use Mac OS 10.4 SDK directory --enable-sdk5=<path> use Mac OS 10.5 SDK directory --enable-sdk6=<path> use Mac OS 10.6 SDK directory --enable-ios=<path> use iOS SDK directory --enable-sysroot=<path> use sysroot directory (e.g., for Android) --enable-xonx use Unix style (e.g., use Gtk) for Mac OS --enable-libfw install Mac OS frameworks to /Library/Frameworks --enable-userfw install Mac OS frameworks to ~/Library/Frameworks --enable-macprefix allow --prefix with a Mac OS install --enable-mac64 allow 64-bit Mac OS build (enabled by default) --enable-cgcdefault use CGC as default build (NOT RECOMMENDED) --enable-sgc use Senora GC instead of Boehm GC (enabled by default) --enable-sgcdebug use Senora GC for debugging (expensive debug mode) --enable-backtrace 3m: support GC backtrace dumps (expensive debug mode) --enable-pthread link with pthreads (usually auto-enabled if needed) --enable-stackup assume "up" if stack direction cannot be determined --enable-bigendian assume "big" if endianness cannot be determined --enable-ffipoll only make FFI calls if embedding program explicitly polls --enable-gprof compile for profiling with gprof (gcc only) --enable-gcov compile to gather gcov statistics (gcc3 only) --enable-strip strip debug on install (usually enabled by default) --enable-noopt drop -O C flags (useful for low-level debugging) --enable-ubsan compile with -fsanitize=undefined) Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a nonstandard directory <lib dir> LIBS libraries to pass to the linker, e.g. -l<library> CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if you have headers in a nonstandard directory <include dir> CPP C preprocessor Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. Report bugs to the package provider. On Tuesday, February 21, 2017 at 11:15:46 AM UTC-8, Ethan Estrada wrote: > On Monday, February 20, 2017 at 12:33:46 PM UTC-7, lu wrote: > > In fact, I'm wondering if `raco distribute` or `raco exe` is flexible > > enough to produce a statically linked executable where all the necessary > > dlls are incorporated. > > I believe this is possible, but probably not worth the effort considering you > mentioned this as a toy project. To my understanding (and, please, someone > correct me if I am wrong about this), `raco exe` will just compile your file > to Racket bytecode, then intelligently mash it together with the racket > executable you have installed. If the racket executable you have installed > requires loading an external dll, then so will the executable created from > `raco exe`. If the racket executable you have installed does NOT require an > external dll, then neither will your executable generated from `raco exe`. > The default Windows installer distributed for racket has the core of the > language linked as a separate `libracket` dll, so `raco exe` follows suit. > Partially this is an issue at the OS and linker level; after compilation, > dynamically linked libraries can't easily be transformed to statically linked > libraries and vice-versa. It is almost universally a compile time choice. To > be clear, I am talking about code compiled to native machine bytecode > tailored to a particular operating system from a source language like C, not > compiled Racket bytecode. > > Which brings me to my next point. To make this work, you would pretty much > need to compile the Racket executable from source and use whatever compile > flags are required to build everything statically into the main executable. > Then `raco exe` should work as expected using your custom compiled version of > Racket. This is a huge amount of work for a toy project. So, like I said, it > probably isn't really worth it. It's ultimately simpler to just use `raco > distribute` and send the whole bundle to someone else. Yes, it is a bit > clumsy for something so small, but it should at least work. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.