[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]