Re: Build static binaries of chicken apps in a docker container
Hi Theo, Thanks for sharing that! I had I similar problem and wanted to share what I arrived at. If there is a C-compiler on the target, you could compile to .c or even .o and link on the target side. Unfortunately, that needs fiddling a bit around with compiler and linker flags. Another solution is to compile the static chicken as a static executable. -static to csc makes it compile the Chicken runtime (so no libchicken.so) and eggs in statically. But you can tell gcc to take it a step further and link statically as well (-L -static). This will grab libc and friends from your build machine. Sometimes that might work and requires very little fiddling around with compiler flags. csc -L -static -static mymod.scm K. On Sun, Jun 20, 2021, 17:53 Théo Cavignac wrote: > Hi, > > I wanted to write and compile Chicken apps on my linux laptop and use > them on some super computer I have access to. > > I naturally chose to compile static app with "csc -static main.scm -o > main" which would link my app against a shared glibc version. > > While that is what I wanted, I encountered the problem that my Arch > based distro has a very recent libc version, hence producing > incompatible binary with the CentOS 6 supercomputer (for stability sake > those are always running on super old OS). > > As a solutions I came up with a simple procedure that build my app > inside a Debian Stable based docker container and extract the file. > > I figured it may be interesting for other people here so I want to share > my script with you: https://github.com/Lattay/chicken-build-static. > > Currently is uses my own Chicken docker images (Images: > https://hub.docker.com/r/lattay/chicken , Dockerfile: > https://github.com/Lattay/chicken_docker ) so it can work on AMD64 or > ARMv7 (nice for RPi 2 and 3), but it is very simple and can easily be > used for other base images. > > If you are interested in this but the script does not does exactly do > what you want, feel free to submit an issue, a PR or to send me a mail. > > Cheers, > > Théo > > > >
Build static binaries of chicken apps in a docker container
Hi, I wanted to write and compile Chicken apps on my linux laptop and use them on some super computer I have access to. I naturally chose to compile static app with "csc -static main.scm -o main" which would link my app against a shared glibc version. While that is what I wanted, I encountered the problem that my Arch based distro has a very recent libc version, hence producing incompatible binary with the CentOS 6 supercomputer (for stability sake those are always running on super old OS). As a solutions I came up with a simple procedure that build my app inside a Debian Stable based docker container and extract the file. I figured it may be interesting for other people here so I want to share my script with you: https://github.com/Lattay/chicken-build-static. Currently is uses my own Chicken docker images (Images: https://hub.docker.com/r/lattay/chicken , Dockerfile: https://github.com/Lattay/chicken_docker ) so it can work on AMD64 or ARMv7 (nice for RPi 2 and 3), but it is very simple and can easily be used for other base images. If you are interested in this but the script does not does exactly do what you want, feel free to submit an issue, a PR or to send me a mail. Cheers, Théo
Re: Trying to link in modules
Thanks!
On Sun, Jun 20, 2021 at 6:42 AM wrote:
> > I've got a module mymod in mymod.scm:
> >
> >[...]
> >
> > However, I can't figure out how to do the same thing with mymod as
> > non-shared objects. I tried
> >
> > csc -c -J mymod.scm
> > csc -c mymod.import.scm
> > csc -static -o trymod.static mymod.o mymod.import.o trymod.scm
> >
> > but I got
> >
> > Undefined symbols for architecture x86_64:
> >
> > "_C_mymod_toplevel", referenced from:
> > _f_138 in trymod.o
> > ld: symbol(s) not found for architecture x86_64
> > clang: error: linker command failed with exit code 1 (use -v to see
> > invocation)
> > Error: shell command terminated with non-zero exit status 256: 'clang'
> > 'mymod.import.o' 'mymod.o' 'trymod.o' -o 'trymod.static' -m64
> > -L/usr/local/Cellar/chicken/5.2.0/lib
> > /usr/local/Cellar/chicken/5.2.0/lib/libchicken.a -lm
>
> When loading a shared object, the CHICKEN runtime uses the libld API
> to obtain the entry point ("C_toplevel") to invoke top-level
> initialization code
> of the module (which also sets up global bindings, etc.). But in a
> statically
> linked executable, all entry points of linked modules must be available
> under
> a separate name, so that they can be distinguished from each other.
>
> What we do is to give the module (the binary *.o module) a name, which is
> called "unit", so mymod would have, for example, the unit name "mymod",
> which produces the entry point "C_mymod_toplevel". So you can link any
> number of separately compiled binary objects (containing modules) and
> their names don't clash.
>
> So, to make it work:
>
> csc -c -J mymod.scm -unit mymod
> # compiling the import library is not needed
> csc -static -o trymod.static -uses mymod mymod.o trymod.scm
>
> The main file (trymod) doesn't need to resolve the imports, so you can omit
> linking the import library. "-unit" gives the module a unit name, "-uses"
> tells
> the main module to invoke the toplevel of the linked module.
>
> This mechanism is a source of great confusion, but this mainly comes from
> the fact that static linking uses a facility for resolving module toplevel
> and
> initialization code from the whole module and namespacing machinery.
>
> ---
> BTW, the "csm" utility, provided by the egg of the same name, figures this
> out
> automatically, just put trymod.scm and mymod.scm into an empty directory
> and enter
>
> csm -program trymod
>
> or
>
> csm -program trymod -static
>
> Add -d and -v to see what the program is doing and how things are compiled.
>
>
> felix
>
>
--
T. Kurt Bond, tkurtb...@gmail.com, https://tkurtbond.github.io
Re: Trying to link in modules
> I've got a module mymod in mymod.scm:
>
>[...]
>
> However, I can't figure out how to do the same thing with mymod as
> non-shared objects. I tried
>
> csc -c -J mymod.scm
> csc -c mymod.import.scm
> csc -static -o trymod.static mymod.o mymod.import.o trymod.scm
>
> but I got
>
> Undefined symbols for architecture x86_64:
>
> "_C_mymod_toplevel", referenced from:
> _f_138 in trymod.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> Error: shell command terminated with non-zero exit status 256: 'clang'
> 'mymod.import.o' 'mymod.o' 'trymod.o' -o 'trymod.static' -m64
> -L/usr/local/Cellar/chicken/5.2.0/lib
> /usr/local/Cellar/chicken/5.2.0/lib/libchicken.a -lm
When loading a shared object, the CHICKEN runtime uses the libld API
to obtain the entry point ("C_toplevel") to invoke top-level initialization code
of the module (which also sets up global bindings, etc.). But in a statically
linked executable, all entry points of linked modules must be available under
a separate name, so that they can be distinguished from each other.
What we do is to give the module (the binary *.o module) a name, which is
called "unit", so mymod would have, for example, the unit name "mymod",
which produces the entry point "C_mymod_toplevel". So you can link any
number of separately compiled binary objects (containing modules) and
their names don't clash.
So, to make it work:
csc -c -J mymod.scm -unit mymod
# compiling the import library is not needed
csc -static -o trymod.static -uses mymod mymod.o trymod.scm
The main file (trymod) doesn't need to resolve the imports, so you can omit
linking the import library. "-unit" gives the module a unit name, "-uses" tells
the main module to invoke the toplevel of the linked module.
This mechanism is a source of great confusion, but this mainly comes from
the fact that static linking uses a facility for resolving module toplevel and
initialization code from the whole module and namespacing machinery.
---
BTW, the "csm" utility, provided by the egg of the same name, figures this out
automatically, just put trymod.scm and mymod.scm into an empty directory
and enter
csm -program trymod
or
csm -program trymod -static
Add -d and -v to see what the program is doing and how things are compiled.
felix
Re: Trying to link in modules
Hi Kurt,
I think the problem is missing flags and parameters when fuilding a static
extension. I'm afraid I don't know exactly what they are, but hopefully I
can give some pointers to how you can find them.
chicken-install will extensions first as a shared object, and then as a
static one by default.
~/p/t/chicken-mtest > cat mymod.egg
((components
(extension mymod)))
~/p/t/chicken-mtest > chicken-install -v
/data/data/com.termux/files/home/prj/tmp/chicken-mtest/mymod.link -host -D
compiling-extension -c -unit mymod -D compiling-static-extension -C
-I/data/data/com.termux/files/home/prj/tmp/chicken-mtest -O2 -d1 mymod.scm
-o
/data/data/com.termux/files/home/prj/tmp/chicken-mtest/mymod.static.o
That gives a lot of output, but notice it installs a mymod.o file that
trymod can use when compiled statically. Let's see how trymod behaves as
normally:
~/p/t/chicken-mtest > csc trymod.scm
~/p/t/chicken-mtest > strace ./trymod ^&1 |grep mymod
newfstatat(AT_FDCWD,
"/data/data/com.termux/files/usr/lib/chicken/11/mymod.so",
{st_mode=S_IFREG|0755, st_size=13232, ...}, 0) = 0
newfstatat(AT_FDCWD,
"/data/data/com.termux/files/usr/lib/chicken/11/mymod.so",
{st_mode=S_IFREG|0755, st_size=13232, ...}, 0) = 0
openat(AT_FDCWD, "/data/data/com.termux/files/usr/lib/chicken/11/mymod.so",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/data/data/com.termux/files/usr/lib/chicken/11/mymod.so",
O_RDONLY|O_CLOEXEC) = 3
write(1, "Hello, World, I'm in mymod!\n", 28Hello, World, I'm in mymod!
And now with static compilation:
~/p/t/chicken-mtest > csc -static trymod.scm
~/p/t/chicken-mtest > strace ./trymod ^&1 |grep mymod
write(1, "Hello, World, I'm in mymod!\n", 28Hello, World, I'm in mymod!
I hope that is what you're after. Note this uses the installed version of
mymod (chicken-status), not the one in PWD. You can inspect the *.build.sh
files that chicken-install produces for inspiration, or tweak the .egg-file
to suit your needs.
Cheers,
Kris
On Sun, Jun 20, 2021, 09:57 T. Kurt Bond wrote:
> I've got a module mymod in mymod.scm:
>
> (module mymod (hello)
> (import scheme)
> (define (hello)
> (display "Hello, World, I'm in mymod!")
> (newline)))
>
> and I've got a module trymod in trymod.scm:
>
> (module trymod ()
> (import scheme)
> (import mymod)
> (hello)
> )
>
> and when I compile them like this:
>
> csc -s -J mymod.scm
> csc -s mymod.import.scm
> csc trymod.scm
>
> it produces an executable trymod that runs and dynamically loads mymod.so,
> unloads it, and loads it again, then produces the expected output, calling
> the function hello in mymod as running it on macOS with
> DYLD_PRINT_LIBRARIES=YES
> ./trymod shows.
>
> ...
> dyld: loaded: <59A8239F-C28A-3B59-B8FA-11340DC85EDC>
> /usr/lib/libc++.1.dylib
> dyld: loaded: ./mymod.so
> dyld: unloaded: ./mymod.so
> dyld: loaded: ./mymod.so
> Hello, World, I'm in mymod!
>
> However, I can't figure out how to do the same thing with mymod as
> non-shared objects. I tried
>
> csc -c -J mymod.scm
> csc -c mymod.import.scm
> csc -static -o trymod.static mymod.o mymod.import.o trymod.scm
>
> but I got
>
> Undefined symbols for architecture x86_64:
>
> "_C_mymod_toplevel", referenced from:
> _f_138 in trymod.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> Error: shell command terminated with non-zero exit status 256: 'clang'
> 'mymod.import.o' 'mymod.o' 'trymod.o' -o 'trymod.static' -m64
> -L/usr/local/Cellar/chicken/5.2.0/lib
> /usr/local/Cellar/chicken/5.2.0/lib/libchicken.a -lm
>
>
> What am I doing wrong?
> --
> T. Kurt Bond, tkurtb...@gmail.com, https://tkurtbond.github.io
>
Trying to link in modules
I've got a module mymod in mymod.scm: (module mymod (hello) (import scheme) (define (hello) (display "Hello, World, I'm in mymod!") (newline))) and I've got a module trymod in trymod.scm: (module trymod () (import scheme) (import mymod) (hello) ) and when I compile them like this: csc -s -J mymod.scm csc -s mymod.import.scm csc trymod.scm it produces an executable trymod that runs and dynamically loads mymod.so, unloads it, and loads it again, then produces the expected output, calling the function hello in mymod as running it on macOS with DYLD_PRINT_LIBRARIES=YES ./trymod shows. ... dyld: loaded: <59A8239F-C28A-3B59-B8FA-11340DC85EDC> /usr/lib/libc++.1.dylib dyld: loaded: ./mymod.so dyld: unloaded: ./mymod.so dyld: loaded: ./mymod.so Hello, World, I'm in mymod! However, I can't figure out how to do the same thing with mymod as non-shared objects. I tried csc -c -J mymod.scm csc -c mymod.import.scm csc -static -o trymod.static mymod.o mymod.import.o trymod.scm but I got Undefined symbols for architecture x86_64: "_C_mymod_toplevel", referenced from: _f_138 in trymod.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Error: shell command terminated with non-zero exit status 256: 'clang' 'mymod.import.o' 'mymod.o' 'trymod.o' -o 'trymod.static' -m64 -L/usr/local/Cellar/chicken/5.2.0/lib /usr/local/Cellar/chicken/5.2.0/lib/libchicken.a -lm What am I doing wrong? -- T. Kurt Bond, tkurtb...@gmail.com, https://tkurtbond.github.io
