Re: Removal of hppa support
On 2020-01-25 2:32 p.m., John Paul Adrian Glaubitz wrote: > I would like to protest this move as it was made without coordination > with the hppa porters in Debian. While Debian does not have hppa as a > release architecture, it's still a fully maintained port with multiple > developers working on it and also a userbase. I'll second that. As can be seen from Adrian's links, there are no major issues in building guile on hppa linux: I also build it from time to time on hpux11.11. Regards, Dave Anglin -- John David Anglin dave.ang...@bell.net
Re: Removal of hppa support
On 2020-01-26 8:34 a.m., John Paul Adrian Glaubitz wrote: > On 1/26/20 1:21 PM, William ML Leslie wrote: >> The only thing Wingo wrote publicly about this seems to be: >> >>> I ported some of the existing GNU Lightning backends over to Lightening... >>> I deleted the backends for Itanium, HPPA, Alpha, and SPARC; they have no >>> Debian ports and there is no situation in which I can afford to do QA on >>> them. [0] There is a porter box for hppa and it's free! I love this page: https://buildd.debian.org/status/architecture.php?a=hppa&suite=sid Dave -- John David Anglin dave.ang...@bell.net
Re: [PATCH, v2] Fix build on platforms where the stack grows upwards
Hi, On 2020-02-08 9:07 a.m., Ludovic Courtès wrote: > John Paul Adrian Glaubitz skribis: > >> * libguile/continuations.c (scm_dynthrow): Fix missing mra >>parameter to grow_stack for SCM_STACK_GROWS_UP. > Applied, thanks! I believe that this change was also applied to the 2.2 stable branch (v2.2.7). There is no mra parameter on 2.2. Dave -- John David Anglin dave.ang...@bell.net
Re: [PATCH, v2] Fix build on platforms where the stack grows upwards
On 2020-03-13 12:29 p.m., Andy Wingo wrote: > On Tue 10 Mar 2020 23:58, John David Anglin writes: > >> On 2020-02-08 9:07 a.m., Ludovic Courtès wrote: >>> John Paul Adrian Glaubitz skribis: >>> >>>> * libguile/continuations.c (scm_dynthrow): Fix missing mra >>>>parameter to grow_stack for SCM_STACK_GROWS_UP. >>> Applied, thanks! >> I believe that this change was also applied to the 2.2 stable branch >> (v2.2.7). There is no mra >> parameter on 2.2. > Indeed; fixed. Thanks for the fix and the note, and thanks Ludo for > getting the fix into 3.0.1 :) guile-3.0 3.0.0+1-2 built successfully on debian linux: https://buildd.debian.org/status/fetch.php?pkg=guile-3.0&arch=hppa&ver=3.0.0%2B1-2&stamp=1583969036&raw=0 On hpux, there are problems with the 2.2 and 3.0 branches. 2.0.14 builds okay on hppa2.0w-hp-hpux11.11 with gcc 8.4.1, but I had to upgrade intprops.h to a newer version. Version 2.2.6 segfaults in vm_regular_engine: 11378 Segmentation fault (core dumped) | GUILE_AUTO_COMPILE=0 ../meta/build-env guild snarf-check-and-output-texi > guile-procedures.texi make[3]: *** [Makefile:4281: guile-procedures.texi] Error 1 (gdb) bt #0 vm_regular_engine (thread=0x7ad69e60, vp=0x7ad28f78, registers=0x7eff22d0, resume=0) at ../../libguile/vm-engine.c:573 #1 0xc2b540fc in scm_call_n (proc=0x7ad4fbc0, argv=0x0, nargs=0) at ../../libguile/vm.c:1260 #2 0xc29e5710 in scm_call_0 (proc=0x7ad4fbc0) at ../../libguile/eval.c:479 #3 0xc2a44e58 in scm_primitive_load_path (args=0x7ad50ff0) at ../../libguile/load.c:1251 #4 0xc2a1f0a0 in scm_apply_subr (sp=0x7acd7f30, nslots=2) at ../../libguile/gsubr.c:305 #5 0xc2b2f22c in vm_regular_engine (thread=0x7ad69e60, vp=0x7ad28f78, registers=0x7eff11d0, resume=0) at ../../libguile/vm-engine.c:786 #6 0xc2b540fc in scm_call_n (proc=0x7ad375c8, argv=0x0, nargs=0) at ../../libguile/vm.c:1260 #7 0xc29e5710 in scm_call_0 (proc=0x7ad375c8) at ../../libguile/eval.c:479 #8 0xc2a44e58 in scm_primitive_load_path (args=0x7ad38b20) at ../../libguile/load.c:1251 #9 0xc2a44f7c in scm_c_primitive_load_path ( filename=0x7adce1ec "ice-9/boot-9") at ../../libguile/load.c:1267 #10 0xc2a31e8c in scm_load_startup_files () at ../../libguile/init.c:250 #11 0xc2a33864 in scm_i_init_guile (base=0x7eff0dd8) at ../../libguile/init.c:535 #12 0xc2b1ca80 in scm_i_init_thread_for_guile (base=0x7eff0dd8, ---Type to continue, or q to quit--- dynamic_state=0x0) at ../../libguile/threads.c:586 #13 0xc2b1cdc0 in with_guile (base=0x7eff0dd8, data=0x7eff0d58) at ../../libguile/threads.c:654 #14 0xc11fc530 in GC_call_with_stack_base (fn=0x4, arg=0x7ad4fd08) at ../src/extra/../misc.c:2130 #15 0xc2b1d01c in scm_i_with_guile ( func=@0x7adc477a: 0xc2a32000 , data=0x7eff0c9c, dynamic_state=0x0) at ../../libguile/threads.c:704 #16 0xc2b1d0ac in scm_with_guile ( func=@0x7adc477a: 0xc2a32000 , data=0x7eff0c9c) at ../../libguile/threads.c:710 #17 0xc2a31fcc in scm_boot_guile (argc=6, argv=0x7eff0a84, main_func=@0x40001a7a: 0x3838 , closure=0x0) at ../../libguile/init.c:324 #18 0x3b6c in main (argc=6, argv=0x7eff0a84) at ../../libguile/guile.c:101 (gdb) disass $pc-16,$pc+16 Dump of assembler code from 0xc2b2e99c to 0xc2b2e9bc: 0xc2b2e99c : addil L%-4800,r19,r1 0xc2b2e9a0 : copy r1,ret0 0xc2b2e9a4 : ldw e8(ret0),ret0 0xc2b2e9a8 : copy ret0,r6 => 0xc2b2e9ac : ldw 0(r6),r4 0xc2b2e9b0 : extrw,u r4,31,8,ret0 0xc2b2e9b4 : depw,z ret0,29,30,ret0 0xc2b2e9b8 : add,l r9,ret0,ret0 End of assembler dump. (gdb) p/x $r6 $1 = 0xf4f25378 (gdb) p/x ip $2 = 0xf4f25378 (gdb) x/x 0xf4f25378 0xf4f25378: Cannot access memory at address 0xf4f25378 The above fault doesn't depend on compiler optimization level. I've tried to find the change that introduced the above using git bisect but it isn't easy. There are multiple places on the trunk where the build breaks. In some places, stack overflows occur due to excessive iteration. Stack size is 16384 kbytes. If you have any thoughts on the above, let me know. Aside from the OS differences, the code generated should be quite similar for both hpux and linux. Dave -- John David Anglin dave.ang...@bell.net
[PATCH] Fix build of guile-3.0 trunk with gcc-8 on hpux11.11
The following change fixes the build of guile-3.0 using gcc-8 on hpux11.11.
There are three issues addressed:
1) The printf function does not support %zu. Since all the type sizes are
small,
we can use %u and cast the sizeof results to unsigned int.
2) HP-UX 11.11 does not have readdir64 or readdir64_r. The change adds back the
checks for readdir64 and readdir64_r. I added support for readdir64 similar to
that
for readdir64_r to gen-scmconfig.c and syscalls.h.
3) I needed to link libguile against gcc's libatomic. I don't have a configure
fix yet.
So, I export "LIBS=-latomic" in my guild to get gcc's atomic routines. This
fixed segmentation
fault building the texi documentation.
With these changes, all tests pass except the following:
wrote `/mnt/gnu/guile/objdir/cache/guile/ccache/3.0-BE-4-4.2/mnt/gnu/guile/guile
/test-suite/standalone/test-out-of-memory.go'
GC Warning: Failed to expand heap by 67239936 bytes
GC Warning: Failed to expand heap by 67108864 bytes
GC Warning: Out of Memory! Heap size: 1 MiB. Returning NULL!
GC Warning: Failed to expand heap by 1000132608 bytes
GC Warning: Failed to expand heap by 101536 bytes
GC Warning: Out of Memory! Heap size: 1 MiB. Returning NULL!
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 65536 bytes
GC Warning: Out of Memory! Heap size: 37 MiB. Returning NULL!
GC Warning: Failed to expand heap by 65536 bytes
GC Warning: Out of Memory! Heap size: 37 MiB. Returning NULL!
Warning: Unwind-only out of memory exception; skipping pre-unwind handler.
FAIL: test-out-of-memory
==
1 of 38 tests failed
(1 test was not run)
Please report to bug-gu...@gnu.org
==
Please install if okay.
Guile is part of the build and test environment that I use for gcc. HP-UX is
still the only
environment where we have a working 64-bit compiler. It is needed to build the
64-bit linux
kernel.
Regards,
Dave Anglin
diff --git a/configure.ac b/configure.ac
index 6198c7e6e..0edb31ba7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -483,7 +483,7 @@ AC_CHECK_HEADERS([assert.h crt_externs.h])
AC_CHECK_FUNCS([DINFINITY DQNAN cexp chsize clog clog10 ctermid
\
fesetround ftime ftruncate fchown fchmod getcwd geteuid getsid \
gettimeofday getuid getgid gmtime_r ioctl lstat mkdir mknod nice \
- readlink rename rmdir setegid seteuid
\
+ readdir64 readdir64_r readlink rename rmdir setegid seteuid \
setlocale setuid setgid setpgid setsid sigaction siginterrupt stat64 \
strptime symlink sync sysconf tcgetpgrp tcsetpgrp uname waitpid \
strdup system usleep atexit on_exit chown link fcntl ttyname getpwent
\
diff --git a/libguile/gen-scmconfig.c b/libguile/gen-scmconfig.c
index 8d77dfaf2..5ae831d53 100644
--- a/libguile/gen-scmconfig.c
+++ b/libguile/gen-scmconfig.c
@@ -239,21 +239,27 @@ main (int argc, char *argv[])
pf ("\n");
pf ("/* Standard types. */\n");
- pf ("#define SCM_SIZEOF_CHAR %zu\n", sizeof (char));
- pf ("#define SCM_SIZEOF_UNSIGNED_CHAR %zu\n", sizeof (unsigned char));
- pf ("#define SCM_SIZEOF_SHORT %zu\n", sizeof (short));
- pf ("#define SCM_SIZEOF_UNSIGNED_SHORT %zu\n", sizeof (unsigned short));
- pf ("#define SCM_SIZEOF_LONG %zu\n", sizeof (long));
- pf ("#define SCM_SIZEOF_UNSIGNED_LONG %zu\n", sizeof (unsigned long));
- pf ("#define SCM_SIZEOF_INT %zu\n", sizeof (int));
- pf ("#define SCM_SIZEOF_UNSI
Re: [PATCH] Fix build of guile-3.0 trunk with gcc-8 on hpux11.11
Hi Massimiliano, I don't think so. I have a recent build of bdwgc from github including this change: https://github.com/ivmai/bdwgc/issues/308 The bdwgc testsuite is clean. The patch that I submitted in issue 308 was to help in debugging issues with guile. HEURISTIC2 causes faults during startup that aren't easy to get by using gdb. I also submitted the previous change to use HEURISTIC2 as the other techniques to determine the stack bottom were problematic (e.g., with autogen). The %zu issue causes immediate problems in the build due to incorrect type sizes. The readdir issue fixes a testsuite issue. As things stand, readdir64 is used in libguile and it's not available. I think the issue with libatomic may also affect hppa-linux. Some atomic support depends on LWS system calls on hppa. These are in libatomic. On x86, it's only necessary to include libatomic.h and not link directly with libatomic. There's stuff in gcc testsuite to handle this. Dave On 2020-03-23 6:57 p.m., Massimiliano Gubinelli wrote: > Hi John, > could maybe be a bug with the Boehm-gc? I had some recent issues compiling > Guile 2.2.7 in Haiku and discovered that there is a new version > (8.1.0, next release development) of the GC here > > https://github.com/ivmai/bdwgc > > which has some changes, in particular certain conditional compilations > related to HP/UX, see e.g. lines 2708, 3093, ... here: > > https://github.com/ivmai/bdwgc/blob/master/os_dep.c > > Maybe you could try to link this new version and see if the problem with the > test persist. > > Best > Massimiliano > >> On 23. Mar 2020, at 18:17, guile-devel-requ...@gnu.org >> <mailto:guile-devel-requ...@gnu.org> wrote: >> >> >> Message: 1 >> Date: Mon, 23 Mar 2020 12:40:57 -0400 >> From: John David Anglin mailto:dave.ang...@bell.net>> >> To: guile-devel mailto:guile-devel@gnu.org>> >> Cc: Helge Deller mailto:del...@gmx.de>>, John Paul Adrian >> Glaubitz >> mailto:glaub...@physik.fu-berlin.de>> >> Subject: [PATCH] Fix build of guile-3.0 trunk with gcc-8 on hpux11.11 >> Message-ID: <1b543c79-7e66-9a93-8c57-91527519b...@bell.net >> <mailto:1b543c79-7e66-9a93-8c57-91527519b...@bell.net>> >> Content-Type: text/plain; charset=utf-8 >> >> The following change fixes the build of guile-3.0 using gcc-8 on hpux11.11. >> There are three issues addressed: >> >> 1) The printf function does not support %zu. Since all the type sizes are >> small, >> we can use %u and cast the sizeof results to unsigned int. >> >> 2) HP-UX 11.11 does not have readdir64 or readdir64_r. The change adds back >> the >> checks for readdir64 and readdir64_r. I added support for readdir64 similar >> to that >> for readdir64_r to gen-scmconfig.c and syscalls.h. >> >> 3) I needed to link libguile against gcc's libatomic. I don't have a >> configure fix yet. >> So, I export "LIBS=-latomic" in my guild to get gcc's atomic routines. This >> fixed segmentation >> fault building the texi documentation. >> >> With these changes, all tests pass except the following: >> >> wrote >> `/mnt/gnu/guile/objdir/cache/guile/ccache/3.0-BE-4-4.2/mnt/gnu/guile/guile >> /test-suite/standalone/test-out-of-memory.go' >> GC Warning: Failed to expand heap by 67239936 bytes >> GC Warning: Failed to expand heap by 67108864 bytes >> GC Warning: Out of Memory! Heap size: 1 MiB. Returning NULL! >> GC Warning: Failed to expand heap by 1000132608 bytes >> GC Warning: Failed to expand heap by 101536 bytes >> GC Warning: Out of Memory! Heap size: 1 MiB. Returning NULL! >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warning: Failed to expand heap by 8388608 bytes >> GC Warn
Building guile-1.8.2 on hpux
As it stands, guile-1.8.2 doesn't build on hpux because of a few minor configuration issues. I've attached a patch which addresses a couple of issues. The two remaining issues were addressed by hacking the generated config.h (i.e., I don't have a fix for them). I initially tried building guile-1.8.2 on hpux10.20 (needed an update from 1.6 for another package). hpux10.20 doesn't have posix complient versions of gmtime_r and readdir_r. I was able to work around the difference in declarations for gmtime_r, but I wasn't able to do this for readdir_r. Probably, the readdir_r configure check needs updating to check for a posix compliant version. In hpux10, _REENTRANT needs to be defined to get declarations for _r routines. There's small hacks in the change for this. The other issue is the check for socklen_t. HP-UX 10.20 doesn't define socklen_t. With gcc-4.2.0 (i.e., when _XOPEN_SOURCE_EXTENDED is defined), the socklen_t type needs to be size_t. HP-UX 11 typedefs socklen_t to size_t in . The comment in config.h says configure looks in . I haven't looked at the code but it's possible the check will fail and socklen_t will be set to int. Since the declaration for getsockopt and others assume size_t, the build fails. I edited config.h to work around this. HP-UX doesn't have 64-bit directory operations, so I hacked the header to always provide 32 bit versions. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) diff -u3pr guile-1.8.2~/libguile/_scm.h guile-1.8.2/libguile/_scm.h --- guile-1.8.2~/libguile/_scm.hWed May 9 16:22:03 2007 +++ guile-1.8.2/libguile/_scm.h Sun Oct 7 10:53:12 2007 @@ -145,15 +145,21 @@ #endif /* These names are a bit long, but they make it clear what they represent. */ -#define dirent_or_dirent64 CHOOSE_LARGEFILE(dirent,dirent64) #define fstat_or_fstat64CHOOSE_LARGEFILE(fstat,fstat64) #define ftruncate_or_ftruncate64CHOOSE_LARGEFILE(ftruncate,ftruncate64) #define lseek_or_lseek64CHOOSE_LARGEFILE(lseek,lseek64) #define lstat_or_lstat64CHOOSE_LARGEFILE(lstat,lstat64) #define off_t_or_off64_tCHOOSE_LARGEFILE(off_t,off64_t) #define open_or_open64 CHOOSE_LARGEFILE(open,open64) +#ifdef __hpux +#define dirent_or_dirent64 dirent +#define readdir_or_readdir64readdir +#define readdir_r_or_readdir64_rreaddir_r +#else +#define dirent_or_dirent64 CHOOSE_LARGEFILE(dirent,dirent64) #define readdir_or_readdir64CHOOSE_LARGEFILE(readdir,readdir64) #define readdir_r_or_readdir64_rCHOOSE_LARGEFILE(readdir_r,readdir64_r) +#endif #define stat_or_stat64 CHOOSE_LARGEFILE(stat,stat64) #define truncate_or_truncate64 CHOOSE_LARGEFILE(truncate,truncate64) #define scm_from_off_t_or_off64_t CHOOSE_LARGEFILE(scm_from_off_t,scm_from_int64) diff -u3pr guile-1.8.2~/libguile/filesys.c guile-1.8.2/libguile/filesys.c --- guile-1.8.2~/libguile/filesys.c Wed May 9 16:22:03 2007 +++ guile-1.8.2/libguile/filesys.c Sun Oct 7 09:23:15 2007 @@ -22,6 +22,7 @@ #define _GNU_SOURCE /* ask glibc for everything */ #define _LARGEFILE64_SOURCE /* ask for stat64 etc */ #ifdef __hpux +#define _REENTRANT #define _POSIX_C_SOURCE 199506L /* for readdir_r */ #endif diff -u3pr guile-1.8.2~/libguile/stime.c guile-1.8.2/libguile/stime.c --- guile-1.8.2~/libguile/stime.c Wed May 9 16:22:03 2007 +++ guile-1.8.2/libguile/stime.cSun Oct 7 09:25:07 2007 @@ -33,6 +33,7 @@ #define _GNU_SOURCE /* ask glibc for everything, in particular strptime */ #ifdef __hpux +#define _REENTRANT #define _POSIX_C_SOURCE 199506L /* for gmtime_r prototype */ #endif @@ -460,7 +461,7 @@ SCM_DEFINE (scm_gmtime, "gmtime", 1, 0, errno = EINVAL; #if HAVE_GMTIME_R - bd_time = gmtime_r (&itime, &bd_buf); + bd_time = (struct tm *) gmtime_r (&itime, &bd_buf); #else SCM_CRITICAL_SECTION_START; bd_time = gmtime (&itime); ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
