Bug#151886: [Gcl-devel] Re: gcl/maxima on hppa

[Camm Maguire]

Greetings!  I'm pleased to announce that gcl/maxima is now supported
in hppa, the last of the 11 Debian architectures.  The issues were/are
with gcc on this platform, and were masked somewhat by my not setting
up gcl's internal compile flags correctly.

1) When compiling with -g, the final link fails, and explicitly asks
   for recompilation with -ffunction-sections.  This works, and
   produces a maxima passing all tests.

2) Any optimization at all breaks the build.  I have a gdb
   session/backtrace showing pointers not being passed correctly into
   functions if anyone is interested in looking into this.

3) I'm hoping some of these symptoms might ring a bell with
   knowledgeable hppa people, and that there may be some other
   combination of compliation flags which might enable optimization. 


Take care,

[EMAIL PROTECTED] (LaMont Jones) writes:

> On Fri, Sep 13, 2002 at 10:17:04AM -0400, Camm Maguire wrote:
> > Greetings!  I think I may have stumbled on a possible explanation for
> > gcl's build failure on hppa.  Hppa alone will not relocate (i.e. allow
> > dlopen to open) modules not compiled with -fPIC.  All other
> > architectures on which dlopen is currently used (alpha, ia64, mips,
> > mipsel)
> 
> Actually, mips and mipsel force -fPIC on all compiles.  The spec requires
> that shared objects be built with -fPIC.
> 
> > 1) gcl can also relocate and load objects via a direct call to the BFD
> >library routine bfd_get_relocated_section_contents.  This method is
> >currently used as the default on i386, sparc, ppc, s390, m68k and
> >arm.  It is not yet fully implemented on hppa.  Completing this
> >routine should enable a fully functional gcl, maxima, and in the
> >hopefully near future acl2 on this platform.
> 
> Cool.
> 
> > 2) Find a way to load objects with dlopen without -fPIC.  Attempting
> >this results in the error that a certain relocation output by the
> >compiler cannot be handled by dlopen.  Perhaps there is some other
> >gcc compiler option short of the full -fPIC which can avoid this
> >relocation?
> 
> Nope.  The non-PIC is truly not position independent.
> 
> > In either case, I will need a knowledgeable hppa person to advise,
> > discuss and help generate patches for this to get fixed any time soon.
> > Gcl can build its own bfd library, so patches here can be simply
> > incorporated.
> 
> willy would be a good target.  I'm going to be out of town for a couple
> of weeks, but (if it's still pending) I'd be happy to help when I get
> back.
> 
> lamont
> 
> 
> ___
> Gcl-devel mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

-- 
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#151886: [Gcl-devel] Re: gcl/maxima on hppa

[Randolph Chung]

> 1) When compiling with -g, the final link fails, and explicitly asks
>for recompilation with -ffunction-sections.  This works, and
>produces a maxima passing all tests.

known problem with gcc-3.0.x

> 2) Any optimization at all breaks the build.  I have a gdb
>session/backtrace showing pointers not being passed correctly into
>functions if anyone is interested in looking into this.

can you please try gcc-3.2 as well? 

good to hear you finally got it to work though :-)

randolph

Bug#151886: [Gcl-devel] Re: gcl/maxima on hppa

[Camm Maguire]

Greetings!  An update:

1) Optimization, even at -O, still fails with gcc-3.2.  I get a
   maxima, but it crashes on one of the tests. -ffunction-sections
   still in.

2) I cannot seem to get gcl's stratified garbage collection option to
   work on hppa.  This basically mprotects the core pages as
   read-only, then traps segfault signals on write attempts,
   unprotects the page and marks it for garbage collection.  The
   sigaction calls don't appear to redirect control to the handler on
   SIGSEGV, however.  This works as is on most other Debian
   platforms. 

3) I have this setup on paer, so can provide gdb dumps to anyone who
   wants to try to fix this.

4) I suppose the -ffunction-sections is still required without the -g,
   but haven't tested this.

5) Just uploaded a maxima which should build for the first time on
   hppa. 

Take care,

Randolph Chung <[EMAIL PROTECTED]> writes:

> > 1) When compiling with -g, the final link fails, and explicitly asks
> >for recompilation with -ffunction-sections.  This works, and
> >produces a maxima passing all tests.
> 
> known problem with gcc-3.0.x
> 
> > 2) Any optimization at all breaks the build.  I have a gdb
> >session/backtrace showing pointers not being passed correctly into
> >functions if anyone is interested in looking into this.
> 
> can you please try gcc-3.2 as well? 
> 
> good to hear you finally got it to work though :-)
> 
> randolph
> 
> 

-- 
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#164009: gcj-3.2: gcj-wrapper-3.2 omits input files starting with .

[Adam C Powell IV]

Package: gcj-3.2
Version: 1:3.2.1-0pre3
Severity: important
Greetings,
javac ./hello.java
fails because the script only allows a-zA-Z_/ as initial characters in 
input files.  This seems to fix it:

diff -u /usr/bin/gcj-wrapper-3.2 ./gcj-wrapper-3.2
--- /usr/bin/gcj-wrapper-3.22002-09-19 16:36:22.0 -0400
+++ ./gcj-wrapper-3.22002-10-09 16:54:05.0 -0400
@@ -66,7 +66,7 @@
-*)
;;
-[a-z0-9A-Z_/]*)
+[a-z0-9A-Z_/.]*)
break;;
esac
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!

-- System Information
Debian Release: testing/unstable
Kernel Version: Linux vaio 2.4.19-686 #1 Thu Aug 8 21:30:09 EST 2002 
i686 unknown unknown GNU/Linux

Versions of the packages gcj-3.2 depends on:
ii  gcc-3.23.2.1-0pre3The GNU C compiler.
ii  gcc-3.2-base   3.2.1-0pre3The GNU Compiler Collection (base 
package).
ii  java-common0.16   Base of all Java packages
ii  libc6  2.2.5-15   GNU C Library: Shared libraries and 
Timezone
ii  libgcc13.2.1-0pre3GCC support library.
ii  libgcj33.2.1-0pre3Java runtime library for use with gcj
ii  libgcj3-dev3.2.1-0pre3Java development headers and static 
library
ii  zlib1g 1.1.4-4compression library - runtime

Bug#159838: c/7853: gcc reports multiple symbol definitions on the wrong line

[ljrittle]

Synopsis: gcc reports multiple symbol definitions on the wrong line

State-Changed-From-To: open->closed
State-Changed-By: ljrittle
State-Changed-When: Wed Oct  9 15:31:26 2002
State-Changed-Why:
Fixed on mainline according to Peter Schmid.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7853

bison 1.50-1

[Jack Howarth]

Matthias,
You might want to do a test build of gcc-3.2.1 against the new
bison 1.50-1. I have found that this new bison breaks the binutils
build. Not sure yet if this is a bison bug or a flaw in the binutils
build process. Hopefully not that may packages will be bit by this.
Regressing to bison 1.35-3 eliminates this problem in the build.
Jack
-
/bin/sh ../../ld/../ylwrap "bison -y" ../../ld/ldgram.y y.tab.c ldgram.c 
y.tab.h ldgram.h --  -d
/home/howarth/debian-binutils/binutils-2.13.90.0.8/build-tree/binutils-2.13.90.0.8/builddir-single/ld/../../ld/ldgram.y:629.12-632.35:
 type clash (`' `name') on default action
/home/howarth/debian-binutils/binutils-2.13.90.0.8/build-tree/binutils-2.13.90.0.8/builddir-single/ld/../../ld/ldgram.y:831.8-847.11:
 type clash (`' `name') on default action
make[3]: *** [ldgram.c] Error 1
make[3]: Leaving directory 
`/home/howarth/debian-binutils/binutils-2.13.90.0.8/build-tree/binutils-2.13.90.0.8/builddir-single/ld'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory 
`/home/howarth/debian-binutils/binutils-2.13.90.0.8/build-tree/binutils-2.13.90.0.8/builddir-single/ld'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory 
`/home/howarth/debian-binutils/binutils-2.13.90.0.8/build-tree/binutils-2.13.90.0.8/builddir-single/ld'
make: *** [all-ld] Error 2
bogus:/home/howarth/debian-binutils/binutils-2.13.90.0.8/build-tree/binutils-2.13.90.0.8/builddir-single#
 
--~v

Bug#159838: c/7853: gcc reports multiple symbol definitions on the wrong line

[ljrittle]

Synopsis: gcc reports multiple symbol definitions on the wrong line

State-Changed-From-To: closed->open
State-Changed-By: ljrittle
State-Changed-When: Wed Oct  9 18:25:47 2002
State-Changed-Why:
Undo, not fixed yet.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7853