l...@gnu.org (Ludovic Courtès) writes: > The good news is that `master' also builds and tests fine on this > platform with these two patches:
Indeed. Following the fixes that we did for MacOS earlier in the 1.8.x series, it's good to know that something else hasn't regressed. > > http://git.savannah.gnu.org/cgit/guile.git/commit/?id=6cc323e2ff4e555d58e115032016a50ef15a1948 > > > http://git.savannah.gnu.org/cgit/guile.git/commit/?id=7ca96180f00800414a9cf855e5ca4dceb9baca07 I'm not sure about moving stack-limit-calibration.scm from TESTS to BUILT_SOURCES. The point of putting it in TESTS was to help with cross-compiling. When cross-compiling, my understanding is that `make' should be run in a build host environment, and `make check' in a target host environment. stack-limit-calibration.scm should be calculated in the target host environment, so it makes better sense to do it as part of `make check' than as part of `make'. > (The calibrated stack limit on this machine is 45771, i.e., slightly > more than on GNU/Linux.) Isn't that 2.5 times more? (i.e. not "slightly" :-)) I believe the GNU/Linux limit is 20000. > However, this was with `--disable-error-on-warning' because of a problem > with GCC's visibility attribute: > > ../../libguile/async.c: In function 'scm_i_setup_sleep': > ../../libguile/async.c:277: warning: internal and protected visibility > attributes not supported in this configuration; ignored > > We can't use Gnulib's `visiblity' module to fix that because the > attribute appears in public headers, which are potentially processed by > compilers other than the one that built Guile. > > One possibility would be to move internal things in internal headers > that are not installed, but it's annoying. Some "#ifdef" magic would be > best, but I don't know of any such tricks. Ideas? Moving internal things into non-installed headers feels like the best thing to me. Regards, Neil
