<rlb>daviid: yep, so this crashes 2.2.3 (wondering if it does for anyone else): <rlb> (CFLAGS='-fstack-protector-strong' ./configure) && make -j 3 && make check <rlb>crashes the out-of-memory test <daviid>rlb: great you find out. why did you have this flag in the first place? <rlb>Have to go see what that option does, i.e. I wonder if that's expected given whatever the test is trying to do, and if so, is it better to drop the option, or disable the test... <rlb>It's one of the default debian flags. <rlb>We can override, but if we do nothing, we get it. <daviid>rlb: hum, how is it that it did not crash earlier version of guile? just curious <rlb>Not sure - could be that it's new, though I don't think it is. More likely it's related to gcc-7 in sid (vs 6 before), and that flag or something. <daviid>i bet it's new, there is no way it would not crash 2.2.2 and all erlier version ... but anyway, really not my domain <rlb>well I don't know how many people are testing with whatever's in sid yet, but yeah, not sure either. <rlb>I know I haven't been building 2.2 with that flag much yet (for debian itself). <daviid>what is important, imo, is to have to proper optimization flag, or set of flags, whch I can't even tell you what is best <daviid>line 2 of your paste, you have ... -O2 and at the end -O0 that does not sounds good to me <rlb>That's just how the override works, i.e. in debian/rules we have: <rlb> export DEB_CFLAGS_MAINT_APPEND += -O0 <rlb>which is conditioned on amd64, and is how you tell dpkg-buildflags to make an adjustment. It chooses to do so with the append. <rlb>posted an update to the bug. <daviid>i was looking for some info about optimization gcc best flag setting, but I can't find anything (in the manual) <rlb>I see it in my info pages -- maybe the ones you're looking at are older? <daviid>in my (manually built from source) guile-2.2.pc: Cflags: -I${pkgincludedir}/2.2 -pthread <daviid>ok, i was thinking there made an entry in our manual... <daviid>1.6 Obtaining and Installing Guile but nothing there <daviid>I should recompile using -O2 maybe, what is the best setting? <daviid>that might influence how guile-cv performs here (by far the most 'expensive' s/w I ever used with guile) <wwoood>Hi there. I have what I hope is a simple guile question. I'm looking to run a subcommand (e.g. with system*), but want to pass a string as STDIN. Thanks in advance.. <daviid>how can I prevent, if possible, GC Warning messages like "GC Warning: Repeated allocation of very large block (appr. size 775237632): May lead to memory leak and poor performance."? guile-cv processing large images will print tens of these, which is annoying (and actually useless anyway, I need to allocate and either it works to the end, or it fails with an 'out of memory', so I'd rather suppress the warnings) <rlb>...and then you'll need to dump the string into the subproc's input pipe, and take the deadlock concerns seriously, i.e. if you're not certain you're not going to fall afoul of PIPE_BUF, you'll need to feed the data in (or get it out) via thread or something. Same thing comes up everywhere (perl, python, etc.). <wwoood>rlb: Sounds perfect, thanks. In my case the input string is quite small <(<255 chars) so the buffer shouldn't fill. Obviously I just wasn't using the right search terms, but would it make sense to add a cross-reference from system to open-pipe in the docs? <rlb>Might well - perhaps suggest it on guile-devel@gnu.org. I'm not actually involved in development at the moment. ***bairui_ is now known as bairui
<rlb>...debs built fine with -fno-stack-protector. I think I'll go with that for now, and we can revisit the question. <rlb>nb. guile 2.2.3+1-1 has been accepted into debian unstable (now to see how the buidds fare). <rlb>(I'm hoping to remove 2.0 from buster.) <rlb>Assuming that's reasonable. <rlb>No, I only do the debian work, though I think the author of that has been in contact (Dan?), and I'm planning to take a look at the differences later. <cmaloney>I sent Dan a note via Launchpad to see if they might be able to do an Ubuntu 14.04 build. <cmaloney>or send info on how to do it so I can contribute <rlb>While I haven't messed with ubuntu too much, I'd guess that the debs might work there too, assuming there's not too much skew (don't know how 14.04 matches up to debian releases offhand). <rlb>oh, wait, that's older? <rlb>Don't know that it would reach far enough back to help, but regardless, at the moment I don't have plans to make a 2.2 stretch backport. (Though it might not be too difficult.) <rlb>Do the people on guile-devel generally watch the bugtracker too? i.e. the bug that's been filed sufficient, or should I also post a summary/notice to the list? <ijp>tracker *should* be sufficient <rlb>ACTION notes that ppc64el seemed to build fairly "fast", though it was still an hour or so (takes *much* longer here). <rlb>(full bootstrap build) <daviid>rlb: don't know the details, but I know the compiler speed has been improved a lot in 2.2.3, it shows here too of course (amd64) <rlb>Heh, well the same bootstrap on my local machine takes ~377m. <rlb>But my local machine only has 2 real cores, and the porterbox I'm logged in to (may not be quite the same as that buildd) has 16... <rlb>(And I think it's really just a handful of bootstrap files that take forever.) <daviid>on a Intel Core i7-7700 @ 3.60GHz and 32GB of ram, it takes less then half an hour (rough evaluation, I did mot 'measure' seriously) <rlb>From a checkout of v2.2.3, or from the release archive? <daviid>this is not my personnal machine :), though I have no more contract at the moment, I stll have access to the lab I was working for ... and they use guile so I provide basic sysadmin and guile maintainance ... <rlb>Nice - and yeah, an upgrade of my main machine wouldn't be unreasonable -- might not be too far off. <daviid>by the way I tried -O3, but I don't think I did it the right way, didn't see any diff, which sounds suspicious: how do we pass this flag so gcc uses it, while running the configure make danse? and would that flag also be listed in the guile-2.2.pc? <rlb>Hmm, wouldn't be surprised if you didn't see much difference with -O3, but I believe to build with that you just need "CFLAGS=-O3 ./configure ..." and then build normally. <daviid>rlb: tx, I did export CFLAGS="-O3" ... i see CFLAGS_ENV in the config.log, so i guess gcc combines its own flags with 'mine' and it does not make almost any diff (visible anyway) <mwette>I did `CFLAGS=-O3 ./configure --prefix=/opt/local' and the Makefiles seem to indicate use of -O3 <rlb>Yeah, that's what I'd expect -- possibly little difference. <rlb>(And what's "better" isn't always clear (generally speaking), i.e. there are cases where optimizing for size (-Os) might produce greater improvements than say -O2, depending on the hardware, cache sizes, weather, etc.) <daviid>yes, and the age of the captain :) <daviid>yesterday I did ask if it was possible to suppress GC Warning, any one knows? <daviid>it scares the only guile-cv user I have :) <daviid>maybe a BDW_GC_* var or something <daviid>rlb: by the way, here, buster, amd64, I use gcc (Debian 7.2.0-16) 7.2.0, and the default gcc flags are: GCC_CFLAGS=' -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wpointer-arith -Wswitch-enum -f no-strict-aliasing -fwrapv' <rlb>I wonder if buster vs unstable matters... <rlb>Or the other dpkg-buildflags... <rlb>Here's how the build flags can be tested: <rlb> eval $(dpkg-buildflags --export=sh) <rlb>(if dpkg-dev is installed) <daviid>debian has other flags then the default gcc (that is what I ment to say earlier) <daviid>I'm a pathetic web user, but so far I can't find not even the (complete) list of BDW_GC variables, a few in their slides, none in the manual, none in the FAQ, any hint? <daviid>not that it matters much, but for info (maintainers) guile is not listed as a bdwgc user <rlb>no idea, but I'll also often just clone the git repo if there is one (or make my own), and start looking around via "git grep", etc. <daviid>rlb: haha, been there, I'll do that indeed <daviid>github, clicking 'dismiss' using tor, open the sign-up window, how is that? :) <daviid>GC_malloc_ignore_off_page if you get collector warnings from allocations of very large objects