Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 23:02
    feeley commented #785
  • 17:58
    gambiteer opened #787
  • 17:54
    gambiteer commented #785
  • 14:12
    CI run 3164641412 passed
  • 13:43
    feeley commented #783
  • 12:51

    feeley on master

    Fix stack overflow undo issue w… (compare)

  • 03:05
    feeley commented #785
  • 00:18
    gambiteer commented #785
  • Sep 30 23:13
    CI run 3161822485 passed
  • Sep 30 21:35

    gambiteer on master

    Add test file for SRFI 231. (compare)

  • Sep 30 21:34
    gambiteer commented #785
  • Sep 30 17:06
    gambiteer commented #785
  • Sep 30 11:19
    feeley commented #785
  • Sep 29 16:03
    CI run 3152254896 passed
  • Sep 29 15:26
    CI run 3152013654 passed
  • Sep 29 14:43

    feeley on master

    Perform all BBS purification at… (compare)

  • Sep 29 14:11

    feeley on master

    Add message when module test is… (compare)

  • Sep 29 12:48
    Negdayen commented #783
  • Sep 29 11:33
    feeley commented #783
  • Sep 28 20:50
    CI run 3146306823 passed
Mark Friedman
@mark-friedman

Another question about the web-based IDE in contrib/try: Do I really need to server all the files in the try\try\lib directory? I assume that some or all of it is to support a set of auto-loaded modules, some or all of which are needed by the demo code. Are any of them needed for core R7RS-small execution? Also, are all the various file types in a given subdirectory necessary? Typically I will see foo.scm, foo.js, foo#.scm, foo.o1, foo.o1.js, and foo.o1.js.gzfiles.

I'm fairly new to Gambit (though not to Scheme), so forgive my naiveté ;-)

Marc Feeley
@feeley
@mark-friedman Sorry but my CSS-fu is not that strong either. As I recall, CodeMirror causes a lot of headaches to do resizing correctly. I did notice however that the pane-splitter is actually dragable close to the top of the REPL and you can drag it down to reveal the console. I hope someone with a PhD in CSS can sort out this issue...
1 reply
tck42
@tck42
Is there any way to override the default CFLAGS etc that gsc issues at runtime during build without changing the flags that are used to compile? The bleeding edge Fedora build is using custom linker scripts that are fine for gambit itself but they reference a linker script that's only available on the build server. I'd like to open the bug with a suggested working build. I checked the build docs but it's not clear to me which options end up where.
Mark Friedman
@mark-friedman
Thanks, @feeley for your answer about the orientation of the console and editor panes in "try". Do you (or anybody else) have an answer for my subsequent "try"-related question relating to all the different files and files types?
Konstantin Astafurov
@konstantin-aa
Hello, I'm writing some scheme that involves parsing JSON, and am having a bit of trouble with using the json.scm from here
Marc Feeley
@feeley
@mark-friedman None of the try/lib files are essential… they are there for dynamic loading of various standard modules… if you use the R7RS define-library then you will need try/lib/_define-library
8 replies
@konstantin-aa What troubles are you having?
Konstantin Astafurov
@konstantin-aa
I keep getting seg faults, which files should I be compiling?
Marc Feeley
@feeley

@tck42 You can set GAMBUILD_VERBOSE=yes or use gsc -verbose … to get a trace of the C compiler invocations. For example:

$ GAMBUILD_VERBOSE=yes gsc foo.scm
gcc-9  -O1    -bundle  -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -foptimize-sibling-calls -fomit-frame-pointer -fPIC -fno-common -mpc64    -D___SINGLE_HOST -D___DYNAMIC -I"/usr/local/Gambit/include" -o 'foo.o1'   'foo.c'
$ GAMBUILD_VERBOSE=yes gsc -exe foo.scm
gcc-9  -O1    -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -foptimize-sibling-calls -fomit-frame-pointer -fPIC -fno-common -mpc64   -D___SINGLE_HOST  -I"/usr/local/Gambit/include" -c -o 'foo.o'  'foo.c'
gcc-9  -O1    -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -foptimize-sibling-calls -fomit-frame-pointer -fPIC -fno-common -mpc64   -D___SINGLE_HOST  -I"/usr/local/Gambit/include" -c -o 'foo_.o'  'foo_.c'
gcc-9     -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -foptimize-sibling-calls -fomit-frame-pointer -fPIC -fno-common -mpc64    -D___SINGLE_HOST  -I"/usr/local/Gambit/include"  -o 'foo'   'foo_.o' 'foo.o' "/usr/local/Gambit/lib/libgambit.a”

After gsc has generated the C file(s) it will call the ~~bin/gambuild-Cscript as the last step of the compilation to invoke the C compiler and linker. When that script is called with no command line arguments it will dump all of the environment variable bindings it uses:

$ `gsc -e '(display (path-expand "~~bin/gambuild-C"))'`
C_COMPILER="gcc-9"
C_PREPROC="gcc-9 -E"
PKG_CONFIG="pkg-config"
FLAGS_OBJ=" -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -foptimize-sibling-calls -fomit-frame-pointer -fPIC -fno-common -mpc64 "
FLAGS_DYN=" -bundle -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -foptimize-sibling-calls -fomit-frame-pointer -fPIC -fno-common -mpc64 "
FLAGS_LIB=" -dynamiclib -install_name \$(libdir)/\$(LIBRARY)\$(LIB_VERSION_SUFFIX) "
FLAGS_EXE=" -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -foptimize-sibling-calls -fomit-frame-pointer -fPIC -fno-common -mpc64 "
FLAGS_OPT=" -O1"
FLAGS_OPT_RTS=" -O3"
DEFS_OBJ=" -D___SINGLE_HOST "
DEFS_DYN=" -D___SINGLE_HOST -D___DYNAMIC"
DEFS_LIB=" -D___SINGLE_HOST "
DEFS_EXE=" -D___SINGLE_HOST “
…

You can see for example that FLAGS_DYN are the flags used for compiling a dynamically loadable object file.
If you need additional command line parameters to be passed to the C compiler you can do it manually with the -cc-options XXX argument to gsc, or set CFLAGS.

tck42
@tck42
@feeley Thanks very much for this info!
Bradley Lucier
@gambiteer

There's also:

    -ld-options 'option ...'    Extra command line options for C linker
    -ld-options-prelude 'option ...'

from gsc --help.

Marc Feeley
@feeley
@konstantin-aa Here’s how you can compile the module, import it and call it:
$ cp contrib/GambitREPL/json*.scm .
$ gsc . json
$ gsi .
Gambit v4.9.4-39-g9a887b80

> (import json)
> (define x (call-with-input-string "{\"name\":\"John\", \"age\":30, \"car\":null}" json-read))
> (table-ref x "age")
30
> (table->list x)
(("name" . "John") ("car") ("age" . 30))
tck42
@tck42
@gambiteer thanks as well! I think it'll come down to simply removing the problematic flags via sed on gambuild-C before the rpm gets created.
Marc Feeley
@feeley
@tck42 Let me know what flag is a problem and if it is a serious problem I can add an option to the configure script to disable that flag.
Konstantin Astafurov
@konstantin-aa
thank you!
tck42
@tck42
@feeley This isn't actually with gambit per se; when building gambit from source for fedora, the fedora build process is adding (among a large # of other flags) a CFLAG telling the linker to use a custom script that adds a so-called "package note" to the output binaries that can be used for bug reports. That linker script is available at time of building gambit (it's generated as part of the build process), but when using gambit on a system that it wasn't built on, that linker script doesn't exist. So it's more about how gambit is generating the contents of gambuild-C I think. It's easy enough to remove inappropriate flags directly from the file as part of the package spec. Though I may be misunderstanding; I was also going to try to rebuilt Gambit with FLAGS_* explicitly set to see if it would take those instead of taking the various flags that were used to compile gambit.
I see a bunch of .in files that appear to be the source to that file, was going to have a look there and see if there's any way I can change how the package is being built to get the flags out of gambuild-C without any changes to gambit
Marc Feeley
@feeley
@tck42 I don’t think the configure script copies the current setting of CFLAGS into the makefiles and the gambuild-C script. So when a Scheme file is compiled by gsc it should only be using (implicitly) the setting of CFLAGS at that moment, i.e. there is no relationship with the build environment.
tck42
@tck42
On the 4.9.3 system I first noticed this on, those flags are indeed hardcoded into gambcomp-C (these are the packages supplied by Fedora); overriding with for instance "CFLAGS= gsc test.scm" also had no effect, though if I remove the single flag directly from gambcomp-C it did fix the issue. I'm guessing I can also override via gsc switch, but my goal is to get the package creating a gsc and gambuild-C that uses the flags as close to the rpm build system's set of flags (some hardening flags) but also removing anything that won't properly work on the build system itself (ie this flag that is referencing a linker script that does not get packaged into the rpm).
Same for the 4.9.4 I built myself - it seems to be setting those in the file from some combination of the CFLAGS, LDFLAGS and CPPFLAGS that are around when configure gets run (I think).
Bradley Lucier
@gambiteer
@tck42 I'm curious, what flag is it?
tck42
@tck42
let me get to the system where I'm using the fedora package, give me 2 seconds
-Wl,-dT,/builddir/build/BUILD/.package_note-gambit-c-4.9.3-7.fc36.x86_64.ld
that file exists on the system that created the package, but does not (and I believe should not) get installed with the package on an end user fedora system
even if it was, it wouldn't be appropriate to use that linker file for binaries output by gsc - if gsc was used to generate another package, that file should be generated for that package, and the argument should be added to the flags in that package's spec (I think)
Marc Feeley
@feeley
can you confirm that the script bin/gambuild-C contains that flag? and where...
tck42
@tck42
yep - so on the fedora system (it's 4.9.3 at thsi time, when I file this bug to them I'll suggest they update to 4.9.4 as well) if I look at /usr/lib64/gambit-c/bin/gambcomp-C I see that FLAGS_DYN, _LIB, and _EXE all have that package_note argument.
Marc Feeley
@feeley
and did you try with v4.9.4?
tck42
@tck42
Yep - same exact behavior, though the file name has changed from gambcomp-C to gambuild-C
Marc Feeley
@feeley
can you show the lines here?
tck42
@tck42
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"
Marc Feeley
@feeley

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...

tck42
@tck42
Right - BUT - isn't that appropriate, at least for the gambuild-C file that's used for building gambit itself?
Marc Feeley
@feeley
however, I think this is probably the correct behavior because you want (in general) the same C compiler flags to be used to guarantee that the generated machine code is compatible
tck42
@tck42
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)
Marc Feeley
@feeley
I don’t think a solution that contains the word “patch” can ever be viewed as the correct solution...
tck42
@tck42
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
Marc Feeley
@feeley
probably the better option would be to add a configure flag to override CFLAGS… for example ./configure --enable-cflags=“…” that way in circumstances where the build CFLAGS contains some unwanted information then it can be removed
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
tck42
@tck42
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
tck42
@tck42
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
Marc Feeley
@feeley
@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.
tck42
@tck42
So during build gambuild-C is not actually used? Even for building the standard library?
tck42
@tck42
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.
Marc Feeley
@feeley
@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="".
Bradley Lucier
@gambiteer
Where will I find a description of how to define a type or a structure, etc., where I can declare whether there's a copier for the structure, whether fields are immutable, etc.