[CM] S7 questions and libc issue

[Fernando Oleo Blanco]

Am Sat, 14 May 2022 12:53:20 -0700
schrieb <bil at ccrma.Stanford.EDU>:

> > gcc -o s7 s7.c -I. -lm -DWITH_MAIN -ldl -pthread
>
> I sent this is a previous message:
>    gcc -o s7 s7.c -I. -lm -DWITH_MAIN -DWITH_C_LOADER=0 -pthread
> -static
>
>

Oh, sorry, I forgot to mention that I did try your suggestion but it
still did not work to due to .so problems. If I understood correctly,
the s7_f symbol not being generated is due to the WITH_C_LOADER value,
so that part is fine. Right now I am just trying to get r7rs.scm
loaded and tested on my computer (no cross-compilation involved in
the previous message nor in this one). Here is the output for full
transparency on a clean git clone:

```
fernando at linux:~/Builds/S7-scheme/s7> gcc -o s7 s7.c -I. -lm
-DWITH_MAIN -DWITH_C_LOADER=0 -pthread -static

fernando at linux:~/Builds/S7-scheme/s7> ./s7 r7rs.scm s7: 16-May-2022
load r7rs.scm
writing libc_s7.c
loading libc_s7.so

;unbound variable (symbol "\x7f;ELF\x02;\x01;\x01;")
;    (symbol "\x7f;ELF\x02;\x01;\x01;")
;    libc_s7.so, line 1, position: 7
; ((delete-file o-file-name))
; ((load so-file-name cur-env))
; ((curlet))

fernando at linux:~/Builds/S7-scheme/s7> gcc -o s7 s7.c -I. -lm
-DWITH_MAIN -DWITH_C_LOADER=1 -pthread -static
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld:
/tmp/cc6q8upX.o: en la función `load_shared_object':
s7.c:(.text+0x5b25a): aviso: Using 'dlopen' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking

fernando at linux:~/Builds/S7-scheme/s7> rm libc_s7.*

fernando at linux:~/Builds/S7-scheme/s7> ./s7 r7rs.scm
s7: 16-May-2022
load r7rs.scm
writing libc_s7.c
loading libc_s7.so
load /home/fernando/Builds/S7-scheme/s7/libc_s7.so failed:
/home/fernando/Builds/S7-scheme/s7/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
; ((delete-file o-file-name))
; ((load so-file-name cur-env))
; ((curlet))
```

Using the following compilation rule: `gcc s7.c -o repl -DWITH_MAIN -I.
-O2 -g -ldl -lm -Wl,-export-dynamic -Wno-stringop-overflow`  as
documented in the .html I get:

```
fernando at linux:~/Builds/S7-scheme/s7> gcc s7.c -o repl -DWITH_MAIN -I.
-O2 -g -ldl -lm -Wl,-export-dynamic -Wno-stringop-overflow

fernando at linux:~/Builds/S7-scheme/s7> ./s7 r7rs.scm
s7: 16-May-2022
load r7rs.scm
writing libc_s7.c
loading libc_s7.so
load /home/fernando/Builds/S7-scheme/s7/libc_s7.so failed:
/home/fernando/Builds/S7-scheme/s7/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
; ((delete-file o-file-name))
; ((load so-file-name cur-env))
; ((curlet))

```

Shouldn't this just have worked since it is a "normal" S7 compilation
case? It seems however I compile S7, it is always trying to interpret
the .so as a .scm. Maybe this is triggered by the s7_f symbol error,
but I do not understand how things work in S7.I may be missing something
trivial or I may just be very dense.

Thank you,
Fer