[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Problems building gcl-2.6.1-18 on Solaris 8 (SPARC)
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] Problems building gcl-2.6.1-18 on Solaris 8 (SPARC) |
Date: |
14 Nov 2003 11:22:48 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings, and thank you *very* much for this informative reply! As
my access to our solaris autobuilding box is still down, may I suggest
the following tests:
1) Try (bye) from the raw....gcl images.
2) Put GNU ld in the path
Take care,
"MAISONOBE Luc" <address@hidden> writes:
> John Tang Boyland wrote :
> > I removed the last line of the makefile which said that saved_pcl_gcl
> > was INTERMEDIATE. Then I was able to make and then run the code that
> > crashed. It still crashes in "exit", just like before with 3.2.1:
> > whatever happened, it doesn't do better in gcc3.3! It's not exit per
> > se, it's exit after registering something as a global destructor
> > apparently). And also it doesn't happen with saved_pre_gcl or saved_gcl,
> > only with saved_pcl_gcl. My guess would that one of the .o's you load
> > puts something in the destructor list and either is buggy
> > (nonportable) or there's some bad interaction with the way images
> > are dumped.
>
> I remember having a similar problem with gcc 3.2.x some months ago
> while building emacs. The dumped emacs crashes on exit due to a
> destructor list interpreted as holding pointer that were all null. I
> filed a bug in emacs list and rms forwarded it to gcc at that
> time. Someone thought it was due to my linker and suggested me to
> switch to binutils. As this induced other problems, I finally gave
> up. My problem at this time was triggered by linking or not a third
> party library in the application (I think it was libpng, but I am not
> sure).
>
> The problem occurred despite all elements were C libraries (I think
> this destructor list is set up regardless of the language and is used
> only by some of them, Objective C and C++ probably). It should
> probably remain empty and considered as such when only C is involved,
> but it somehow corrupted during the unexec procedure.
>
> I am not able to reproduce the problem anymore with latest emacs and gcc.
>
> Luc
>
>
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- Re: [Gcl-devel] Problems building gcl-2.6.1-18 on Solaris 8 (SPARC), (continued)
- Re: [Gcl-devel] Problems building gcl-2.6.1-18 on Solaris 8 (SPARC), John Tang Boyland, 2003/11/07
- Re: [Gcl-devel] Problems building gcl-2.6.1-18 on Solaris 8 (SPARC), John Tang Boyland, 2003/11/07
- Re: [Gcl-devel] Problems building gcl-2.6.1-18 on Solaris 8 (SPARC), John Tang Boyland, 2003/11/10
- Re: [Gcl-devel] Problems building gcl-2.6.1-18 on Solaris 8 (SPARC), John Tang Boyland, 2003/11/10
- Re: [Gcl-devel] Problems building gcl-2.6.1-18 on Solaris 8 (SPARC), John Tang Boyland, 2003/11/10
- Re: [Gcl-devel] Problems building gcl-2.6.1-18 on Solaris 8 (SPARC), John Tang Boyland, 2003/11/10
- Re: [Gcl-devel] Problems building gcl-2.6.1-18 on Solaris 8 (SPARC), John Tang Boyland, 2003/11/11
- Re: [Gcl-devel] Problems building gcl-2.6.1-18 on Solaris 8 (SPARC), John Tang Boyland, 2003/11/15
- Re: [Gcl-devel] Problems building gcl-2.6.1-18 on Solaris 8 (SPARC), John Tang Boyland, 2003/11/15
- Re: [Gcl-devel] Problems building gcl-2.6.1-18 on Solaris 8 (SPARC), John Tang Boyland, 2003/11/16