[CM] S7 questions and libc issue

[Fernando Oleo Blanco]

Thank you for your thorough answer,

I will try to be as precise as possible.

Am Wed, 11 May 2022 13:29:23 -0700
schrieb <bil at ccrma.Stanford.EDU>:

> That's an interesting project!  To answer some of
> your questions:
>
> I think tcc can build s7 statically in linux.  Here's an example
> in Ubuntu:
>
> tcc -o s7 s7.c -I. -lm -DWITH_MAIN
> s7
> s7: 9-May-2022
>
> > (+ 1 2)
> 3
>

In order to build staticly one needs to add the "-static" flag. That is
when the build failure happens. Building dynamicly works perfectly
(tested on x86_64 OpenSUSE Tumbleweed). The error I added on the first
message happens when running:

`tcc s7.c -o s7-tcc -lm -I. -DWITH_MAIN -static`

I think I am using TCC v0.9.27. I say I think because I believe master
is still v0.9.27 even though it has received tons of improvements for
years and I had installed TCC.git in the past... Maybe TCC.git does not
have the issues.


> The -DWITH_MAIN switch includes a minimal repl, so you don't need
> repl.c or libc_s7.so.  The other choice is nrepl.scm but that
> requires the notcurses-core library.
>

I tried with the -DWITH_MAIN and it just works. Thank you. However,
when I use GCC it errores/warns with the following message (TCC
compilation on top for comparison and transparency):

```
fernando at linux:~/Builds/S7-scheme/s7-riscv-all-c> tcc s7.c -o s7-tcc
-lm -I. -DWITH_MAIN
fernando at linux:~/Builds/S7-scheme/s7-riscv-all-c> ./s7- s7-riscv
s7-tcc
fernando at linux:~/Builds/S7-scheme/s7-riscv-all-c> ./s7-tcc
s7: 2-May-2022

> (exit)
fernando at linux:~/Builds/S7-scheme/s7-riscv-all-c> gcc s7.c -o
s7-gcc-dynamic -lm -I. -DWITH_MAIN
fernando at linux:~/Builds/S7-scheme/s7-riscv-all-c> ./s7-gcc-dynamic
s7: 2-May-2022 load
/home/fernando/Builds/S7-scheme/s7-riscv-all-c/libc_s7.so failed:
/home/fernando/Builds/S7-scheme/s7-riscv-all-c/libc_s7.so: undefined
symbol: s7_f

;unbound variable (symbol "\x7f;ELF\x02;\x01;\x01;")
;    (symbol "\x7f;ELF\x02;\x01;\x01;")
;    libc_s7.so, line 1, position: 7

;unbound variable fileno in (fileno stdin)
;    (fileno stdin)
;    repl.scm, line 207, position: 6849
; (fileno stdin)
; ((terminal-fd (fileno stdin)) (tab-as-spa...
; ((lambda (hook lst) (when (or (not (proce...


;unbound variable *repl*
; (*repl* 'run)
; ((*repl* 'run))
; ((lambda (new-size) (unless (= new-size h... ; histsize: 100,
histpos: 0 ;                                              histbuf: #(""
"" "" "" ...)

fernando at linux:~/Builds/S7-scheme/s7-riscv-all-c> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit
--enable-offload-targets=nvptx-none,amdgcn-amdhsa,
--without-cuda-driver --enable-host-shared --enable-checking=release
--disable-werror --with-gxx-include-dir=/usr/include/c++/11
--enable-ssp --disable-libssp --disable-libvtv --enable-cet=auto
--disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-libphobos --enable-version-specific-runtime-libs
--with-gcc-major-version-only --enable-linker-build-id
--enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-11 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux Thread model: posix
Supported LTO compression algorithms: zlib zstd gcc version 11.2.1
20220420 [revision 691af15031e00227ba6d5935c1d737026cda4129] (SUSE
Linux)
```

When compiling with GCC it always seems to be trying to load
libc_s7.so. The load fails because libc_s7.so cannot find the function
"s7_f". That function is public and exists in s7.c... Maybe GCC is
optimising it out?? If I delete libc_s7.so from a previous test, then I
get the following warning:

```
fernando at linux:~/Builds/S7-scheme/s7-riscv-all-c> ./s7-gcc-dynamic
s7: 2-May-2022
load /home/fernando/Builds/S7-scheme/s7-riscv-all-c/libc_s7.so failed:
/home/fernando/Builds/S7-scheme/s7-riscv-all-c/libc_s7.so: cannot open
shared object file: No such file or directory

>
```

It tries to load it, warns about the library, and then just works.

These two cases is what I have also seen in RISC-V. Let me retell my
RISC-V adventures since there are some news.
I compiled s7.c staticly with the -DWITH_MAIN flag. I sent the binary
to my RISC-V installation and it gives the same libc_s7.so warning as
above... But it works!! :D For this I used GCC 11, as GCC 10 was giving
me errors during the compilation. However, when I cross-compile
libc_s7.so, it seems there is a memory issue or error... It loads for a
while and then it dies. Maybe there is some memory exhaustion problem.
There is also the (likely) issue that if it is trying to load
libc_s7.so, that it cannot do so. Glibc does not allow to dynamicly link
with other modules with another system Glibc version from a static
program. My system was compiled a long ago and it is using an older
Glibc, which is why I need to compile staticly. However, a couple of
times I got the error of the missing s7_f symbol...

> I notice you're using musl -- I think s7 works with it, but there was
> some header problem in libgsl -- I did not pursue it.  I haven't
> tried tcc with musl in linux.
>

This is going to be used for a compiler, so I do not care about "extra"
functionality. I only care about the Scheme, SRFIs and extra bits
related to programming in the Scheme implementation. The goal is to use
musl, but not for now. And I am surprised that you had issues with it,
it is a really good libc.

> On your chart, the s7 entries looks accurate to me.  s7 has the full
> numeric tower (including multiprecision support for all types via
> gmp, mpfr, and mpc).  s7 macros are "low-level" -- CL-style
> define-macro.  s7 has full tail recursion optimization, unless
> I inadvertently missed some case.  You can define arbitrary types
> via "setters", but the optimizer is not very smart about them
> yet.
>

Thank you for these comments, I will try to add them as soon as
possible :)

One last question/issue...
What is libc_s7.so supposed to do? I suppose it is an important part of
S7... And I will need to interface with some C subsystems...

Thank you very much for your time and care! Regards,
Fer