gmane.lisp.gcl.devel

Re: How to submit GCL patches

Gabriel Dos Reis — 2008-12-02T21:57:51

| Over the last month, I've submitted several patches to fix problems on | current Fedora systems. While a short discussion followed a couple of | the patches, largely I've been met with silence. How should I be | proceeding? Should I be submitting the patches to the Savannah patch | tracker instead of sending them to this list? I am absolutely ready | to discuss the problems these patches address, and how I came up with | the proposed solutions ... in what forum? Jerry -- First of, your patches are most welcome. This is the right place to submit contributions. While I feel confident about some of your patches, I would prefer Camm to sign off on them. Camm appears to be extremely busy these days. | | Incidentally, the "Debian package page" link on | http://www.gnu.org/software/gcl/ is broken. The trailing ".html" | should be changed to "/" to fix it. | | Also, what version of GCL should I be attempting to package for | Fedora: 2.6.7, or current CVS (which, I gather, is intended to become | 2

How to submit GCL patches

Jerry James — 2008-12-02T21:34:43

Over the last month, I've submitted several patches to fix problems on current Fedora systems. While a short discussion followed a couple of the patches, largely I've been met with silence. How should I be proceeding? Should I be submitting the patches to the Savannah patch tracker instead of sending them to this list? I am absolutely ready to discuss the problems these patches address, and how I came up with the proposed solutions ... in what forum? Incidentally, the "Debian package page" link on http://www.gnu.org/software/gcl/ is broken. The trailing ".html" should be changed to "/" to fix it. Also, what version of GCL should I be attempting to package for Fedora: 2.6.7, or current CVS (which, I gather, is intended to become 2.7.0 some day)? I've also seen mention of a "2.6.8pre". What is that? Thanks,

Re: Patch: compile with newer system BFD libraries

Jerry James — 2008-12-02T19:13:34

Don't use that patch, at least not the part that patches o/unexelf.c. The Emacs unexelf.c I used to make that is GPL v3. Here's a replacement patch that syncs up with the unexelf.c in Emacs 22.1, the last version of Emacs released under GPL v2.

Patch: LaTeX 2.09 -> 2e

Jerry James — 2008-11-26T03:25:25

This gets rid of modern LaTeX complaints about running in compatibility mode when processing xgcl-2/dwdoc.tex. There isn't anything terribly fancy in that document, so the conversion was straightforward. It consisted of the following mappings: - \documentstyle -> \documentclass - {\bf ...} -> \textbf{...} - {\tt ...} -> \texttt{...} - {\em ...} -> \emph{...} I also replaced a few length settings in the preamble with use of the geometry package.

Re: Re: Patch: adapt to newer autoconf versions

Jerry James — 2008-11-24T13:52:13

Sorry for the long delay in replying. Real Life intervened for a few days. On Fri, Nov 21, 2008 at 12:28 PM, Aleksej Saushev inbox.ru> wrote: The intent of the patch I submitted is to port the autoconf bits forward to a more recent version of autoconf, rationalizing a few things on the way. If someone would like to take the next step and test for isnormal and friends directly, that's great, but goes beyond what I intended to do.

Re: Patch: adapt to newer autoconf versions

Aleksej Saushev — 2008-11-21T19:28:33

No, it doesn't. GCL doesn't run on BSD systems, except FreeBSD when heavily patched to do so. GCL is unportable.

Re: Patch: adapt to newer autoconf versions

Gabriel Dos Reis — 2008-11-21T00:27:13

Yes, I understand that. I guess, my point is that GCL runs also on non GNU systems (e.g. *BSD, MAC, MinGW, etc), and since the problem is not GNU platform specific, I think we should test for the features themselves, e.g. isnormal, e.g., if necessary by supplying -std=c99.

Re: Patch: adapt to newer autoconf versions

Jerry James — 2008-11-21T00:17:39

On Thu, Nov 20, 2008 at 5:13 PM, Gabriel Dos Reis integrable-solutions.net> wrote: 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.

Re: Patch: adapt to newer autoconf versions

Gabriel Dos Reis — 2008-11-21T00:13:45

So, in fact, we want to check for C99 features, not GNU sources; right?

Re: Patch: adapt to newer autoconf versions

Jerry James — 2008-11-21T00:01:39

On Thu, Nov 20, 2008 at 11:49 AM, Gabriel Dos Reis integrable-solutions.net> wrote: 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.

Re: Patch: adapt to newer autoconf versions

Gabriel Dos Reis — 2008-11-20T18:49:29

Hi Jerry, Isn't _GNU_SOURCE GNU/Linux or glibc specific?

Patch: adapt to newer autoconf versions

Jerry James — 2008-11-20T16:19:18

If autoconf 2.61 is used to process the current configure.in, it produces a script containing illegal shell script syntax, causing a script failure at runtime. This is due to some obsolete autoconf usages within configure.in. This patch fully updates configure.in for use by autoconf 2.61. Let me explain a few bits of the patch. I added AC_PROG_EGREP, because AC_EGREP_HEADER (formerly AC_HEADER_EGREP) now expands to an expression that includes "$(EGREP)", which isn't set unless AC_PROG_EGREP is run. I added AC_GNU_SOURCE and a corresponding #undef in acconfig because some math functions (e.g., isnormal) aren't defined unless _GNU_SOURCE is defined. There was already a workaround in the script for this, but it broke in a couple of cases on my Fedora 9 machine. I reordered a few statements to make the "checking ..." messages and their corresponding results be on the same line. Quite a few obsolete macros were converted to their new forms. There were a number of cases of strings quoted with quote marks

Patch: compile with newer system BFD libraries

Jerry James — 2008-11-20T15:59:09

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.

Re: Patch: don't #include inside a function

Jerry James — 2008-11-20T15:54:21

Disregard that patch. It was incomplete, and is fundamentally the wrong approach anyway. Here is a patch that does it the right way. Unfortunately, regenerating configure with autoconf 2.61 after applying this patch produces a configure script that fails to execute all the way. That's due to some obsolete autoconf input in the existing configure.in script. I'll post a separate patch to fix that problem in a moment.

Re: Build trouble

Jerry James — 2008-11-12T03:45:58

On Tue, Nov 11, 2008 at 6:27 PM, Nicolas FRANCOIS free.fr> wrote: Unfortunately, that advice is both distribution- and version-specific. Both GDB and binutils use libbfd, so there are versions of both that work with GCL and versions of both that don't. (Well, I'm not sure about GDB, but if there isn't a version yet that has a GCL-breaking libbfd, there will be some day.) I'm using a Fedora 9 machine, which has binutils-2.18.50.0.6, which has the problem. I also have gdb 6.8, which is NOT linked against the system libbfd, so I assume they statically compiled in whatever version of libbfd came with that GDB version. I think I see how to fix the GCL code for the newer libbfd. Hold your breath, cross your fingers, and hope for a patch in about 12 hours. :-) Incidentally, are there any GCL developers on this list? I've been posting patches for a few days now and haven't had one say "Boo!" yet. I'd like to know if I'm wasting my time or not.

Re: Build trouble

Nicolas FRANCOIS — 2008-11-12T01:27:21

Le Tue, 11 Nov 2008 12:50:17 -0700 "Jerry James" gmail.com> a écrit : I can confirm now that the problem comes from Gdb. I recompiled binutils to repair the libraries, and reinstalled Gdb in a way that doesn't overwrite them ("make -C gdb install" at the final stage). Then Gcl compiled fine with just the --enable-ansi switch, and no mention of a particular "loader", whatever that is. I try to use Gdb as little as possible, and only when my system has a *SERIOUS* problem :-P So I think this should be added to the Gcl build doc, with the --enable-ansi remark : "If you installed Gdb in a way that overwrote the libraries installed by binutils, either reinstall binutils, or pass those switches to your configure..." That should settle a problem that seems to annoy quite a lot of people, in particular all the Gentoo team (not that I'm one of them, mind you ;-) There are a few mentions of this problem on their bug list, including one guy who says he posted a question on the Gcl list, without any

LD_COMMAND for Linux

Jerry James — 2008-11-11T22:25:55

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?

Re: Build trouble

Jerry James — 2008-11-11T19:50:17

_______________________________________________ Gcl-devel mailing list Gcl-devel< at >gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel

Re: Build trouble

Nicolas FRANCOIS — 2008-11-11T17:57:38

Le Mon, 10 Nov 2008 11:45:01 -0700 "Jerry James" gmail.com> a écrit : 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 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 ? 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 ? \bye

Re: [Maxima] Can't build Maxima because I can't buildGCL...

Alexey Beshenov — 2008-11-10T20:29:54

As for the 2.6.7 tarball: ~/gcl-2.6.7$ ./configure loading cache ./config.cache checking host system type... i686-pc-linux-gnu host=i686-pc-linux-gnu enable_machine= use=386-linux checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking how to run the C preprocessor... gcc -E checking for gawk... gawk checking system version (for dynamic loading)... checking for makeinfo... makeinfo ./configure: 1: Syntax error: Unterminated quoted string It could be corrected though: http://savannah.gnu.org/bugs/?20836 After that `./configure` faults with another problem: http://bugs.gentoo.org/show_bug.cgi?id=186926 Then I've got the latest CVS code. `make` reports a missing target "/usr/lib/libbfd.a". (It's pretty clean that I have to install libbfd-dev, but it should be correctly reported by `./configure`.) Another issue: ~/gcl$ make

Re: Build trouble

Jerry James — 2008-11-10T18:45:01

_______________________________________________ Gcl-devel mailing list Gcl-devel< at >gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel