Dear Maintainer,

To embed racket/scheme in other applications it would be much easier, if
libracket was built as a shared library.

The fix is as simple as adding '--enable-shared' to the configure flags.

`configure --help` mentions that enable-shared is "ok, but not recommended",
however it fails to specify why this is so.
src/README says that enable-shared should not be used on W32 and OSX, but it
seems that there isn't a problem on other unices (like linux).
src/README even uses enable-shared in a number of build-examples and goes on to
say:

(which i understand to mean: "we ship it statically linked because it is easier
to use, but distributions will probably want to use enable-shared")

If there's a performance issue with the 'racket' binary, you might want to link
/usr/bin/racket statically, while still providing both libracket3m.so* and
libracket3m.a for the end-user.

While being there, it would be nice to have these shipped in "libracket-dev" and
"libracket" packages (with multiarch support)


this seems to also fix the problem that triggered #666201 (namely, to build
"fluxus"; i happen to know because that's what started all that)


fdmasr
IOhannes

IOhannes m zmoelnig <umlaeute@debian.org> writes:

I did a test build and it seems like it's not quite that simple. Since
the library is installed in /usr/lib, that basically means we need a new
libracket3m-6.11 package, and probably a -dev package as well. I'm not
sure yet how I feel about doing a library transition for every racket
upstream version. Presumably not many packages will depend on it, but
formally a transition will still be required (the problem being racket
is using the version as an SONAME).

d

IOhannes m zmoelnig <umlaeute@debian.org> writes:

I did a test build and it seems like it's not quite that simple. Since
the library is installed in /usr/lib, that basically means we need a new
libracket3m-6.11 package, and probably a -dev package as well. I'm not
sure yet how I feel about doing a library transition for every racket
upstream version. Presumably not many packages will depend on it, but
formally a transition will still be required (the problem being racket
is using the version as an SONAME).

d