FLAGS_DYN="-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/.package_note-gambit-c-4.9.3-7.fc36.x86_64.ld -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer -fPIC -fno-common -mpc64 -rdynamic -shared"
FLAGS_LIB="-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/.package_note-gambit-c-4.9.3-7.fc36.x86_64.ld -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -rdynamic -shared"
FLAGS_EXE="-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/.package_note-gambit-c-4.9.3-7.fc36.x86_64.ld -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer -fPIC -fno-common -mpc64 -rdynamic"
Sorry - the above was 4.93, below is 4.9.4 (I think they're identical
FLAGS_DYN="-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/home/tck42/rpmbuild/BUILD/gambit-4.9.4/.package_note-gambit-c-4.9.4-1.fc37.x86_64.ld -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -foptimize-sibling-calls -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer -fPIC -fno-common -mpc64 -rdynamic -shared"
FLAGS_LIB="-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/home/tck42/rpmbuild/BUILD/gambit-4.9.4/.package_note-gambit-c-4.9.4-1.fc37.x86_64.ld -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -rdynamic -shared"
FLAGS_EXE="-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/home/tck42/rpmbuild/BUILD/gambit-4.9.4/.package_note-gambit-c-4.9.4-1.fc37.x86_64.ld -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -foptimize-sibling-calls -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer -fPIC -fno-common -mpc64 -rdynamic"
I see the problem in configure.ac:
if test "$ENABLE_CPLUSPLUS" = yes; then
CORCXXFLAGS="$CXXFLAGS"
else
CORCXXFLAGS="$CFLAGS"
fi
FLAGS_OBJ="$CORCXXFLAGS $FLAGS_OBJ $FLAGS_OBJ_DYN $FLAGS_OBJ_DYN_LIB_EXE"
FLAGS_DYN="$LDFLAGS $CORCXXFLAGS $FLAGS_DYN $FLAGS_OBJ_DYN $FLAGS_OBJ_DYN_LIB_EXE $FLAGS_DYN_LIB"so I was wrong and CFLAGS from the build environment is being captured in the generated gambuild-C script...
right - it's just about removing that one flag, which is why I'm thinking the easiest and I guess most correct way is just to patch / sed it out of the gambuild-C that actually gets installed. That linker flag can be dropped I think, since it's just tagging the output binaries with metadata that aren't even appropriate for end user build binaries
(I'll just be proposing this in the bug, the actual packager may have other ideas on how to fix it in the spec file)
Hmm, that's true (I'm used to arch where those kinds of patches are common in their build scripts); though the existing fedora spec is alread patching configure presumably to work properly with buildroot or whatever they're using for the actual install. I don't know that a general solution is possible without somehow generating gambuild-C twice; once before building, and once just before packaging
another option would be to remove the reference to CFLAGS in the configure script, and cross our fingers that on all systems the build machine and target machines have compatible settings for CFLAGS
Hmm - I'm personally too ignorant on the topic but the second method sounds like it could cause problems (ie where we know we need a particular flag on a particular architecture). Splitting into "flags we use to build gsc" and "flags gsc will later use" and then defaulting the packaged gsc's flags to the build flags does sound like the way to go.
I'm happy to take a shot at a pull request, been meaning to learn and understand autoconf and friends
for what it's worth, fedora's build system is actually adding that flag to LDFLAGS, not CFLAGS or CXXFLAGS, though I think basically all three of those would be useful to have a configure flag for the same behavior and probably similar to implement. Will submit a pull request when I have it working
@tck42 So currently the value of
LDFLAGS at the time of the ./configure is captured and used by the Gambit makefiles (to build libgambit.a, gsi and gsc) and also by the gambuild-C script which is used to compile the standard modules (SRFIs, etc) and also user modules. I propose to add a new option to configure that allows capturing a different set of flags in the gambuild-C script. So ./configure --enable-gambuild-ldflags="-foo -bar" will only capture those flags in gambuild-C (but the LDFLAGS that exist when the gambuild-C script is called will still be used by the C compiler, as this is normal behavior). A ./configure --enable-gambuild-ldflags="" … will thus only use the late binding of LDFLAGS and a ./configure --enable-gambuild-ldflags="$LDFLAGS" … will cause the same behavior as now. The same can be done for CFLAGS and CXXFLAGS.
I'd been going a different route - I was creating a second set of gambuild files with the override variables if they're provided, and with the normal values if not, and then at install time I'm installing those instead; that was the only way I could think of that would still allow those files to be generated at configure time and have the original gambuild files used for the actual build process, but it requires duplicate gambuild files in a separate directory which I do not like. If it's not a requirement that the original gambuild files be around for build, your method is much much cleaner. I'll give that one a shot instead.
@tck42 Remember that
CFLAGS and LDFLAGS environment variables are always used implicitly by the C compiler, so putting them in the binding of FLAGS_ is redundant at build time (when doing ./configure …;make). It is only relevant when a programmer is using the gsc compiler after it is built and installed. Either to generate a .oN file with gsc foo.scm or an executable program with gsc -exe foo.scm (both cases invoke the gambuild-C script). I believe your problem will be solved if the gambuild-C script does not capture the setting that LDFLAGS had at build time by using ./configure --enable-gambuild-ldflags="".
gambiteer (Bradley Lucier): what about look up define-type in Gambit’s sourcew
s
@gambiteer I believe this is what you're after: https://github.com/gambit/gambit/blob/0f84372e879cb6979ccf30ee886ca3e19ad09936/lib/_nonstd.scm#L769
@gambiteer The define-type form is identical to define-structure. It is also easy to map define-record-type to define-type. It is done with:
(define-runtime-macro (##define-record-type name constructor predicate . fields)
`(##define-type ,name
constructor: ,constructor
copier: #f
predicate: ,predicate
no-functional-setter:
,@fields))Some documentation is here: https://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20090226/af2ee44c/attachment.txt
It would of course be good to define the form properly in the Gambit manual. I’ve added an issue for this on the github repo.
feeley (Marc Feeley): To recap the definition of a module: it is a directory and the directory contains, let’s see, a .sld or .scm or .six file with the body code of the module, and then also a #.scm with headers that are automatically ##include:d by (import)?
Apart from those two, the build output ends up in the module’s own directory and finally the module may ##include files in turn and those would be sought for (have as search path, relative current directory) in the module directory -
And then a module can contain setup.scm and module directories can have module subdirectories = recursive structure
Is this all the use the fact, that each module has its own directory, has or can a directory contain anything more of significance than what was said above here?
All, in Aug-Oct would you be up for a group zoom call with Marc where he explains compiler internals and more?
feeley (Marc Feeley): The time infos processed by Gambit eg in the floats slot in the thread struct, is it that any relative timeout eg (thread-sleep! 0.001) in Gambit gets translated to absolute time and then frequently ends up processed in C Gambit internals, and this is the reason the absolute time is always f64 or 64bit uint?
For fixes to bugs in the SMP support, 15x 100 EUR bounties are allocated. Feel tree to fix a bug and claim a bounty 👍
If one person intends to claim more than 2-3 bounties please discuss with donor in advance.
Bounty is due when validated that the bug was real and the solution is adopted by Gambit: ie an official Gambit function per the Gambit manual, that works in unicore Gambit and did not work in SMP Gambit, and with the claimant’s fix the bug is solved, and the particular PR offered is viewed as reference grade so much that it’s accepted for adoption to Gambit.
Method for transfer of the bounty eg paypal, bank, cash, crypto etc. discussed when bounty payment is due.
No particular expiry date on this offer eg 10 years (1 Jan 2032).
(Offer is nonbinding in the sense subject to current sanctions etc applicable regulations.)
Supposedly there are some easy to find and solve bounties in the SMP support now.
A bit down the line difficulty may go up and the bounty offer may be raised.
@cs7:matrix.org That’s a great initiative on your part to weed out the issues in the SMP support and make it reliable for everyday use. I have added a “donation” button to the Gambit github repo landing page (and will soon add it to the gambitscheme.org page) so that the Gambit project can have access to some funds for offering bug bounties on other types of bugs and rewards for other contributions (SRFIs, new modules, ports of modules of other Scheme systems, etc).
@ober To announce a bounty that you are willing to pay, just add an issue and indicate the details of the bounty. If you want to contribute funds so that we (the Gambit maintainers = me) can offer bounties then just click the button on the Gambit github repo README (in the “Contributing” section).
Question re: the FFI and C function pointers. If I have this in C,
int cfcn (int (*cb)()) {
cb();
}and this in scheme,
(define call-cfcn
(c-lambda ((function () int)) int "cfcn"))
(c-define (scmcallback) () int "cname" ""
(display " ** scheme callback\n"))
(call-cfcn scmcallback)I receive the message, 'ERROR (Argument 1) Can't convert to C function' upon executing instead of the ' ** scheme callback' message. What have I missed or mis-read?
@vesten I’m not sure which version of Gambit you are using, but this works fine:
$ gsc -v
v4.9.4-39-g9a887b80 20220503145411 x86_64-apple-darwin21.4.0 "./configure '--enable-single-host' 'CC=gcc-9'"
$ gsc cffi.scm
$ gsi cffi.o1
** scheme callback
42
$ cat cffi.scm
(c-declare "
int cfcn (int (*cb)()) {
return cb() * 7;
}
")
(define call-cfcn
(c-lambda ((function () int)) int "cfcn"))
(c-define (scmcallback) () int "cname" ""
(display " ** scheme callback\n")
6)
(pp (call-cfcn scmcallback))
@feeley Thanks for taking up something so trivial Marc. I'm using the Void Linux 4.9.4 Gambit package and can reproduce your results. Checking back with my original code, I had a typo - called scmcccallback <facepalm>. Ultimately I'm trying to interface to Lua and am having trouble with a function that pushes a function pointer to the Lua stack. I'll check for PEBKAC issues. Sorry for the stumble.
Just curious, is there a Rust language backend, would it have tail calls or other features that make it a suitable target. Not a suggestion, just curious.
@cs7:matrix.org There is no Rust backend currently or in the works. I don’t see immediate advantages to using Rust as a target language… it is hard to beat C for portability and execution speed. Last time I checked, Rust did not have TCO so a trampoline would be needed, like C/C++. A backend as complete as the C backend is a multi-year effort. An extension to the universal backend for Rust would be an easier task but with unclear optimizability to achieve max performance.
If I compile the following:
(let loop ((i 0))
(when (< i 100000000)
(display i)
(newline)
(loop (+ i 1))))and then pipe the output to head like this
./x | headthe pipeline appears to hang. I'm not sure what ./xis doing, since it has no place to write to, but it nevertheless consumes a lot of cpu time.
An equivalent Python program has a different behavior
➜ flub cat foo.py
i = 0
while i < 10000:
print(i)
i+=1
➜ flub python3.10 foo.py | head
0
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
File "/tmp/flub/foo.py", line 3, in <module>
print(i)
BrokenPipeError: [Errno 32] Broken pipe@cornett By default the interpreter uses stdin and stdout as the “REPL channel” to interact with the user. This can be changed with the -:dc runtime option so that the REPL channel is connected to the controlling terminal. This allows observing the error:
$ cat head.scm
(let loop ((i 0))
(when (< i 100000000)
(display i)
(newline)
(loop (+ i 1))))
$ gsi -:dc head.scm | head
0
1
2
3
4
5
6
7
8
9
*** ERROR IN ##wr-substr -- Broken pipe
(write-substring "923" 0 3 '#<output-port #2 (stdout)>)So when the -:dc option is not used the runtime system will attempt to output this error message on the REPL channel which is stdout, but this generates a similar error that the runtime system tries to output to stdout, and an infinite error loop results.
In the past Gambit used the controlling terminal for the REPL channel, but this was changed because users found this to give surprizing behavior, in particular they expect echo "(+ 1 2) (exit)" | gsi to feed the REPL with commands, which did not work when the controlling terminal is used as the REPL channel.
If you prefer the old behavior, you could set the GAMBOPT environment variable with export GAMBOPT=dc
Note also that you can get more context for the error by adding
2 or 3 to the -:d runtime option:$ gsi -:d2c head.scm | head
0
1
2
3
4
5
6
7
8
9
*** ERROR IN ##wr-substr -- Broken pipe
(write-substring "923" 0 3 '#<output-port #2 (stdout)>)
0 ##wr-substr
1 ##write-generic-to-character-port
2 ##display
3 loop "head.scm"@3:5 (display i)
4 (interaction) "head.scm"@1:1 ((letrec ((loop (lambda (...
5 ##load
6 ##load
7 ##main
$ gsi -:d3c head.scm | head
0
1
2
3
4
5
6
7
8
9
*** ERROR IN ##wr-substr -- Broken pipe
(write-substring "923" 0 3 '#<output-port #2 (stdout)>)
0 ##wr-substr
1 ##write-generic-to-character-port
2 ##display
3 loop "head.scm"@3:5 (display i)
i = 923
loop = (lambda (i) (if (< i 100000000) (begin (display i) (newlin... #3
4 (interaction) "head.scm"@1:1 ((letrec ((loop (lambda (...
5 ##load
6 ##load
7 ##main