[Gcl-devel] Patch: don't #include inside a function
I'm taking over maintainership of the Fedora GCL package, effective
today. I've grabbed the current Debian patch. Even with that patch,
I'm getting a build failure, due to h/unrandomize.h. Essentially, it
is not possible to #include unistd.h inside a function when
compiling with both optimization and -D_FORTIFY_SOURCE. When I
complained about this to the glibc maintainers, they replied:
Then GCL is buggy. Standard headers are never meant to be included
inside of a function. E.g. ISO C99 says in 7.1.2/4:
... If used, a header shall be included outside of any external
declaration or
definition, and it shall first be included before the first
reference to any of
the functions or objects it declares, or to any of the types or macros it
defines
So here is a patch to move the #include statements out of functions.
After applying this patch, configure will need to be regenerated.
diff -dur gcl-2.6.7.ORIG/configure.in gcl-2.6.7/configure.in
--- gcl-2.6.7.ORIG/configure.in 2008-11-03 16:58:14.0 -0700
+++ gcl-2.6.7/configure.in 2008-11-04 08:58:03.0 -0700
@@ -1032,7 +1032,11 @@
fi
AC_MSG_CHECKING([for personality(ADDR_NO_RANDOMIZE) support])
- AC_TRY_RUN([void gprof_cleanup() {};
+ AC_TRY_RUN([#include sys/personality.h
+ #include syscall.h
+ #include unistd.h
+ #include alloca.h
+ void gprof_cleanup() {};
int main(int argc,char *argv[],char *envp[]) {
#include h/unrandomize.h
return
0;}],CAN_UNRANDOMIZE_SBRK=1,CAN_UNRANDOMIZE_SBRK=0,CAN_UNRANDOMIZE_SBRK=0)
diff -dur gcl-2.6.7.ORIG/h/unrandomize.h gcl-2.6.7/h/unrandomize.h
--- gcl-2.6.7.ORIG/h/unrandomize.h 2008-11-03 16:58:16.0 -0700
+++ gcl-2.6.7/h/unrandomize.h 2008-11-04 08:58:24.0 -0700
@@ -1,8 +1,3 @@
-#include sys/personality.h
-#include syscall.h
-#include unistd.h
-#include alloca.h
-
{
long pers = personality(0xUL);
diff -dur gcl-2.6.7.ORIG/o/main.c gcl-2.6.7/o/main.c
--- gcl-2.6.7.ORIG/o/main.c 2008-11-03 16:58:56.0 -0700
+++ gcl-2.6.7/o/main.c 2008-11-04 09:00:38.0 -0700
@@ -27,6 +27,11 @@
#include stdlib.h
#include unistd.h
#include string.h
+#ifdef CAN_UNRANDOMIZE_SBRK
+#include sys/personality.h
+#include syscall.h
+#include alloca.h
+#endif
static void
init_main(void);
Regards,
--
Jerry James
http://loganjerry.googlepages.com/
___
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] Patch for ~username code
This is another patch against 2.6.7 + the current Debian patch. This
one does a couple of minor cleanups to the code that handles filenames
starting with ~username. First, such names may be greater than 20
characters long, so this code may overflow its buffer. On Fedora,
they can be 256 characters long. The patch uses LOGIN_NAME_MAX
instead. Second, the variable q is initialized twice with the same
value, so this patch removes the second initialization. Finally,
since we already know that q[0] == '~', there is no point in starting
the loop at index 0. Starting it at index 1 also gets gcc to stop
whining about a possibly negative array index when setting name[n - 1]
to zero.
Regards,
--
Jerry James
http://loganjerry.googlepages.com/
diff -dur gcl-2.6.7.ORIG/o/unixfsys.c gcl-2.6.7/o/unixfsys.c
--- gcl-2.6.7.ORIG/o/unixfsys.c 2008-11-04 16:36:47.0 -0700
+++ gcl-2.6.7/o/unixfsys.c 2008-11-04 16:46:37.0 -0700
@@ -215,7 +215,7 @@
#ifndef NO_PWD_H
if(namestring-st.st_self[0]=='~')
-{char name[20];
+{char name[LOGIN_NAME_MAX];
int n;
char *q = namestring-st.st_self;
#ifndef __STDC__
@@ -225,8 +225,7 @@
struct passwd *pwent;
int m=0;
- q=namestring-st.st_self;
- for (n=0; n namestring-st.st_fillp; n++)
+ for (n=1; n namestring-st.st_fillp; n++)
if (q[n]=='/') break;
bcopy(q+1,name,n-1);
name[n-1]= 0;
___
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Build trouble
On Sun, Nov 9, 2008 at 8:47 AM, Nicolas FRANCOIS [EMAIL PROTECTED]wrote: Hi. I've got a hard time compiling GCL-2.6.7 (Linux (Linux From Scratch), DualCore, Gcc 4.2.3, Glibc 2.7). The build is stuck on a segfault, caused by a buggy malloc, Gentoo bugtracking list dixit : Building symbol table for /sources/gcl-2.6.7/unixport/raw_pre_gcl .. Unrecoverable error: Segmentation violation.. /bin/sh: line 1: 13485 Abandon /sources/gcl-2.6.7/unixport/raw_pre_gcl /sources/gcl-2.6.7/unixport/ -libdir /sources/gcl-2.6.7/ foo make[1]: *** [saved_pre_gcl] Erreur 134 rm raw_pre_gcl make[1]: quittant le répertoire « /sources/gcl-2.6.7/unixport » make: *** [unixport/saved_pre_gcl] Erreur 2 I don't quite understand all the workarounds provided by the Gentoo list, as they are quite contradictory. Can someone help me compile this package ? I need it badly for Maxima. Hi Nicolas, I'm in the middle of reviving the Fedora build of GCL, and I had a problem with segfaults in raw_pre_gcl as well. They weren't caused by a buggy malloc, but rather by GCL's use of libbfd being behind the times. A temporary workaround that works for me is to configure GCL to use its built-in bfd library, rather than the system bfd library. I'm planning to look at the problem in more depth this week to see if GCL can be made to use a current libbfd. (If someone has already solved this problem, please let me know.) If configuring with GCL's bfd library doesn't fix your problem, can you provide a backtrace from the segfault? -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Build trouble
On Tue, Nov 11, 2008 at 10:57 AM, Nicolas FRANCOIS [EMAIL PROTECTED] wrote: If you mean compile Gcl (2.6.7) with this configure line : ./configure --prefix=/usr --enable-ansi --enable-locbfd \ --disable-dynsysbfd --disable-statsysbfd --disable-dlopen it works. Now I would have enjoyed having to pass only ./configure --prefix=/usr --enable-ansi --enable-locbfd but the (quite enigmatic) eror message was : Exactly one loader option must be chosen: dlopen=no statsysbfd=yes dynsysbfd=no locbfd=yes custreloc=no This could be modified, in my own humble opinion. I agree. Choosing a non-default option ought to switch off the default. Having to choose a non-default AND turn off the default seems wrong. I think you can get away with just this: ./configure --prefix=/usr --enable-ansi --enable-locbfd --disable-statsysbfd I don't remember Gcl being so hard to compile. But I think someone pointed something about it : Gdb modifies some installed libraries, so if you install Gdb BEFORE Gcl, you may encounter troubles. Can this be confirmed ? GDB comes with a libbfd and a libiberty, both of which are used by GCL. So, yes, if you install GDB then you'll get its versions of those libraries in /usr/lib or /usr/lib64. However, the --enable-locbfd option avoids that problem by building the libbfd and libiberty that ship with GCL. You won't use the system libraries in that case, so installation of GDB should not matter. If configuring with GCL's bfd library doesn't fix your problem, can you provide a backtrace from the segfault? Djezus man, speak good english to me ! :-) What the hell is backtrace from the segfault ??? A new hard rock tube ? ;-) To be more serious, I don't know what to backtrace : do I need to run make through Gdb ? Sorry, I'll try to avoid speaking Swahili. :-) It sounds like you solved your problem already, so no backtrace (or stack trace) is needed. This section in the GDB manual explains what they are: http://sourceware.org/gdb/current/onlinedocs/gdb_8.html Regards, -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] LD_COMMAND for Linux
I'm struggling to understand the definition of LD_COMMAND in h/linux.h. Currently, it generates a string as follows: ld -d -S -N -x -A %s -T %x %s %s -o %s but Linux uses GNU ld, where: -A sets the architecture -T sets the linker script file Neither of those make any sense in this definition. I suspect these are the BSD linker options, where: -A identifies a symbol file -T specifies the start of the text segment The equivalents in GNU ld are -R and -e, respectively. Also, GNU ld expects a base 10 number as the argument to -e, but BSD's -T expects a hex number; note the %x in the LD_COMMAND definition. So I don't see how this works at all on a Linux system. Shouldn't the definition be: ld -d -S -N -x -R %s -e %d %s %s -o %s ? Is the code that invokes LD_COMMAND never executed on a Linux box? -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] Patch: compile with newer system BFD libraries
This patch detects whether a newer system BFD library is being used, specifically one that requires an output BFD. If so, it adds code to set up a dummy output BFD. This lets me compile successfully with the Fedora 9 BFD library. This patch requires regenerating the configure script with autoconf, and also using autoheader to regenerate h/gclincl.h.in. Unfortunately, autoconf 2.61 generates a configure script that will not run successfully, due to some obsolete autoconf usages in the current configure.in. I'll send a patch to fix that in a moment. -- Jerry James http://loganjerry.googlepages.com/ diff -dur gcl-2.6.7.ORIG/acconfig.h gcl-2.6.7/acconfig.h --- gcl-2.6.7.ORIG/acconfig.h 2008-11-13 10:01:08.0 -0700 +++ gcl-2.6.7/acconfig.h 2008-11-13 10:06:09.0 -0700 @@ -140,6 +140,7 @@ /* bfd support */ #undef HAVE_LIBBFD #undef NEED_CONST +#undef HAVE_OUTPUT_BFD #define HAVE_BFD_BOOLEAN #ifdef HAVE_BFD_BOOLEAN diff -dur gcl-2.6.7.ORIG/configure.in gcl-2.6.7/configure.in --- gcl-2.6.7.ORIG/configure.in 2008-11-13 10:01:57.0 -0700 +++ gcl-2.6.7/configure.in 2008-11-13 10:09:06.0 -0700 @@ -843,6 +843,15 @@ AC_MSG_RESULT(no), AC_MSG_RESULT(no)) +# +# Newer BFD libraries need a dummy output bfd +# + AC_CHECK_MEMBER([struct bfd_link_info.output_bfd], + [AC_DEFINE(HAVE_OUTPUT_BFD)], [], [ +#include bfd.h +#include bfdlink.h + ]) + AC_SUBST(HAVE_OUTPUT_BFD) # # FIXME: Need to workaround mingw before this point -- CM diff -dur gcl-2.6.7.ORIG/o/sfasli.c gcl-2.6.7/o/sfasli.c --- gcl-2.6.7.ORIG/o/sfasli.c 2005-01-15 09:26:43.0 -0700 +++ gcl-2.6.7/o/sfasli.c 2008-11-13 10:06:09.0 -0700 @@ -32,6 +32,9 @@ int u,v; unsigned long pa; asymbol **q; +#ifdef HAVE_OUTPUT_BFD + const char **bfd_targets; +#endif bfd_init(); if (!(bself=bfd_openr(kcl_self,0))) @@ -40,6 +43,11 @@ FEerror(I'm not an object,0); /*if (link_info.hash) */ /* bfd_link_hash_table_free(bself,link_info.hash); */ +#ifdef HAVE_OUTPUT_BFD + bfd_targets = bfd_target_list(); + link_info.output_bfd = bfd_openw(/dev/null, bfd_targets[0]); + free(bfd_targets); +#endif if (!(link_info.hash = bfd_link_hash_table_create (bself))) FEerror(Cannot make hash table,0); if (!bfd_link_add_symbols(bself,link_info)) diff -dur gcl-2.6.7.ORIG/o/unexelf.c gcl-2.6.7/o/unexelf.c --- gcl-2.6.7.ORIG/o/unexelf.c 2004-05-03 15:35:58.0 -0600 +++ gcl-2.6.7/o/unexelf.c 2008-11-13 10:06:09.0 -0700 @@ -1,5 +1,13 @@ -/* Foundation; either version 2, or (at your option) -any later version. +/* Copyright (C) 1985, 1986, 1987, 1988, 1990, 1992, 1999, 2000, 2001, + 2002, 2003, 2004, 2005, 2006, 2007, 2008 + Free Software Foundation, Inc. + +This file is part of GNU Emacs. + +GNU Emacs is free software: you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation, either version 3 of the License, or +(at your option) any later version. GNU Emacs is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -7,10 +15,9 @@ GNU General Public License for more details. You should have received a copy of the GNU General Public License -along with GNU Emacs; see the file COPYING. If not, write to -the Free Software Foundation, Inc., 59 Temple Place - Suite 330, -Boston, MA 02111-1307, USA. +along with GNU Emacs. If not, see http://www.gnu.org/licenses/. */ +/* In other words, you are welcome to use, share and improve this program. You are forbidden to forbid anyone else to use, share and improve what you give them. Help stamp out software-hoarding! */ @@ -82,224 +89,224 @@ temacs: SECTION HEADER TABLE -[No]TypeFlags Addr Offset Size Name -LinkInfoAdralgn Entsize + [No]TypeFlags Addr Offset Size Name + LinkInfoAdralgn Entsize -[1] 1 2 0x80480d40xd4 0x13 .interp -0 0 0x1 0 + [1] 1 2 0x80480d40xd4 0x13 .interp + 0 0 0x1 0 -[2] 5 2 0x80480e80xe8 0x388 .hash -3 0 0x4 0x4 + [2] 5 2 0x80480e80xe8 0x388 .hash + 3 0 0x4 0x4 -[3] 11 2 0x80484700x4700x7f0 .dynsym -4 1 0x4 0x10 + [3] 11 2 0x80484700x4700x7f0 .dynsym + 4 1 0x4 0x10 -[4] 3 2 0x8048c600xc600x3ad .dynstr -0 0 0x1 0 + [4] 3 2 0x8048c600xc600x3ad .dynstr + 0 0 0x1 0 -[5] 9 2
Re: [Gcl-devel] Patch: adapt to newer autoconf versions
On Thu, Nov 20, 2008 at 11:49 AM, Gabriel Dos Reis [EMAIL PROTECTED] wrote: Hi Jerry, Isn't _GNU_SOURCE GNU/Linux or glibc specific? -- Gaby Yes, that's right. The AC_GNU_SOURCE macro will determine if you are on a system that requires _GNU_SOURCE to be defined to get access to all prototypes and macros. -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Patch: adapt to newer autoconf versions
On Thu, Nov 20, 2008 at 5:13 PM, Gabriel Dos Reis [EMAIL PROTECTED] wrote: So, in fact, we want to check for C99 features, not GNU sources; right? -- Gaby RIght. On glibc-based systems, defining _GNU_SOURCE causes _ISOC99_SOURCE to also be defined (see /usr/include/features.h), as well as _POSIX_C_SOURCE, _XOPEN_SOURCE, and several others. In short, defining _GNU_SOURCE says to activate all features. -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] How to submit GCL patches
On Tue, Dec 23, 2008 at 12:44 AM, Andrey G. Grozin a.g.gro...@inp.nsk.su wrote: Jerry, Where can I get the full set of your patches? I want to make a better gcl-2.6.8-pre package for Gentoo. Andrey Sorry, I've been avoiding email during my Christmas break. I refactored the patches in the hope of making them more palatable to the GCL maintainers and threw them all onto a web page where they can be browsed more easily: http://jjames.fedorapeople.org/gcl/ You'll notice that I've wasted none of my precious storage space on little frills like CSS. :-) So can we start with some of the easy patches and start moving them into CVS? How about the fd-leak patch? That one seems pretty obvious to me. As anybody looks at these patches, if you find yourself wondering why I did something, please drop me a line. I'll expand the explanations on those web pages as necessary. If it looks like a patch needs a little more work, tell me that, too. (I've already noted that the SELinux patch is not quite fully baked.) Regards, -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] How to submit GCL patches
On Sun, Jan 11, 2009 at 9:41 PM, Andrey G. Grozin a.g.gro...@inp.nsk.su wrote: ping anybody here? And more to the point, why is Camm not responding to list email, not responding to list email CCed to him, and not responding to private email when he is clearly still around and paying at least some attention to GCL? http://osdir.com/ml/lisp.cl-debian/2008-01/msg3.html I'm getting really frustrated with this project. I can see how to fix a couple of the bugs listed in BUGS, but it appears that doing so is a waste of time. Am I wrong? I don't have any history with this project, so let's start with the fundamentals. 1. Who are the current developers? There's a list on the project web page, but since I can't even get anybody to fix a broken link there (see the first message in this thread), I have no confidence that those pages aren't years out of date. 2. Who has editing rights on the project web pages? 3. Who has commit rights to the code repository? 4. Who is in charge of release management? 5. What are the release criteria for 2.6.8 and 2.7.0, respectively? 6. What processes are used to manage incoming patches? 7. What are the policies and procedures around recruiting new developers? If any of this is already documented somewhere, please just provide a pointer. Thanks, -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] How to submit GCL patches
On Tue, Jan 13, 2009 at 5:27 AM, Marijn Schouten (hkBst) hk...@gentoo.org wrote: Isn't that almost a year old? Well, I figured I was still writing 2008 on all my checks, so it must be 2008. -- Jerry *blush* James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] How to submit GCL patches
Okay, so I'll try to answer my own questions. On Mon, Jan 12, 2009 at 7:33 AM, Jerry James loganje...@gmail.com wrote: 1. Who are the current developers? There's a list on the project web page, but since I can't even get anybody to fix a broken link there (see the first message in this thread), I have no confidence that those pages aren't years out of date. So here's the list from the Savannah page, along with date of last CVS commit, followed by date of last message to this mailing list in -MM-DD format (the namazu results seem to indicate that either the archives are not complete, or some messages were sent off-list and replied to on-list, so these dates may be off arbitrarily): David Billinghurst billingd: NONE, 2008-12-09 Robert Alan Byer ByerRA: 2002-01-11, 2002-01-15 Camm Maguire camm: 2008-09-08, 2008-09-05 Gabriel Dos Reis gdr: 2006-10-27, 2008-12-02 Gene Cooperman gene: 2005-12-19, 2005-12-20 GOTO Kentaro gotoken: NONE, 2002-11-15 David Holmgren holmgren: NONE, 2002-03-21 Michael Koehne kraehe: 2003-08-08, 2005-02-16 Stavros Macrakis macrakis: NONE, 2008-04-17 Mike Thomas mjthomas: 2006-06-23, 2005-02-15 Paul F. Dietz pfdietz: 2006-05-31, 2005-08-08 Walt Read read: NONE, 2002-12-02 Aurelien Chanudet rlbrk: 2005-12-01, 2004-07-18 Robert Read rread: NONE, 2002-01-13 Viet Ha Nguyen vietha: NONE, NONE Vadim V. Zhytnikov vvzhy: 2003-11-22, 2005-08-07 Those who have responded to previous messages of mine are David Billinghurst and Gabriel Dos Reis. Thank you, David and Gabriel. It appears that you are the only GCL developers still reading this list. 2. Who has editing rights on the project web pages? I don't know. 3. Who has commit rights to the code repository? The developers, would be my guess. 4. Who is in charge of release management? Since the last release was in 2005, my guess is nobody. 5. What are the release criteria for 2.6.8 and 2.7.0, respectively? I haven't yet found any information on this. 6. What processes are used to manage incoming patches? There doesn't seem to be one (anymore). 7. What are the policies and procedures around recruiting new developers? I don't know. Along those lines, let me introduce myself and explain my interest in GCL. My first technical job, while still an undergraduate in Computer Science, was as a Lisp programmer. I worked for a year, writing an interviewing tool for a Psychology professor on what, if my memory hasn't failed me, was called Macintosh Allegro Common Lisp. This was around 1990 somewhere. I had read parts of CLtL1 while taking a Lisp class the previous year, and read CLtL2 from cover to cover during that time. I didn't touch Lisp much for a few years after that (unless you can count hacking on my ~/.emacs file). Then, halfway through grad school, a couple of Masters students doing some work for me asked me why I was using Emacs instead of XEmacs. I hadn't heard of XEmacs, so they clued me in. How could I resist the spiffy Gnus interface? So I became an XEmacs convert. I bumped into a few bugs, and started sending patches off to the XEmacs developers. Before long, they recruited me to become a developer, and later a member of the XEmacs Review Board. I've done a number of things to XEmacs (mostly good!), but my biggest feat was adding bignum/bigfloat support to XEmacs Elisp. I modeled it after the Common Lisp types. In 1999, I started life as a Computer Science professor, first at the University of Kansas, and later at Utah State University. During that time I started using PVS [1], which is written in Common Lisp, and started contributing to the project. Just this fall, I completed a port of PVS to SBCL (available Real Soon Now, once the SRI guys have time to roll out a new release). I have been told that GCL is the best-performing free Lisp, and there is a pretty big performance gap for PVS between SBCL and Allegro Lisp. I would like to port PVS to GCL next to have another point of comparison. Since Fedora is my platform of choice, I wanted GCL to be available on Fedora. And since the previous Fedora GCL maintainer gave up on GCL about the time I became interested, I took over. So here we are. I see some things I could do to improve GCL a little, here and there. What can be done to make that possible? References: [1] http://pvs.csl.sri.com/ -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] DESCRIBE and gcl.info
I've pushed a build of 2.6.8pre into Fedora. So far I have only hit one problem: (describe 'foo) doesn't work. It triggers a complaint that gcl cannot find gcl.info. Looking in info/makefile shows that the default build of gcl.info has been commented out. The rule is still in the makefile, but it depends on files named chap-*.texi, which have been removed from the 2.6.8 CVS branch. They still exist in HEAD. So is somebody in the process of changing how DESCRIBE works? If so, what is it changing to? And why is it being changed on the 2.6 branch instead of in HEAD?? Also, in the meantime, how should I fix the Fedora build of gcl so developers can get a working DESCRIBE? Thanks, -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] PPC64 platform
I had to exclude GCL from building on the ppc64 platform for Fedora due to failing builds. Some investigation shows that that platform and a handful of others (such as ia64) have been discussed on this list before. Apparently, the BFD library does not support some of the methods used to make executable dumping possible on other platforms. Has anyone looked further into the ppc64 and other such platforms? What approach can be taken to build a working GCL there? I tried configuring with --enable-dlopen, but that failed with a segfault, just like the BFD build. Thanks, -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] Updated BFD and SELinux patches
I figured out a simpler way to accomplish one part of the upgrade to newer BFD libraries. Also, the Fedora/RedHat SELinux team helped me streamline and improve the SELinux policy for GCL. I have updated the corresponding patches here: http://jjames.fedorapeople.org/gcl/ Regards, -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] How to submit GCL patches
On Wed, Jan 28, 2009 at 6:20 PM, Camm Maguire c...@maguirefamily.org wrote: Greetings, and please excuse my absence of late. I have recently left my job of 17 years, and am confronting a new situation of chronic illness in my family. I am also currently without an effective method for dealing with with the massive amount of spam I receive each day from debian.org. I'm wedded to emacs, and so am trying to get gnus to filter effectively. I'm very sorry to hear about the chronic illness situation. I wish you and your family all the best in dealing with that. I used Emacs + Gnus and then XEmacs + Gnus starting about 1994 up until a couple of years ago. I used spamassassin to filter my email during the last couple of years that I used Gnus. Even with constant training, it never worked very well. A couple of years ago, for a variety of reasons, I moved almost exclusively to gmail. I do get the occasional false negative or false positive, but both are pretty rare. I'd like to launch another GCL burst now if possible. I have a local tree which greatly accelerates the new automatic inlining of 2.7.0, primarily by storing precompiled C strings in addition to compressed lisp code for each compiled function. There are remaining niggles, primarily getting the labels and variable numbers to be adjustable. Finalizing the inlining policy, and hopefully cleaning up the remaining ansi issues, are all that stand in the way of 2.7.0. I'm thrilled to welcome new contributers! Needless to say, all GCL matters are up for consultation -- the more minds the better. I think I have some things to offer this project and would be delighted to have a chance to contribute. Kindly give me a few days to get this email situation sorted out once and for all, then perhaps we can start discussing new issues of substance. Sounds great! Regards, -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] How to submit GCL patches
On Thu, Feb 5, 2009 at 1:31 PM, Camm Maguire c...@maguirefamily.org wrote: Greetings! First, let me thank you again so much for your attention and contribution to GCL! I've downloaded your patches and are looking them over. Regarding the bfd patch, I cannot find a bfd version (on any debian release version at least) which requires this output_bfd setting. Can you fill me in on the problem you encountered? With a sufficiently new BFD library (more on that in a moment), failing to set the output_bfd field triggers a crash due to a null pointer dereference when attempting to read symbols. I took a look at upstream CVS. This page: http://sourceware.org/cgi-bin/cvsweb.cgi/src/include/bfdlink.h?cvsroot=src indicates that the output_bfd field was added in version 1.71 of bfdlink.h, checked in on Feb 15, 2008. Version 2.19 of binutils has subsequently been released. I am on a Fedora 10 machine, where binutils reports its version as 2.18.50.0.9. I presume that is some kind of development snapshot. In any case, /usr/include/bfdlink.h on my machine shows the output_bfd field, and failing to set it results in the aforementioned crash. Perhaps you could register at savannah and send me your username -- then we can discuss some commit policy? If your interested, then welcome aboard! I am user jjames on savannah. I assume you will want to review anything I produce until you gain some confidence that I'm not going to recklessly destroy anything. :-) Regards, -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] Re: binutils induced libz dependency
On Wed, Feb 18, 2009 at 11:18 AM, Camm Maguire c...@maguirefamily.org wrote: Greetings! It also appears that using newer binutils requires a dynamic link dependency against libz. I suppose there is no way around this. (?) Ugh, yes, I hit this. On Fedora 10 (but not Fedora 9 or earlier), /usr/lib64/libbfd.so is a linker script that pulls in /usr/lib64/libbfd.a (ha, you thought you were getting a shared library!) and libz. So for my development platform of choice, the right thing to do is choose to link against a dynamic system libbfd. This is not universally the case across distributions, so I guess configure will have to check for one of these libbfds and pull in libz as necessary. -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] GCC 4.4 and strict aliasing
On Sun, Feb 22, 2009 at 6:43 PM, Camm Maguire c...@maguirefamily.org wrote: Greetings, and thanks so much for looking into this! As always, a small code example is worth its weight in gold. I'm assuming we're referring to code emitted by the GCL lisp compiler? If not, the task is considerably simpler. In either case, we've adapted to gcc changes before and can do so again. 4.4 is not yet in Debian sid, apparently. No, or at least the build didn't make it far enough to emit code from the Lisp compiler. See the build log here: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/x86_64/gcl-2.6.8-0.1.20080902cvs.2.fc11.src.rpm/result/build.log BTW, I've made considerable progress on your very helpful patches and will have more to report soon. Great.! I'm happy to answer any questions you may have. -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Offtopic: productivity enhancing Linux howto sought
I don't know much about Ubuntu, but I'll take a stab at a few of these On Fri, Feb 27, 2009 at 12:53 PM, Camm Maguire c...@maguirefamily.orgwrote: Greetings! Any pointers to the following would speed up things quite a bit: 1) terse instructions for getting laptop suspend working on Acer Aspire series (mine hangs at Suspending console ...) (i.e. do certain modules need reloading across resume, etc.) Here are instructions for the 9113. What model do you have? http://www.freewebs.com/gkiagia/hibernate.html 2) howto turnoff verbose ubuntu kernel logging, at least to console 3) howto capture and preserve bootup messages, not the same as dmesg output https://wiki.ubuntu.com/BootMessageLogging 4) terse instructions on howto use the emacs lisp compiler debugger, specifically warning message control (i.e. some present with compile-defun, but not byte-compile-file.) Somehow I don't think is what you are talking about, but just in case: http://www.gnu.org/software/emacs/elisp/html_node/Compiler-Errors.html 5) prevent/diagnose usb wireless lockups Without knowing more about the problem, all I can suggest is that you take a look here: http://wireless.kernel.org/ 6) best way to quickly toggle system network settings based on laptop location change. (including exim configuration) Take care, -- Camm Maguirec...@maguirefamily.org == The earth is but one country, and mankind its citizens. -- Baha'u'llah ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel Regards, -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] Release notes
Fedora 11 is coming! I have just been pinged by the team putting together release notes. They want to know what has changed from GCL 2.6.7 to 2.6.8pre. My history with GCL is so short that I don't know how to answer the question. Can anybody give me a few bullet items that I can pass on to that team? They can be in raw form; the release notes team will massage them to make them read well and look good. Thank you, -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] Re: release notes
On Wed, Mar 4, 2009 at 4:15 PM, Camm Maguire c...@maguirefamily.org wrote: Greetings! Here is the relevant list from debian/changelog. I hope this is not too cryptic. Will likely need some clarification. Thanks for the notes. This is very helpful. I do have a question about that first item: * New upstream release Does that refer to 2.6.7, or to an as yet unannounced 2.6.8 release? -- Jerry James http://loganjerry.googlepages.com/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] asm/signal.h
The configure script tells me that it is unable to process asm/signal.h, even though that header file exists. This happens on both Fedora 10 and the current snapshot of Fedora 11-to-be. The problem turns out to be conflicting type definitions in the glibc 2.9 (Fedora 10) or glibc 2.10 (Fedora 11) header files and the Linux kernel 2.6.27 (Fedora 10) or 2.6.29 (Fedora 11) headers. As it also turns out, just defining __ASSEMBLY__ before including asm/signal.h is enough to make it not read the Linux kernel headers, thereby solving the problem. Does anybody else see this? To check, make a file test.c with these contents: #include stdio.h #include asm/signal.h Then I see the following: $ gcc -c test.c In file included from /usr/include/asm/signal.h:7, from test.c:3: /usr/include/linux/time.h:10: error: expected specifier-qualifier-list before ‘time_t’ /usr/include/linux/time.h:16: error: expected specifier-qualifier-list before ‘time_t’ If I change the file contents to this: #include stdio.h #define __ASSEMBLY__ #include asm/signal.h then the gcc invocation succeeds. -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] PLT problem on Sparc
A group of people are trying to get a Sparc build of Fedora put together. I just received a report from them that attempting to build GCL failed. The immediate problem is that plt.h is being generated with these contents: MY_PLT(), MY_PLT(), MY_PLT(_mcount), MY_PLT(_setjmp), MY_PLT(acos), MY_PLT(acosh), MY_PLT(asin), MY_PLT(asinh), MY_PLT(atan), MY_PLT(atanh), MY_PLT(cos), MY_PLT(cosh), MY_PLT(exp), MY_PLT(fdopen), MY_PLT(feof), MY_PLT(log), MY_PLT(memset), MY_PLT(read), MY_PLT(sin), MY_PLT(sincos), MY_PLT(sinh), MY_PLT(sqrt), MY_PLT(sscanf), MY_PLT(tan), MY_PLT(tanh), MY_PLT(write) Those two empty invocations of MY_PLT() at the top are causing a compilation error. It's been a long time since I last used AWK. Before I go dig out my AWK manual to try to figure out what happened here, does anybody have any ideas on what could lead to those empty entries? Thanks, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] PLT problem on Sparc
: 0 SECTION LOCAL DEFAULT 16 13: 0 SECTION LOCAL DEFAULT 17 14: 0 SECTION LOCAL DEFAULT 19 15: 0 SECTION LOCAL DEFAULT 20 16: 0 SECTION LOCAL DEFAULT 18 17: 612 FUNCGLOBAL DEFAULT1 main 18: 0002 0 REGISTER GLOBAL DEFAULT UND 19: 0003 0 REGISTER GLOBAL DEFAULT UND 20: 0 NOTYPE GLOBAL DEFAULT UND __isoc99_sscanf 21: 0 NOTYPE GLOBAL DEFAULT UND memset 22: 0 NOTYPE GLOBAL DEFAULT UND _IO_getc 23: 0 NOTYPE GLOBAL DEFAULT UND _IO_putc 24: 0 NOTYPE GLOBAL DEFAULT UND feof 25: 0 NOTYPE GLOBAL DEFAULT UND fdopen 26: 0 NOTYPE GLOBAL DEFAULT UND read 27: 0 NOTYPE GLOBAL DEFAULT UND write 28: 0 NOTYPE GLOBAL DEFAULT UND _mcount 29: 0 NOTYPE GLOBAL DEFAULT UND _setjmp 30: 0 NOTYPE GLOBAL DEFAULT UND cos 31: 0 NOTYPE GLOBAL DEFAULT UND sin 32: 0 NOTYPE GLOBAL DEFAULT UND sincos 33: 0 NOTYPE GLOBAL DEFAULT UND tan 34: 0 NOTYPE GLOBAL DEFAULT UND acos 35: 0 NOTYPE GLOBAL DEFAULT UND asin 36: 0 NOTYPE GLOBAL DEFAULT UND atan 37: 0 NOTYPE GLOBAL DEFAULT UND cosh 38: 0 NOTYPE GLOBAL DEFAULT UND sinh 39: 0 NOTYPE GLOBAL DEFAULT UND tanh 40: 0 NOTYPE GLOBAL DEFAULT UND acosh 41: 0 NOTYPE GLOBAL DEFAULT UND asinh 42: 0 NOTYPE GLOBAL DEFAULT UND atanh 43: 0 NOTYPE GLOBAL DEFAULT UND exp 44: 0 NOTYPE GLOBAL DEFAULT UND log 45: 0 NOTYPE GLOBAL DEFAULT UND sqrt So it looks like the culprits are the two REGISTER entries for REG_G2 and REG_G3. -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] PLT problem on Sparc
On Fri, Jun 19, 2009 at 1:24 PM, Camm Maguirec...@maguirefamily.org wrote: Greetings! Does this patch just committed into 2.6.8pre fix this problem? Thanks, Camm. You've saved me from having to re-learn AWK! :-) I'll get back with the people who have the Sparc hardware and have them give this a try. I'm going to be out of touch for a couple of days starting in about half an hour, though, so I probably won't make any progress on this until next week. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] cvs make on redhat 5.0
On Tue, Jun 23, 2009 at 7:54 AM, Jim Wardse...@uwyo.edu wrote: Hi all, So 2.6.7 on redhat/centos 5.3, configure and make fails. I tried the cvs version and while configure completes (no errors). make fails with this error: # make make: *** No rule to make target `/usr/lib/libbfd.a', needed by `copy_bfd'. Stop. Thanks for any help. I really need to get gcl working again, so I can then compile acl2. I'm curious to know if this source RPM builds successfully for you: http://download.fedora.redhat.com/pub/fedora/linux/updates/10/SRPMS/gcl-2.6.8-0.3.20090303cvs.fc10.src.rpm If you try it, please let me know if it builds or not (I'm the Fedora maintainer). Also, if it does build successfully and you are using SELinux, note that you will have to label image files produced by gcl with the gcl_exec_t type. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] cvs make on redhat 5.0
On Tue, Jun 23, 2009 at 8:57 AM, Jim Wardse...@uwyo.edu wrote: I have dependencies problems. Redhat 5.x normally works pretty well with Fedora 6/7/8, 9 and 10 I have a lot of problems with seems like names changes or something. Anyway, I get the following errors rpmbuild: rpmbuild -ba gcl.spec tex(latex) is needed by gcl-2.6.8-0.3.20090303cvs.noarch xemacs-devel is needed by gcl-2.6.8-0.3.20090303cvs.noarch xemacs-packages-extra is needed by gcl-2.6.8-0.3.20090303cvs.noarch Can't find tex(latex) version? have tetex-latex-3.0-33.2.el5_1.2 install Xemacs was removed from the redhat/centos 5.x dist. I have a version I built and put into /usr/local for everyone to use. If you don't mind editing the spec file a little, I think we can get a version that works for you. First, change the tex(latex) BuildRequires to tetex-latex. (The tex(foo) Provides were added in Fedora to handle the transition from tetex to texlive.) Second, if you don't care about XEmacs support in your GCL build, then just nuke every mention of XEmacs in the spec file, subpackages and all. If you do care, we'll have to get you an XEmacs package first. I'm attaching what I think the final spec file should look like. -- Jerry James http://www.jamezone.org/ gcl.spec Description: Binary data ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] cvs make on redhat 5.0
Let's keep the list involved, in case someone else has a similar question/problem later. On Tue, Jun 23, 2009 at 9:36 AM, Jim Wardse...@uwyo.edu wrote: Ok, made the changes, looks like gcl built, but now I build errors looks like for selinux. selinux is disable (but installed) on our systems (to much a pain). How can I disable selinux part, partial output below. Okay, so we need to rip the SELinux parts out, too. Result attached. Oh and before I forget, does this install into /usr/local or /usr? I would really like to avoid installing gcl on about 70+ linux machines and just install it once into /usr/local. Hm. Well, rpm builds for /usr by default. I can think of two ways to try addressing this. First, maybe we can just define _prefix to /usr/local in the spec file. I've added that to the attached version, but I don't know if it will work. However, now you have an RPM-managed package in /usr/local, which doesn't seem like a good thing. The second approach to try is to only do the rpmbuild -bp part to get the patches applied, etc., then manually configure and build following the recipe in the spec file so that you can control the resulting install prefix. And did I say THANKS! You are very welcome. -- Jerry James http://www.jamezone.org/ gcl.spec Description: Binary data ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Fedora Sparc build problem
On Sun, Aug 16, 2009 at 8:29 AM, Camm Maguirec...@maguirefamily.org wrote: Greetings! I'm away from home for another week, but I just wanted t add this quickly -- I think the error handler was called recursively from your output. Please make sure you are looking at the topmost call to the error handler. Also -- if remote access to this machine can be arranged, I'd be happy to take a look if you'd like. I would be very happy if you could take a look. I'll see if remote access for you can be arranged. Thanks! -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Re: [TeXmacs] A rewrite of tm_axiom.c (attached)
On Mon, Oct 12, 2009 at 9:38 PM, Jerry James loganje...@gmail.com wrote: I am the Fedora maintainer of gcl. I welcome input on how the gcl package should be configured and built. Et cetera. I got bounce messages back from open-axiom-devel and texmacs-users, both of which appear to be closed lists. If you want the discussion to continue cross-posted on those lists, it looks like you'll have to forward my messages there yourself. -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Re: [TeXmacs] A rewrite of tm_axiom.c (attached)
On Mon, Oct 12, 2009 at 9:38 PM, Jerry James loganje...@gmail.com wrote: The *(.iplt) line didn't use to be present. I found .iplt lines being generated when I last built on Fedora Rawhide (soon to be F-12), and fixed the problem there. I didn't realize it had shown up in F-11 as well. I'll roll a new F-11 package with the iplt fix in it tomorrow. The new package will appear in the updates-testing repository after the next compose. Here are direct links for the impatient: http://koji.fedoraproject.org/koji/buildinfo?buildID=136447 Please let me know whether this build resolves the problem. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] PLT patch
This is the patch I used to resolve the recent issue with .iplt
sections and compilation of open-axiom:
diff -dur gcl-2.6.8.ORIG/o/makefile gcl-2.6.8/o/makefile
--- gcl-2.6.8.ORIG/o/makefile 2009-08-11 15:11:17.769474923 -0600
+++ gcl-2.6.8/o/makefile2009-08-11 15:11:46.167645473 -0600
@@ -149,7 +149,7 @@
$(CC) -c $(CFLAGS) $(DEFS) $*.c $(AUX_INFO)
plt.h: plttest.o
- nm $ | $(AWK) '/ U / {if ($$NF!=2) next;a=$$2;if (k) sub(^_,,a);\
+ nm $ | $(AWK) '/ U / {if (NF!=2) next;a=$$2;if (k) sub(^_,,a);\
print a}' \
k=$(LEADING_UNDERSCORE) |\
sort | \
diff -dur gcl-2.6.8.ORIG/o/plt.c gcl-2.6.8/o/plt.c
--- gcl-2.6.8.ORIG/o/plt.c 2008-08-03 09:16:22.0 -0600
+++ gcl-2.6.8/o/plt.c 2009-08-11 15:12:26.627506327 -0600
@@ -135,7 +135,7 @@
for (i=j=0,li=Cnil;fgets(b,sizeof(b),f);) {
if (!memchr(b,10,sizeof(b)-1))
FEerror(plt buffer too small, 0);
-if (memcmp(b, .plt,4) !i)
+if ((memcmp(b, .plt,5) || memcmp(b, .iplt,6)) !i)
continue;
if (*b=='\r' || *b=='\n') {
i=0;
--
Jerry James
http://www.jamezone.org/
___
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] Ellipsis patch
I can't remember if I sent this one before or not. GCC complains
about undefined behavior when a varargs function's last non-varargs
parameter is declared to have storage class register. Since varargs
works by taking the address of that parameter, and register is a
promise to never take the address of a variable, the two conflict.
This patch fixes the issue.
diff -dur gcl-2.6.8.ORIG/o/bind.c gcl-2.6.8/o/bind.c
--- gcl-2.6.8.ORIG/o/bind.c 2006-06-21 14:03:05.0 -0600
+++ gcl-2.6.8/o/bind.c 2009-08-11 14:11:56.982474159 -0600
@@ -708,7 +708,7 @@
#defineNOT_KEYWORD 1
void
-parse_key(object *base, bool rest, bool allow_other_keys, register int n, ...)
+parse_key(object *base, bool rest, bool allow_other_keys, int n, ...)
{
object temporary;
va_list ap;
diff -dur gcl-2.6.8.ORIG/o/external_funs.h gcl-2.6.8/o/external_funs.h
--- gcl-2.6.8.ORIG/o/external_funs.h2003-08-29 14:41:59.0 -0600
+++ gcl-2.6.8/o/external_funs.h 2009-08-11 14:17:35.000473249 -0600
@@ -167,8 +167,8 @@
extern object find_special GPR((object body, struct bind_temp *start,
struct bind_temp *end));;
extern object let_bind GPR((object body, struct bind_temp *start,
struct bind_temp *end));;
extern object letA_bind GPR((object body, struct bind_temp *start,
struct bind_temp *end));;
-extern int parse_key GPR((object *base, bool rest, bool
allow_other_keys, register int n, int __builtin_va_alist));;
-extern int check_other_key GPR((object l, int n, int __builtin_va_alist));;
+extern int parse_key GPR((object *base, bool rest, bool
allow_other_keys, int n, ...));;
+extern int check_other_key GPR((object l, int n, ...));;
extern int parse_key_new GPR((int n, object *base, struct key *keys, ...));;
extern int parse_key_rest GPR((object rest, int n, object *base,
struct key *keys, ...));;
extern int set_key_struct GPR((struct key *ks, object data));;
@@ -380,7 +380,6 @@
extern int not_a_variable GPR((int obj));;
extern int illegal_index GPR((object x, object i));;
extern int Lerror GPR((void));;
-extern object LVerror GPR((int __builtin_va_alist));;
extern int Lcerror GPR((void));;
extern int vfun_wrong_number_of_args GPR((object x));;
extern int init_error GPR((void));;
@@ -415,9 +414,6 @@
extern object ifuncall2 GPR((object fun, object arg1, object arg2));;
extern object ifuncall3 GPR((object fun, object arg1, object arg2,
object arg3));;
extern int funcall_with_catcher GPR((object fname, object fun));;
-extern object fcalln_cclosure GPR((...));;
-extern object fcalln_general GPR((...));;
-extern object fcalln_vfun GPR((va_list vl));;
-extern object fcalln GPR((int __builtin_va_alist));;
-extern object funcall_cfun GPR((funcvoid fn, int n, int
__builtin_va_alist));;
+extern object fcalln GPR((object first, ...));;
+extern object funcall_cfun GPR((funcvoid fn, int n, ...));;
extern int init_eval GPR((void));;
--
Jerry James
http://www.jamezone.org/
___
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] PLT patch for GNU ld = 2.19
I recently received this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=542004 The patch included in that bug report is to be applied on top of the PLT patch I sent earlier. I'll attach a patch to this message that applies directly to current 2.6.8-pre. Regards, -- Jerry James http://www.jamezone.org/ gcl-2.6.8-plt.patch Description: Binary data ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] 2.6.8 licensing
On Wed, Oct 27, 2010 at 4:19 PM, Camm Maguire c...@maguirefamily.org wrote: Greetings! The FSF has requested that we change the software license to GPLv3 or later, and the documentation license FDLv1.3 or later. By this I think they mean LGPLv3 of course. Forgive me if I've mistaken your meaning, but there is an FDL: http://www.gnu.org/licenses/fdl-1.3.html -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] Man page problems (2.6.8)
While reading the gcl man page, I noticed some oddities. The first one is because of this construct on lines 149-154: .B \-compile .RB Invoke the compiler on the filename following .BR \-compile . Other flags affect compilation. The . Other is interpreted as a macro, due to a . at the start of the line. Since nroff doesn't recognize the macro, it drops the entire line from the output. The second is in lines 206-209: This GNU package should not be confused with the proprietary program distributed by FRANZ, Inc. Nor should it be confused with the public domain \*(Fl or the proprietary \*(Li. What are \*(Fl and \*(Li supposed to be, lists of free and proprietary Lisps, respectively? If so, what is supposed to generate those lists? For the time being, I'm applying the following patch to the Fedora gcl build. Please let me know if there's a better solution. --- man/man1/gcl.1.orig2002-02-03 11:44:07.0 -0700 +++ man/man1/gcl.12010-12-30 14:09:50.834355544 -0700 @@ -149,8 +149,7 @@ .B \-compile .RB Invoke the compiler on the filename following -.BR \-compile -. Other +\fB\-compile\fR. Other flags affect compilation. .TP @@ -205,8 +204,6 @@ This GNU package should not be confused with the proprietary program distributed by FRANZ, Inc. -Nor should it be confused with the public domain \*(Fl or the proprietary -\*(Li. For anything other than program development, use of the lisp compiler \fIglc\fP(1L) is strongly recommended in preference to use of the interpreter, Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] Patch for gcc 4.6 / volatile
The Fedora project is in the midst of a mass package rebuild. One of the reasons for doing this is so that all C/C++/... code in Fedora 15 packages will have been built with GCC 4.6 (to be). The GCL package failed to rebuild. The build failure looks exactly like the one reported here, but this time GCC did emit warnings: http://lists.gnu.org/archive/html/gcl-devel/2005-07/msg00028.html I think the volatile annotations are still not correct. The attached patch results in a successful build for me. I think the print.d portion is obviously correct. For the prog.c portion, the pointers in new_top and bodysv are used after the setjmp call, so should also be volatile. The tinf variable is only used to iterate, and is initialized after the setjmp call, so it does not need to be volatile. The tinf_base variable (as also new_top and bodysv) should be declared with the volatile AFTER the asterisk, rather than before, because it is the pointer itself that needs to survive the setjmp call, not the thing pointed to. Regards, -- Jerry James http://www.jamezone.org/ gcl-2.6.8-volatile.patch Description: Binary data ___ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] configure: EMACS_DEFAULT_EL
On Wed, Dec 21, 2011 at 8:15 PM, Andrey G. Grozin a.g.gro...@inp.nsk.su wrote: Hello *, I've checked out gcl Version_2_6_8pre from cvs on 21.12.2011, and compiled it on 32-bit gentoo linux (gcl is no longer in gentoo officially, due to the absence of a release). The current configure, in order to find EMACS_DEFAULT_EL, does $EMACS -q -batch --no-site-file -l conftest.el 21 But there is no conftest.el anywhere; as a result, default.el is installed into / - not the place one would wish. What's conftest.el and where should it be? Andrey It is created by the configure script itself. Look for this line: cat conftest.el EOF Perhaps your problem is caused by an earlier configure error. Try looking through config.log to see if it all looks sane. -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unhandled R_ARM_MOVW_ABS_NC reloc
On Sat, Dec 29, 2012 at 9:37 AM, Camm Maguire c...@maguirefamily.org wrote: Can you provide access to a machine showing this problem? I don't own any ARM hardware myself. I've made a few attempts at setting up an ARM virtual machine using the images here: http://scotland.proximity.on.ca/arm-nightlies/vault/. I've had trouble getting the Fedora 18 images to work, up until the most recent set, in the f18-beta-tc3 directory. The F18-vexpress-xfce-20121218.tar.xz bundle is working for me, but the virtual SD card is so small, that just installing the build dependencies filled the thing up. As soon as I figure out how to add more storage, I'm going to try a test build on it. This might be worth a try, too: http://www.calxeda.com/trystack/. One of the Calxeda guys, Mark Langsdorf, is active on the Fedora ARM mailing list. -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unhandled R_ARM_MOVW_ABS_NC reloc
On Sat, Dec 29, 2012 at 9:37 AM, Camm Maguire c...@maguirefamily.org wrote: Can you provide access to a machine showing this problem? I have made a list of instructions on how to setup an ARM virtual machine that illustrates the problem: http://software.jamezone.org/HOWTO/gcl-arm.html. Hopefully that helps. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unhandled R_ARM_MOVW_ABS_NC reloc
On Wed, Jan 9, 2013 at 11:25 AM, Jerry James loganje...@gmail.com wrote: I have made a list of instructions on how to setup an ARM virtual machine that illustrates the problem: http://software.jamezone.org/HOWTO/gcl-arm.html. Hopefully that helps. Regards, Also, here's a patch to show the reloc type ff an unhandled reloc type is ever encountered again. -- Jerry James http://www.jamezone.org/ gcl-2.6.8-reloc-type.patch Description: Binary data ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unhandled R_ARM_MOVW_ABS_NC reloc
On Wed, Jan 9, 2013 at 11:25 AM, Jerry James loganje...@gmail.com wrote: I have made a list of instructions on how to setup an ARM virtual machine that illustrates the problem: http://software.jamezone.org/HOWTO/gcl-arm.html. Hopefully that helps. Regards, Following my own recipe, I added the patch you suggested earlier in this thread. That (plus the reloc-type patch I sent earlier today), resulted in this: Finished compiling /root/rpmbuild/BUILD/gcl-2.6.8/unixport/../pcl/gcl_pcl_pkg.o. Loading binary of GCL_PCL_PKG... Unknown reloc type 44 Error: The assertion tp~tp on line 181 of sfaslelf.c in function relocate failed Fast links are on: do (si::use-fast-links nil) for debugging Error signalled by OR. Broken at LOAD. Type :H for Help. make[1]: *** [gcl_pcl_boot.c] Error 255 make[1]: Leaving directory `/root/rpmbuild/BUILD/gcl-2.6.8/pcl' make: *** [unixport/saved_pcl_gcl] Error 2 Reloc type 44 is R_ARM_MOVT_ABS. If you could please suggest code for that case, too, I'll give it a try. Thank you, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] ARM relocs
On Mon, Jan 21, 2013 at 8:27 AM, Camm Maguire c...@maguirefamily.org wrote: Greetings! The constants R_ARM_MOVT_ABS et.al. don't appear to be defined in any header, unlike other platforms. Am I missing something? Hmmm, I don't see them anywhere, either. Ultimately, they are derived from the Linux sources. I see this in arch/arm/include/asm/elf.h in the Linux 3.7 source tree: #define R_ARM_NONE0 #define R_ARM_PC241 #define R_ARM_ABS322 #define R_ARM_CALL28 #define R_ARM_JUMP2429 #define R_ARM_V4BX40 #define R_ARM_PREL3142 #define R_ARM_MOVW_ABS_NC43 #define R_ARM_MOVT_ABS44 #define R_ARM_THM_CALL10 #define R_ARM_THM_JUMP2430 #define R_ARM_THM_MOVW_ABS_NC47 #define R_ARM_THM_MOVT_ABS48 But you're right, those defines don't seem to make it into any shipped header file. I'll ask about this on the Fedora ARM mailing list. -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] ARM reloc; default timezone, and user-homedir-pathname
On Mon, Jan 21, 2013 at 12:30 PM, Camm Maguire c...@maguirefamily.org wrote: Greetings! While I cannot yet confirm the reloc documentation, I've gone ahead and checked in the algorithm as it has proved quite robust under testing. Will continue to try to confirm. Thanks so much for looking into this, Camm! -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] Patch for s390x support
Hello Camm, The Fedora team that is working on IBM System z support found that they need support for a new reloc type, too. They suggest this patch for s390: diff -up gcl-2.6.8/h/elf32_s390_reloc.h.s390 gcl-2.6.8/h/elf32_s390_reloc.h --- gcl-2.6.8/h/elf32_s390_reloc.h.s3902013-01-23 07:50:36.0 -0500 +++ gcl-2.6.8/h/elf32_s390_reloc.h2013-01-23 07:50:43.0 -0500 @@ -5,3 +5,7 @@ case R_390_PC32: add_val(where,~0L,s+a-p); break; + + case R_390_PC32DBL: +add_val(where,~0L,(s+a-p)1); +break; Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] ASDF 2.32 released
On Tue, Mar 5, 2013 at 6:29 PM, Faré fah...@gmail.com wrote: Why do I bother contacting the GCL team? I dunno. Maybe some day I manage to compile GCL again, add debug GCL support. In any case, if and when you make another release of GCL, don't forget to include ASDF as a provided module. I maintain the GCL package for Fedora. I gave up on 2.6.7 over 4 years ago; it just won't build on modern Linux systems. But I've been building the 2.6.8pre branch successfully all that time. It's true that I'm also carrying no less than 17 patches against 2.6.8pre, but if you would like a recipe that builds a working GCL, let me know. -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] GCC 4.8.0 problem
On Mon, Feb 25, 2013 at 2:59 PM, Jerry James loganje...@gmail.com wrote: Fedora Rawhide has moved to what will soon be GCC 4.8.0. GCL now fails to build properly on i386, although it still builds properly on x86_64. The build reaches this point: I finally got around to figuring this out. The GCC 4.8.0 release notes say that -O implies -fomit-frame-pointer on more platforms now. Apparently i386 is one of them. If I add -fno-omit-frame-pointer to the build flags, and edit configure to remove the spot where it adds -fomit-frame-pointer to the build flags, then the build succeeds. I have no idea why that makes a difference. The symptom was that the value stack would overflow. Is management of the value stack tied to the program stack somehow? Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] Segfault while building maxima
out) at eval.c:1100 #195407 0x00461cc4 in funcall (fun=optimized out) at eval.c:335 #195408 0x00461969 in eval (form=optimized out) at eval.c:1100 #195409 0x00461cc4 in funcall (fun=optimized out) at eval.c:335 #195410 0x0040d1dc in main (argc=9, argv=optimized out, envp=optimized out) at main.c:363 The line in add_page_to_freelist in alloc.c in frame 195390 is: make_writable(nn,nn+1); The previous, working, build was made from a CVS snapshot on 26 Jan 2013. GCC has changed in the meantime, to version 4.8.1, but I just built the previous snapshot, then rebuilt maxima, and it worked. So something has changed in CVS between 26 Jan and now that is causing this. Any clues are much appreciated. Thanks, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Segfault while building maxima
On Tue, Jun 4, 2013 at 4:34 PM, Jerry James loganje...@gmail.com wrote:
I built the latest 2.6.8pre from CVS a few days ago for Fedora
Rawhide. Now it is segfaulting while building maxima:
I looked through the diff from the 26 Jan 2013 snapshot to current CVS
head to see if I could spot something that might be related. I
applied this patch to revert one change:
--- o/sgbc.c.orig2013-05-10 20:25:57.0 -0600
+++ o/sgbc.c2013-06-04 16:44:51.156907429 -0600
@@ -1158,14 +1158,14 @@
return -1;
}
{ /* mips kernel bug test -- SIGBUS with no faddr when floating
point is emulated. */
-float *f1=(void *)memprotect_test_address,*f2=(void
*)b2,*f1e=f1+p/sizeof(*f1);
+float *f1=(void *)memprotect_test_address,*f2=(void *)b2;
if (mprotect(memprotect_test_address,p,PROT_READ_EXEC)) {
memprotect_result=memprotect_cannot_protect;
return -1;
}
memprotect_result=memprotect_bad_return;
-for (;f1f1e;) *f1++=*f2;
+*f1=*f2;
if (memprotect_result==memprotect_bad_return)
memprotect_result=memprotect_no_signal;
if (memprotect_result!=memprotect_none) {
and now maxima builds successfully and passes all tests. On the other
hand, I see this in the logs:
Loading /builddir/build/BUILD/maxima-5.30.0/src/init-cl.lisp
Finished loading /builddir/build/BUILD/maxima-5.30.0/src/init-cl.lisp
; - Providing system maxima
The SGC segfault recovery test failed with memprotect_no_signal, SGC disabled
So the patch above is not correct, but I don't understand this code
well enough to know what to do to fix the infinite recursion described
in my first message. Regards,
--
Jerry James
http://www.jamezone.org/
___
Gcl-devel mailing list
Gcl-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Migrate to git?
On Fri, Jul 12, 2013 at 8:35 AM, Bruce-Robert Fenn Pocock brpoc...@star-hope.org wrote: On Fri, Jul 12, 2013 at 10:32 AM, Игорь Пашев pashev.i...@gmail.comwrote: 2013/7/12 Camm Maguire c...@maguirefamily.org: Greetings! Subject says it all -- any opinions? YES, please! :-) +1 I am also very much in favor. -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] TCL_signal_error bug
I happened to spot a gcc warning when building the latest GCL release
(thanks, Camm!) for Fedora. The function TCL_signal_error() in
gcl/gcl-tk/tkMain.c has an sprintf call that omits the buffer it is
supposed to be printing into. I think this patch is appropriate:
diff --git a/gcl/gcl-tk/tkMain.c b/gcl/gcl-tk/tkMain.c
index 9b1ee37..39a12e1 100755
--- a/gcl/gcl-tk/tkMain.c
+++ b/gcl/gcl-tk/tkMain.c
@@ -191,7 +191,7 @@ static void
TCL_signal_error(x)
char *x;
{char buf[300] ;
- sprintf(error %s,x);
+ snprintf(buf,300,error %s,x);
Tcl_Eval(interp,buf);
dfprintf(stderr,x);
}
Regards,
--
Jerry James
http://www.jamezone.org/
___
Gcl-devel mailing list
Gcl-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] gcl-2.6.10 and tcl/tk-8.6
On Tue, Feb 4, 2014 at 8:26 PM, Andrey G. Grozin a.g.gro...@inp.nsk.suwrote: Hello *, A deprecated interp-result has finally disappeared in tcl-8.6, one has to use Tcl_GetStringResult(interp) instead. gcl-2.6.10 (as well as all earlier versions) don't compile with tcl-8.6 or later. The attached patch to tkMain.c fixes the problem (I've already sent it to the list in March 2013, but it is not yet included). I've committed gcl-2.6.10 ebuild to Gentoo, largely based on the fedora srpm by Jerry James (thanks!). But this patch is also absent in fedora. Does fedora use a very old tcl? The current stable version, Fedora 20, has tcl 8.5.14. The development version, Rawhide, currently has 8.5.15, but see: https://bugzilla.redhat.com/show_bug.cgi?id=889201 Thanks for the patch! Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] gcl-2.6.10 and tcl/tk-8.6
On Wed, Feb 5, 2014 at 9:04 AM, Jerry James loganje...@gmail.com wrote:
Thanks for the patch! Regards,
Camm, how about the attached version of the patch? This will let gcl still
compile should there be any Tcl 7 users left in the world. :-) Regards,
--
Jerry James
http://www.jamezone.org/
diff --git a/gcl/gcl-tk/tkMain.c b/gcl/gcl-tk/tkMain.c
index 74475cc..21c6c59 100755
--- a/gcl/gcl-tk/tkMain.c
+++ b/gcl/gcl-tk/tkMain.c
@@ -42,6 +42,11 @@
#if (TK_MINOR_VERSION==0 TK_MAJOR_VERSION==4)
#define TkCreateMainWindow Tk_CreateMainWindow
#endif
+#if TCL_MAJOR_VERSION = 8
+#define INTERP_RESULT(interp) Tcl_GetStringResult(interp)
+#else
+#define INTERP_RESULT(interp) (interp)-result
+#endif
/*---*/
@@ -276,7 +281,7 @@ TkX_Wish (argc, argv)
if (Tk_ParseArgv(interp, (Tk_Window) NULL, argc, (void *)argv, argTable, 0)
!= TCL_OK) {
- fprintf(stderr, %s\n, interp-result);
+ fprintf(stderr, %s\n, INTERP_RESULT(interp));
exit(1);
}
if (name == NULL) {
@@ -309,7 +314,7 @@ TkX_Wish (argc, argv)
/* mainWindow = TkCreateMainWindow(interp, display, name/\* , Tk *\/); */
/* if (mainWindow == NULL) { */
-/* fprintf(stderr, %s\n, interp-result); */
+/* fprintf(stderr, %s\n, INTERP_RESULT(interp)); */
/* exit(1); */
/* } */
/* #ifndef __MINGW32__ */
@@ -362,7 +367,7 @@ TkX_Wish (argc, argv)
Tcl_FindExecutable ( argv[0] );
#else
if (Tcl_AppInit(interp) != TCL_OK) {
- fprintf(stderr, Tcl_AppInit failed: %s\n, interp-result);
+ fprintf(stderr, Tcl_AppInit failed: %s\n, INTERP_RESULT(interp));
}
#endif
/*
@@ -372,7 +377,7 @@ TkX_Wish (argc, argv)
if (geometry != NULL) {
code = Tcl_VarEval(interp, wm geometry . , geometry, (char *) NULL);
if (code != TCL_OK) {
- fprintf(stderr, %s\n, interp-result);
+ fprintf(stderr, %s\n, INTERP_RESULT(interp));
}
}
@@ -402,13 +407,13 @@ TkX_Wish (argc, argv)
fullName = Tcl_TildeSubst(interp, tcl_RcFileName, buffer);
if (fullName == NULL) {
- fprintf(stderr, %s\n, interp-result);
+ fprintf(stderr, %s\n, INTERP_RESULT(interp));
} else {
f = fopen(fullName, r);
if (f != NULL) {
code = Tcl_EvalFile(interp, fullName);
if (code != TCL_OK) {
- fprintf(stderr, %s\n, interp-result);
+ fprintf(stderr, %s\n, INTERP_RESULT(interp));
}
fclose(f);
}
@@ -443,7 +448,7 @@ TkX_Wish (argc, argv)
error:
msg = Tcl_GetVar(interp, errorInfo, TCL_GLOBAL_ONLY);
if (msg == NULL) {
- msg = interp-result;
+ msg = INTERP_RESULT(interp);
}
dfprintf(stderr, %s\n, msg);
Tcl_Eval(interp, errorExitCmd);
@@ -566,13 +571,13 @@ StdinProc(clientData, mask)
|| code)
{
char buf[4];
- char *p = buf;
+ char *p = buf, *string;
/*header */
*p++ = (code ? '1' : '0');
bcopy(msg-msg_id,p,3);
/* end header */
- if(sock_write_str2(dsfd, m_reply, buf, 4 ,
- interp-result, strlen(interp-result))
+ string = INTERP_RESULT(interp);
+ if(sock_write_str2(dsfd, m_reply, buf, 4, string, strlen(string))
0)
{ /* what do we want to do if the write failed */}
@@ -752,7 +757,7 @@ guiBindCallback(char *szNameCmdProc, char *szTclObject, char *szModifier,char* a
code = Tcl_Eval(interp, szCmd);
if (code != TCL_OK)
{
- dfprintf(stderr, TCL Error int bind : %s\n, interp-result);
+ dfprintf(stderr, TCL Error int bind : %s\n, INTERP_RESULT(interp));
}
return code;
___
Gcl-devel mailing list
Gcl-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] gcl-2.6.10 and tcl/tk-8.6
On Tue, Feb 11, 2014 at 11:15 AM, Camm Maguire c...@maguirefamily.orgwrote: Thanks! Looking into this. What is the portable way these days to get the path to tclConfig.sh from tclsh? I have to admit that I know little about tcl. On Fedora systems, tclConfig.sh is in /usr/lib (32-bit systems) or /usr/lib64 (64-bit systems). On Debian systems, it is in /usr/lib. I don't know if that pattern holds up for other distributions. -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] selinux support
On Thu, Aug 21, 2014 at 2:06 PM, Camm Maguire c...@maguirefamily.org wrote: Thank you so much for this. So I suppose this means this personality bit will be completely meaningless? On future versions of Fedora, yes. It may be a reasonable workaround for other distributions for some time to come. (And it will work on Fedora 20 until it reaches End Of Life sometime next year.) I will have to read up on selinux 'policy' files. I take it this means an ordinary user will not be able to build gcl and or dependencies on fedora. I take it also that every application which unexec's an image compiled by gcl will have to either be listed in this policy file or some other one. Do such things belong in the gcl source tree? Yes and no. Programs built by a user in his/her home directory and executed only by that user can use some tricks to get around system-wide policy (see below). This is safe because any damage from an exploit is confined to the user's own files. The situation I have to deal with as the maintainer of the gcl package for Fedora is that the binaries are installed in /usr/bin, and have to work for all users. Package maintainers like me need some way to affect system-wide SELinux policy for gcl and any programs built by gcl. One way to do that is to tell sysadmins that they need to do this (untested): setsebool -P deny_execmem=0 - OR - setsebool -P allow_execmem=1 depending on which boolean is provided. But that will allow ALL programs, not just those related to gcl, to mark memory as executable. (Fedora actually defaults to allowing execmem, at the moment. But since sysadmins can change that, I ship SELinux policy to allow gcl to run in either case.) The policy files I provided allow a sysadmin to specify that executables marked with the SELinux type gcl_exec_t are allowed the execmem permission, and specifies that gcl and maxima both be so marked. If I'm building gcl in my home directory, for just my personal use, on the other hand, I may have other options. If my sysadmin has set policy that allows some program, ANY program, to run with execmem permission, I can hijack the corresponding type for my own purposes. For example, if I know that lpr_exec_t provides execmem permission (I don't, by the way), then I can either run my gcl-built programs in one-shot mode like this: runcon -t lpr_exec_t my_personal_gcl_program or if I intend to keep an executable around for awhile, I can permanently mark it, like so: chcon -t lpr_exec_t my_personal_gcl_program I do understand how the personality bit bypasses policy, but it seems this was what was intended in supporting 'legacy' applications, and gcl's approach certainly pertains to the traditional unix memory management model. Yes, but it appears that the SELinux Powers That Be have decided that READ_IMPLIES_EXEC is a security hole, and plan to close it. It appears that all this obstruction is simply seeking assurance that code has no predictable address relationship with data. I'm wondering how much randomness is required, and if gcl could not simply randomly offset code when loading and satisfy all these concerns, and then be left alone :-). Try running that by the SELinux folks and see what they say. :-) By the way, I am not in any imaginable way an expert on SELinux, so take all of the foregoing with a grain of salt. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] Unrelocated symbol: __aeabi_unwind_cpp_pr1
Hi, I attempted to build gcl 2.6.11 for Fedora tonight. The builds for i386 and x86_64 seem fine, but the 32-bit ARM build failed, like so: Finished compiling /builddir/build/BUILD/gcl/unixport/../pcl/gcl_pcl_pkg.o. Loading binary of GCL_PCL_PKG... Loading /builddir/build/BUILD/gcl/unixport/../pcl/gcl_pcl_pkg.o Error: The assertion !fprintf(stderr,Unrelocated non-local symbol: %s\n,st1+sym-st_name) on line 236 of sfaslelf.c in function relocate_symbols failed Fast links are on: do (si::use-fast-links nil) for debugging Error signalled by OR. Broken at OR. Type :H for Help. Unrelocated non-local symbol: __aeabi_unwind_cpp_pr1 makefile:34: recipe for target 'gcl_pcl_boot.c' failed make[1]: Leaving directory '/builddir/build/BUILD/gcl/pcl' make[1]: *** [gcl_pcl_boot.c] Error 255 makefile:83: recipe for target 'unixport/saved_pcl_gcl' failed make: *** [unixport/saved_pcl_gcl] Error 2 A little web searching revealed that the symbol __aeabi_unwind_cpp_pr1 is defined in libgcc. It is one of the exception handling personality routines, and has reloc type R_ARM_NONE. What does this assertion failure imply, and what can I do to fix it? Thank you, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unrelocated symbol: __aeabi_unwind_cpp_pr1
On Tue, Sep 9, 2014 at 2:03 AM, Will Newton will.new...@linaro.org wrote: It's possible that this patch might fix it: http://lists.gnu.org/archive/html/gcl-devel/2014-07/msg00030.html Unfortunately, no, the build failed in exactly the same way after applying that patch. On the other hand, I do not see the string -shared-libgcc anywhere in the build log. Is it only passed in places where it would not be visible to the build log? Although the R_ARM_NONE reloc type sounds like maybe we should just ignore it (could be a linker bug?). I am open to suggestions. :-) Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unrelocated symbol: __aeabi_unwind_cpp_pr1
On Tue, Sep 9, 2014 at 9:09 AM, Camm Maguire c...@maguirefamily.org wrote: In truth, I am not sure if this work around is relying on an artifact of ld, but nevertheless, the latter is currently writing the needed symbols when thus invoked. If you modify configure.in to add TLIBS=$TLIBS -lgcc_s; for your machine and run autoconf, that should do it. Sadly, that didn't work either. Alternatively, you could edit the function use_symbols in sfasli.c and put in dummy calls to the functions you need. I will try this next. -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unrelocated symbol: __aeabi_unwind_cpp_pr1
On Tue, Sep 9, 2014 at 10:01 AM, Jerry James loganje...@gmail.com wrote: On Tue, Sep 9, 2014 at 9:09 AM, Camm Maguire c...@maguirefamily.org wrote: Alternatively, you could edit the function use_symbols in sfasli.c and put in dummy calls to the functions you need. I will try this next. That didn't work either. Still the same complaint. (Unless I'm an idiot and am not applying these patches correctly, but I'm so paranoid about that that I've checked it several times.) -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unrelocated symbol: __aeabi_unwind_cpp_pr1
On Tue, Sep 9, 2014 at 11:42 AM, Camm Maguire c...@maguirefamily.org wrote: Can you please post nm o/sfasl.o |grep __aeabi_unwind_cpp_pr1 Oh, wait! I didn't notice that the previous recipe (calling the function from use_symbols) *worked*, and it is now complaining about __aeabi_unwind_cpp_pr0. That is, it's a different symbol, ending with a zero instead of a 1 now. Sorry about that. Okay, I will now add a call to __aeabi_unwind_cpp_pr0 as well and we'll see if it wants anything else. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unrelocated symbol: __aeabi_unwind_cpp_pr1
On Tue, Sep 9, 2014 at 1:36 PM, Jerry James loganje...@gmail.com wrote:
Oh, wait! I didn't notice that the previous recipe (calling the
function from use_symbols) *worked*, and it is now complaining about
__aeabi_unwind_cpp_pr0. That is, it's a different symbol, ending with
a zero instead of a 1 now. Sorry about that. Okay, I will now add a
call to __aeabi_unwind_cpp_pr0 as well and we'll see if it wants
anything else.
I don't know why the TLDFLAGS and TLIBS approaches did not work, but
this patch led to a successful build:
--- o/sfasli.c.orig 2014-09-06 09:45:30.0 -0600
+++ o/sfasli.c 2014-09-09 12:00:00.0 -0600
@@ -133,6 +133,11 @@ extern int __remqu();
#ifndef DARWIN
#ifndef _WIN32
+#if defined(__arm__) !defined(__aarch64__)
+extern void __aeabi_unwind_cpp_pr0(void);
+extern void __aeabi_unwind_cpp_pr1(void);
+#endif
+
int
use_symbols(double d,...) {
@@ -141,6 +146,10 @@ use_symbols(double d,...) {
#ifdef GCL_GPROF
_mcount();
#endif
+#if defined(__arm__) !defined(__aarch64__)
+ __aeabi_unwind_cpp_pr0();
+ __aeabi_unwind_cpp_pr1();
+#endif
return (int)d;
Now to try building on aarch64 and see what happens.
--
Jerry James
http://www.jamezone.org/
___
Gcl-devel mailing list
Gcl-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unrelocated symbol: __aeabi_unwind_cpp_pr1
On Wed, Sep 10, 2014 at 10:26 AM, Camm Maguire c...@maguirefamily.org wrote: Greetings! 1) So I take it you also tried Will Newton's shared-libgcc to no avail? Yes, I tried that approach, and it did not improve the situation. 2) Do you know why this arm is different from Debian's armel and armhf? No. :-( Perhaps it is the toolchain versions? I did this build on Fedora Rawhide, which is currently using gcc 4.9.1 and binutils 2.24. 3) Do you know what the symbols do, or what compiled code pulls them in? They have something to do with the stack unwinding and backtrace printing code. I'm afraid that I don't know a lot about the ARM platform. 4) Is this specific to some Fedora gcc compile flag? Maybe. I used to block -fstack-protector from being used, because it caused the build to fail. However, I read that you had done some work to make that flag safe to use, so I stopped blocking it. It is possible that that has something to do with this problem. The Fedora-specific CFLAGS in use are: -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -fno-omit-frame-pointer -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard Maybe -fexceptions is responsible? Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Support for little-endian ppc64
On Tue, Sep 23, 2014 at 1:09 PM, Camm Maguire c...@maguirefamily.org wrote: Greetings, and thanks for your work on this and reports! There is a proto Debian ppc64le port in unstable which builds axiom, hol88, and acl2. There are gcc compiler bugs preventing a maxima testsuite pass. I am in dialogue with the gcc maintainers, and am filing bugs, but if you want to do it, please feel free to take over! I don't actually know much about the powerpc architecture. I'm just the hapless package maintainer who gets bug reports from Fedora's secondary arch teams. :-) I think we'll all be better off if you continue to drive things. I will look at/apply your reloc patches -- thanks! I think the patch isn't quite right, because ... I suspect selinux chcon settings on the mprotect failure. ... SELinux is turned off on the koji builders, precisely because there are a number of packages that cannot be built successfully with SELinux protection on. Since we appear to be getting EACCES from mprotect(), that means that the target address isn't right. I will try to gather more data. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Support for little-endian ppc64
On Tue, Sep 23, 2014 at 5:50 PM, Camm Maguire c...@maguirefamily.org wrote: Greetings, and thanks so much! Does this work? + store_val(where,MASK(32),(s+a-p)); I should have mentioned that I tried that. It failed in the same way as ~0L (on big-endian ppc64; little endian worked with both). Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] The perils of gcc 5.x
Greetings, Fedora is now building packages with gcc 5.x. The gcl package build for Fedora Rawhide (the upcoming Fedora 23 release) is failing with gcc 5.1.1. Part of the reason is that gcc now defaults to the C11 standard when building C code. This breaks the gcl build, because the inline keyword now defaults to meaning static inline, where it used to default to meaning extern inline. This leads to lots of duplicate symbols AND lots of missing symbols at link time. I added -std=gnu89 to CFLAGS to fix that problem, but the build is still failing, like so: make[1]: Entering directory '/builddir/build/BUILD/gcl/lsp' ../unixport/saved_pre_gcl ../unixport -system-p -c-file -data-file -h-file -compile gcl_sharp Compiling gcl_sharp.lsp. Loading ./gcl_cmpinit.lsp Finished loading ./gcl_cmpinit.lsp End of Pass 1. End of Pass 2. In file included from gcl_sharp.c:2:0: /builddir/build/BUILD/gcl/unixport/../h/cmpinclude.h:32:6: error: is not a valid filename # 34 stdin 3 4 ^ ... So somewhere the preprocessor is getting invoked and needs the -P flag to suppress those line numbers, I guess. I'm not sure where to look. Any suggestions would be greatly appreciated. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] configure error and warnings
On Wed, Jul 22, 2015 at 4:56 AM, Blake McBride bl...@mcbride.name wrote: # ./configure --enable-ansi xx ./configure: line 8423: test: 29: unary operator expected configure: WARNING: asm/signal.h: present but cannot be compiled configure: WARNING: asm/signal.h: check for missing prerequisite headers? configure: WARNING: asm/signal.h: see the Autoconf documentation configure: WARNING: asm/signal.h: section Present But Cannot Be Compiled configure: WARNING: asm/signal.h: proceeding with the compiler's result I'm attaching the patch we use in Fedora to work around the asm/signal.h issue. HTH. Regards, -- Jerry James http://www.jamezone.org/ --- configure.in.orig 2014-09-06 20:00:00.0 -0600 +++ configure.in 2014-09-06 20:00:00.0 -0600 @@ -2490,7 +2490,7 @@ #if test $use = 386-linux ; then AC_CHECK_HEADERS(asm/sigcontext.h) - AC_CHECK_HEADERS(asm/signal.h) + AC_CHECK_HEADERS(asm/signal.h, [], [], [#define __ASSEMBLY__]) AC_MSG_CHECKING([for sigcontext]) AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ #include signal.h @@ -2515,6 +2515,7 @@ #include asm/sigcontext.h #endif #ifdef HAVE_ASM_SIGNAL_H + #define __ASSEMBLY__ #include asm/signal.h #endif ]], --- configure.orig 2014-09-06 20:00:00.0 -0600 +++ configure 2014-09-06 20:00:00.0 -0600 @@ -9573,7 +9573,8 @@ for ac_header in asm/signal.h do : - ac_fn_c_check_header_mongrel $LINENO asm/signal.h ac_cv_header_asm_signal_h $ac_includes_default + ac_fn_c_check_header_compile $LINENO asm/signal.h ac_cv_header_asm_signal_h #define __ASSEMBLY__ + if test x$ac_cv_header_asm_signal_h = xyes; then : cat confdefs.h _ACEOF #define HAVE_ASM_SIGNAL_H 1 @@ -9627,6 +9628,7 @@ #include asm/sigcontext.h #endif #ifdef HAVE_ASM_SIGNAL_H + #define __ASSEMBLY__ #include asm/signal.h #endif ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Failed building gcl-2.6.9 on NIX using gcc 6.3.0 on x86-64
On Wed, Feb 21, 2018 at 11:33 PM, George Gaarder <2672286...@qq.com> wrote: > I ran `./configure; make` and got thousands of `multiple definition of` > error lines. Here is the full terminal session, including configure output: > https://paste.ubuntu.com/p/qnwnPjrY7d/ where you can see the errors from > line 1868 on. The semantics of 'inline' changed. You need to add "-std=gnu89" to your CFLAGS, since that version of gcc defaults to a later C standard. Also, if you plan to use SGC, you will also need to add "-fno-omit-frame-pointer" to CFLAGS, since that version of gcc defaults to omitting the frame pointer. Lessons learned while building gcl for Fedora. :-) > Besides, I have another question: At the beginning I used `make -j` to speed > up and seems it makes `make` failed. Why? Yes, I've had -j disabled for the Fedora build for a long time. I don't know how to fix it. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Reloc type R_X86_64_PLT32
On Tue, Jul 24, 2018 at 3:56 PM Camm Maguire wrote: > Greetings! Committed this to Version_2_6_13pre: Thanks again, Camm. Your speed is much appreciated. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Reloc type R_X86_64_PLT32
On Mon, Jul 23, 2018 at 4:11 PM Camm Maguire wrote: > Greetings, and thanks so much for bringing this to my attention! I have > reproduced the problem and will be committing a fix shortly. That's great! Thank you very much for the quick fix. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] Reloc type R_X86_64_PLT32
Hi Camm, Fedora just did a mass rebuild of all packages in preparation for Fedora 29. The gcl package failed to build, because unexpected reloc type R_X86_64_PLT32 was encountered in the relocate function of sfaslelf.c. The first symbol encountered with this reloc type is Lshadowing_import, although with readelf I can see that lots of symbols in package.o have that reloc type. The build was performed with: - binutils 2.31.2 - gcc 8.1.1 - glibc 2.27.9000 (pre-2.28) The exact same sources build without that reloc type on Fedora 28, which has: - binutils 2.29.1 - gcc 8.1.1 - glibc 2.27 Does this indicate a bug in the newer binutils? Is it reasonable that this reloc type should show up? Any advice you can give is much appreciated. Thank you, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unknown reloc type on ppc64
On Thu, May 9, 2019 at 8:08 PM Jerry James wrote: > I don't have administrative access to any ppc64le hardware. Is there > some other way I can be of help? I poked a little at this tonight. The unknown relocation type, plus 3 more which I will describe below, shows up while processing pcl/gcl_pcl_pkg.o. Here are some of the entries in .rela.text, as shown by readelf: Offset Info Type Symbol's Value Symbol's Name + Addend 003e00fc R_PPC64_REL16_HA .TOC. + 0 0004 003e00fa R_PPC64_REL16_LO .TOC. + 4 0024 00180032 R_PPC64_TOC16_HA .toc + 0 0028 00180040 R_PPC64_TOC16_LO_DS .toc + 0 002c 00180032 R_PPC64_TOC16_HA .toc + 8 0030 00180040 R_PPC64_TOC16_LO_DS .toc + 8 0050 00030032 R_PPC64_TOC16_HA .data + 10 0054 00030040 R_PPC64_TOC16_LO_DS .data + 10 0058 00180032 R_PPC64_TOC16_HA .toc + 10 005c 00180040 R_PPC64_TOC16_LO_DS .toc + 10 0060 00030032 R_PPC64_TOC16_HA .data + 18 0064 00030040 R_PPC64_TOC16_LO_DS .data + 18 00b0 00030032 R_PPC64_TOC16_HA .data + 20 00b4 00030040 R_PPC64_TOC16_LO_DS .data + 20 00c8 003f001f R_PPC64_PLT16_HA make_cons + 0 00e4 003f003c R_PPC64_PLT16_LO_DS make_cons + 0 00e8 003f0077 R_PPC64_PLTSEQ make_cons + 0 00ec 003f0078 R_PPC64_PLTCALL make_cons + 0 00f4 00030032 R_PPC64_TOC16_HA .data + 0 00fc 00180032 R_PPC64_TOC16_HA .toc + 18 0100 00180040 R_PPC64_TOC16_LO_DS .toc + 18 0108 00030030 R_PPC64_TOC16_LO .data + 0 0110 003f0078 R_PPC64_PLTCALL make_cons + 0 0120 0040001f R_PPC64_PLT16_HA symbol_name + 0 0128 0040003c R_PPC64_PLT16_LO_DS symbol_name + 0 012c 00400077 R_PPC64_PLTSEQ symbol_name + 0 0130 00400078 R_PPC64_PLTCALL symbol_name + 0 0144 0041001f R_PPC64_PLT16_HA Lintern + 0 0148 0041003c R_PPC64_PLT16_LO_DS Lintern + 0 0150 00410077 R_PPC64_PLTSEQ Lintern + 0 0158 00410078 R_PPC64_PLTCALL Lintern + 0 0174 003f001f R_PPC64_PLT16_HA make_cons + 0 0180 003f003c R_PPC64_PLT16_LO_DS make_cons + 0 0188 003f0077 R_PPC64_PLTSEQ make_cons + 0 We see the following unhandled relocation types: - 31 == R_PPC64_PLT16_HA - 60 == R_PPC64_PLT16_LO_DS - 119 == R_PPC64_PLTSEQ - 120 == R_PPC64_PLTCALL This seems to be the relevant patch series: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01078.html https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01079.html https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01080.html https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01081.html https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01082.html https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01083.html And this link may also be helpful: https://patches-gcc.linaro.org/patch/3512/ Let me know how else I can be of assistance. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unknown reloc type on ppc64
On Thu, May 9, 2019 at 9:16 AM Camm Maguire wrote: > Greetings! I only have access to a ppc64le machine (i.e. no function > descriptors) at gcc 8.3, with no gcc-9 packages yet in sid. Might you > provide access to the setup? I'm afraid that the only ppc64le machines I have access to are Fedora's build machines, and these test instances provided for the use of packagers: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers I don't have administrative access to any ppc64le hardware. Is there some other way I can be of help? -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
[Gcl-devel] Unknown reloc type on ppc64
Hi Camm, My latest attempt to build gcl for Fedora, with the upcoming gcc 9, failed on ppc64 due to unknown reloc type 31, which appears to be R_PPC64_PLT16_HA. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unknown reloc type on ppc64
On Sat, Jul 13, 2019 at 1:23 PM Camm Maguire wrote: > Greetings, and thanks for the heads up! I did try reproducing but the > Debian porterboxes did not seem to have this gcc version yet. I will > get to it. No rush. I have an acceptable workaround for now. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unknown reloc type on ppc64
On Mon, Jun 24, 2019 at 8:43 PM Jerry James wrote: > We see the following unhandled relocation types: > - 31 == R_PPC64_PLT16_HA > - 60 == R_PPC64_PLT16_LO_DS > - 119 == R_PPC64_PLTSEQ > - 120 == R_PPC64_PLTCALL I have discovered that passing -mno-pltseq to gcc prevents these relocation types from being generated. I will build the Fedora packages with this flag for now. Regards, -- Jerry James http://www.jamezone.org/ ___ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
Re: [Gcl-devel] Unknown reloc type on ppc64
On Fri, Sep 13, 2019 at 8:53 AM Camm Maguire wrote: > Greetings! Might you please post objdump -h, -t, -r, and -d on > gcl_pcl_pkg.o when you get a chance? Sure, it is attached. -- Jerry James http://www.jamezone.org/ $ objdump -h gcl_pcl_pkg.o gcl_pcl_pkg.o: file format elf64-powerpcle Sections: Idx Name Size VMA LMA File off Algn 0 .group0014 0040 2**2 CONTENTS, READONLY, GROUP 1 .group0014 0054 2**2 CONTENTS, READONLY, GROUP 2 .group0014 0068 2**2 CONTENTS, READONLY, GROUP 3 .group0014 007c 2**2 CONTENTS, READONLY, GROUP 4 .text 049c 0090 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 5 .data 0038 0530 2**3 CONTENTS, ALLOC, LOAD, RELOC, DATA 6 .bss 0568 2**0 ALLOC 7 .gnu.build.attributes 0214 0568 2**2 CONTENTS, RELOC, READONLY 8 .text.hot 077c 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 9 .gnu.build.attributes.hot 0028 077c 2**2 CONTENTS, RELOC, READONLY 10 .gnu.build.attributes.hot 012c 07a4 2**2 CONTENTS, READONLY 11 .text.unlikely 08d0 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 12 .gnu.build.attributes.unlikely 0028 08d0 2**2 CONTENTS, RELOC, READONLY 13 .gnu.build.attributes.unlikely 012c 08f8 2**2 CONTENTS, READONLY 14 .text.startup 0a24 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 15 .gnu.build.attributes.startup 0028 0a24 2**2 CONTENTS, RELOC, READONLY 16 .gnu.build.attributes.startup 012c 0a4c 2**2 CONTENTS, READONLY 17 .text.exit 0b78 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 18 .gnu.build.attributes.exit 0028 0b78 2**2 CONTENTS, RELOC, READONLY 19 .gnu.build.attributes.exit 012c 0ba0 2**2 CONTENTS, READONLY 20 .toc 0038 0cd0 2**3 CONTENTS, ALLOC, LOAD, RELOC, DATA 21 .debug_info 26a4 0d08 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 22 .debug_abbrev 0383 33ac 2**0 CONTENTS, READONLY, DEBUGGING 23 .debug_loc048e 372f 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 24 .debug_aranges 0030 3bbd 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 25 .debug_ranges 0180 3bed 2**0 CONTENTS, READONLY, DEBUGGING 26 .debug_line 0344 3d6d 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 27 .debug_str0d3c 40b1 2**0 CONTENTS, READONLY, DEBUGGING 28 .comment 002d 4ded 2**0 CONTENTS, READONLY 29 .text.unlikely 4e1a 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 30 .text.unlikely 4e1a 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 31 .text.unlikely 4e1a 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 32 .text.hot 4e1a 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 33 .text.hot 4e1a 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 34 .text.unlikely 4e1a 2**0 CONTENTS, ALLOC, LOAD, READONLY, CO
Re: [Gcl-devel] Unknown reloc type on ppc64
On Sun, Dec 8, 2019 at 12:41 PM Camm Maguire wrote: > Greetings! Just a heads up that I've released a fix for this and am > running it through its paces now. That's great! Thank you. > Similar reloc support is needed for the big-endian ppc64, but I no > longer have access to any such machine for debugging, so have added > -mno-pltseq to the flags there. If anyone wants to help with support > here please let me know. Fedora no longer supports big endian ppc64, so I can't help you there, I'm afraid. I have no access to such hardware either. -- Jerry James http://www.jamezone.org/
Re: GCC 10 issues
On Fri, Feb 21, 2020 at 12:16 PM Camm Maguire wrote: > Greetings! I've committed a fix for these to the Version_2_6_13pre > branch. Thanks for your report! Please let me know if problems > persist. > I have added your patch to the gcl build for Fedora 32 and Rawhide. It built with no problems. Thank you! -- Jerry James http://www.jamezone.org/
GCC 10 issues
Hi Camm, The Fedora project is currently rebuilding all packages with what will soon be GCC 10. I have encountered two issues so far and thought I should give you a heads up. GCC has long defaulted to -fcommon, but GCC 10 flips the default to -fno-common. As a result, the link step fails with complaints about lots of multiply-defined variables. A quick workaround is to add -fcommon to the build flags. Otherwise, the code would have to be altered to ensure that there is exactly one compilation unit containing a definition for each variable. After adding -fcommon, the build still fails like this: COMPILER> Error: ERROR "Caught fatal error [memory may be damaged]" Signalled by EQUAL-TAIL-RECURSION-CHECK. ERROR "Caught fatal error [memory may be damaged]" Broken at SYSTEM::DO-BREAK-LEVEL. Type :H for Help. 1 Return to top level. COMPILER>>2148155904 heap words available NIL COMPILER>> NIL COMPILER>>make[1]: *** [makefile:98: saved_pre_gcl] Error 255 Here is a disassembly of cclear_stack on an x86_64 machine: 5370 : 5370: f3 0f 1e fa endbr64 5374: 31 c0 xor%eax,%eax 5376: c3 retq GCC 10 has concluded that it can optimize cclear_stack away, as that simply returns 0. GCC may feel it is justified in doing so because of this warning: main.c: In function 'cclear_stack': main.c:454:10: warning: function returns address of local variable [ ]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wreturn-local-addr -Wreturn-local-addr ]8;; ] 454 | return v; | ^ In file included from /usr/include/stdlib.h:568, from main.c:27: main.c:452:11: note: declared here 452 | void *v=alloca(size); | ^~ The same thing has happened with gcl_strncpy_chk; it just returns 0. What are these functions supposed to do? EQUAL-TAIL-RECURSION-CHECK in particular, even if cclear_stack is not optimized away, touches memory it isn't allowed to touch, memory belonging to a stack frame that has been popped. A conforming compiler is allowed to generate code that segfaults (precisely what GCC 10 is doing). I should also mention this output from the configure script: checking finding default linker script... gawk: cmd. line:1: warning: regexp escape sequence `\=' is not a known regexp operator got it Perhaps all of the "\=" should be "\\="? Regards, -- Jerry James http://www.jamezone.org/
realpath can set errno on success
Hi Camm, We recently had a build failure on Fedora that was traced back to realpath() returning non-NULL AND setting errno to EINVAL. The glibc maintainers say: "In general, POSIX specifies that errno only has a valid value after an unsuccessful function call. glibc follows this policy." In particular, the mbin() function added by the Version_2_6_13pre70 patch wraps massert() around a call to realpath(). Instead, the code should check that realpath returns a non-NULL value. Regards, -- Jerry James http://www.jamezone.org/
Re: realpath can set errno on success
On Mon, Jan 18, 2021 at 2:10 PM Jerry James wrote:
> We recently had a build failure on Fedora that was traced back to
> realpath() returning non-NULL AND setting errno to EINVAL. The glibc
> maintainers say:
>
> "In general, POSIX specifies that errno only has a valid value after
> an unsuccessful function call. glibc follows this policy."
>
> In particular, the mbin() function added by the Version_2_6_13pre70
> patch wraps massert() around a call to realpath(). Instead, the code
> should check that realpath returns a non-NULL value.
I had to change several other massert() calls, all made to functions
that do not guarantee they set errno. With the attached patch, the
build passes with the latest glibc. Regards,
--
Jerry James
http://www.jamezone.org/
--- gcl/h/linux.h.orig 2021-01-18 20:07:36.072892806 -0700
+++ gcl/h/linux.h 2021-01-18 20:15:02.852982150 -0700
@@ -15,14 +15,14 @@
long offset = 0, endofelf; int j; \
ElfW(Ehdr) eheader; ElfW(Shdr) shdr; \
fseek(fp, 0, SEEK_SET); \
-massert(1==fread(, sizeof(eheader), 1, fp)); \
+assert(1==fread(, sizeof(eheader), 1, fp)); \
/* in case the headers themselves come AFTER the actual sections */ \
endofelf=offset = eheader.e_shoff+ eheader.e_shentsize *eheader.e_shnum;\
fseek(fp, eheader.e_shoff, SEEK_SET); \
if ( eheader.e_shentsize != sizeof(ElfW(Shdr)) ) \
{ FEerror("Bad ELF section header size",0); } \
for ( j = 0; j < eheader.e_shnum; j++ ) \
- { massert(1==fread(,eheader.e_shentsize,1,fp)); \
+ { assert(1==fread(,eheader.e_shentsize,1,fp)); \
if ( (shdr.sh_offset > offset) && (shdr.sh_type != SHT_NOBITS) ) \
{ offset = shdr.sh_offset; endofelf = offset+shdr.sh_size; } \
} \
@@ -134,7 +134,7 @@ do { int c = 0; \
#include
#define GET_FULL_PATH_SELF(a_) do {\
static char q[PATH_MAX]; \
-massert(which("/proc/self/exe",q) || which(argv[0],q)); \
+assert(which("/proc/self/exe",q) || which(argv[0],q)); \
(a_)=q; \
} while(0)
--- gcl/o/main.c.orig 2021-01-18 20:10:11.918575121 -0700
+++ gcl/o/main.c 2021-01-18 20:10:32.816532533 -0700
@@ -469,7 +469,7 @@ mbin(const char *s,char *o) {
struct stat ss;
if (!stat(s,) && (ss.st_mode_IFMT)==S_IFREG && !access(s,R_OK|X_OK)) {
-massert(realpath(s,o));
+assert(realpath(s,o) != NULL);
return 1;
}
@@ -485,10 +485,10 @@ which(const char *n,char *o) {
if (strchr(n,'/'))
return mbin(n,o);
- massert(snprintf(FN1,sizeof(FN1),"%s",getenv("PATH"))>1);
+ assert(snprintf(FN1,sizeof(FN1),"%s",getenv("PATH"))>1);
for (s=NULL;(s=strtok(s ? NULL : FN1,":"));) {
-massert(snprintf(FN2,sizeof(FN2),"%s/%s",s,n));
+assert(snprintf(FN2,sizeof(FN2),"%s/%s",s,n)>1);
if (mbin(FN2,o))
return 1;
Re: gcl-2.6.13 released [stable]
On Wed, Dec 21, 2022 at 10:31 AM Camm Maguire wrote: > My strong guess is that you are using gcc-12. There is a known bug > therein preventing gcl from using it until fixed. I anticipate this > won't take too long, so have not put any configure checks etc. in the > way. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023756 > > Please let me know if problems persist with gcc <= 11. You should be > able to do CC=gcc-11 ./configure when building gcl and that will > take care of it. I don't know about Gentoo, but in Fedora 36 and 37, there is no gcc 11 package. GCC 12 is all we get (currently version 12.2.1). I have discovered that adding -fno-tree-vrp to the build flags makes your example compile successfully (found by doing a binary search on the optimization flags added between -O1, where the example works, and -O2, where it does not). -- Jerry James http://www.jamezone.org/
Re: gcc-12 miscompilation
On Sat, Dec 24, 2022 at 3:27 PM Camm Maguire wrote: > Greetings, and thank you so much for pinning down the offending > optimization flag, reducing the bug report, and forwarding the response! > > I'm not convinced (yet at least) that this code being classified as > 'undefined' means gcc is not in error. Signed and unsigned integer > arithmetic of any precision is defined in C to loop around extremal > values, i.e. to act as modular operations. This code acknowledges this > and relies upon it -- runtime 'overflows' are not a mistake. Perhaps > there is some better syntax to make this clear? My understanding is that *unsigned* integer overflow is well-defined, and simply wraps around as you describe. *Signed* integer overflow, on the other hand, is undefined behavior. This article supports that view: https://en.wikipedia.org/wiki/Integer_overflow (see the section on "Inconsistent behavior"). This also means that, while -fno-tree-vrp may cause the symptoms to disappear, the correct flag to use is -fwrapv. Better would be to make sure that overflow only happens for unsigned integer operations. Regards, -- Jerry James http://www.jamezone.org/
Re: gcl-2.6.13 released [stable]
On Wed, Dec 21, 2022 at 8:22 AM Camm Maguire wrote: > Greetings! Yes, the upload still seems stuck in the ftp-upload queue, > but all feedback thus far indicates a successful installation: > > https://lists.gnu.org/archive/html/ftp-upload-report/2022-12/msg00062.html > > I'm hoping it appears in a few days, but in the meantime you can > checkout tag Version_2_6_13 from git. Please let me know if problems > persist. Something seems wrong. The gcl-2.6.13 tarball still doesn't appear at gnu.org, but files uploaded after it have appeared (tramp-2.6.0.tar.gz and ncurses-6.4.tar.gz, for example). -- Jerry James http://www.jamezone.org/
Re: gcl-2.6.13 released [stable]
On Fri, Dec 23, 2022 at 8:44 AM Jerry James wrote: > I have discovered that adding -fno-tree-vrp to the build flags makes > your example compile successfully (found by doing a binary search on > the optimization flags added between -O1, where the example works, and > -O2, where it does not). I was able to reduce your test code, Camm, and have filed https://bugzilla.redhat.com/show_bug.cgi?id=2156088. I am now going to vanish for the rest of the year, but will have sporadic email access. Regards, -- Jerry James http://www.jamezone.org/
Re: gcl-2.6.13 released [stable]
On Fri, Dec 23, 2022 at 1:55 PM Jerry James wrote: > I was able to reduce your test code, Camm, and have filed > https://bugzilla.redhat.com/show_bug.cgi?id=2156088. I am now going > to vanish for the rest of the year, but will have sporadic email > access. I haven't quite vanished yet, and I already got a reply on that bug. The code invokes undefined behavior. Add -fsanitize=undefined to the build flags and you will see: $ ./t -887426961747968 t.c:50:16: runtime error: signed integer overflow: 887426961747968 + 2305843009213693952 cannot be represented in type 'long int' make 0x404140 -- Jerry James http://www.jamezone.org/
unrandomize issue with glibc 2.36.9000 and _FORTIFY_SOURCE
A new snapshot of the upcoming glibc 2.37 (called 2.36.9000) has
landed in Fedora, and now gcl 2.6.14 does this while running
configure:
checking for personality(ADDR_NO_RANDOMIZE) support... no
checking that sbrk is (now) non-random... no
Cannot build with randomized sbrk. Your options:
- upgrade to a kernel/libc that knows about personality(ADDR_NO_RANDOMIZE)
- recompile your kernel with CONFIG_COMPAT_BRK (if it has that option)
- run sysctl kernel.randomize_va_space=0 before using gcl
configure: error: exiting
And config.log is full of errors:
configure:8097: checking for personality(ADDR_NO_RANDOMIZE) support
configure:8117: gcc -o conftest -O2 -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fsigned-char
-pipe -fcommon -fno-builtin-malloc -fno-builtin-free -fno-PIE -fno-pie
-fno-PIC -fno-pic -Wall -Wno-empty-body -Wno-unused-but-set-variable
-I/usr/include/tirpc -Wl,-z,relro -Wl,--as-needed
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1
-no-pie conftest.c >&5
In file included from /usr/include/unistd.h:1214,
from h/unrandomize.h:4,
from conftest.c:64:
/usr/include/bits/unistd.h: In function 'main':
/usr/include/bits/unistd.h:36:1: error: nested function 'read' declared 'extern'
36 | read (int __fd, void *__buf, size_t __nbytes)
| ^~~~
/usr/include/bits/unistd.h:36:1: error: static declaration of 'read'
follows non-static declaration
/usr/include/unistd.h:371:16: note: previous declaration of 'read'
with type 'ssize_t(int, void *, size_t)' {aka 'long int(int, void *,
long unsigned int)'}
371 | extern ssize_t read (int __fd, void *__buf, size_t __nbytes) __wur
|^~~~
/usr/include/bits/unistd.h:72:1: error: nested function 'pread'
declared 'extern'
72 | pread (int __fd, void *__buf, size_t __nbytes, __off_t __offset)
| ^
/usr/include/bits/unistd.h:72:1: error: static declaration of 'pread'
follows non-static declaration
/usr/include/unistd.h:389:16: note: previous declaration of 'pread'
with type 'ssize_t(int, void *, size_t, __off_t)' {aka 'long
int(int, void *, long unsigned int, long int)'}
389 | extern ssize_t pread (int __fd, void *__buf, size_t __nbytes,
|^
/usr/include/bits/unistd.h:90:1: error: nested function 'pread64'
declared 'extern'
90 | pread64 (int __fd, void *__buf, size_t __nbytes, __off64_t __offset)
| ^~~
/usr/include/bits/unistd.h:90:1: error: static declaration of
'pread64' follows non-static declaration
/usr/include/unistd.h:422:16: note: previous declaration of 'pread64'
with type 'ssize_t(int, void *, size_t, __off64_t)' {aka 'long
int(int, void *, long unsigned int, long int)'}
422 | extern ssize_t pread64 (int __fd, void *__buf, size_t __nbytes,
|^~~
In file included from /usr/include/features.h:490,
from /usr/include/bits/libc-header-start.h:33,
from /usr/include/stdio.h:27,
from conftest.c:61:
/usr/include/bits/unistd.h:116:1: error: nested function 'readlink'
declared 'extern'
116 | __NTH (readlink (const char *__restrict __path, char *__restrict __buf,
| ^
/usr/include/bits/unistd.h:116:1: error: static declaration of
'readlink' follows non-static declaration
/usr/include/unistd.h:838:16: note: previous declaration of 'readlink'
with type 'ssize_t(const char * restrict, char * restrict, size_t)'
{aka 'long int(const char * restrict, char * restrict, long unsigned
int)'}
838 | extern ssize_t readlink (const char *__restrict __path,
and so on. The problem is h/unrandomize.h, which starts with #include
directives, then has code meant to be embedded in a function.
Apparently the combination of that with -O2 and
-Wp,-D_FORTIFY_SOURCE=3 (or 2) leads to the errors above. Here is the
definition of read from /usr/include/bits/unistd.h, for example:
__fortify_function __wur ssize_t
read (int __fd, void *__buf, size_t __nbytes)
{
return __glibc_fortify (read, __nbytes, sizeof (char),
__glibc_objsize0 (__buf),
__fd, __buf, __nbytes);
}
I don't know offhand where or how __fortify_function or
__glibc_fortify are defined, but note the "nested function" parts of
the errors above. That read() function is a full definition, so when
it appears inside a function body, that makes it a nested function,
which makes it fail to match the unfortified function declaration.
The attached patch may not be optimal, but seems to solve this
problem. Then the GCC 13 prerelease version we are using seems to be
causing another problem that I haven't had time to diagnose yet. More
on that later.
--
Jerry James
http://www.jame
