[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: carbon emacs won't build with Dec 2002 dev tools?
From: |
Andrew Choi |
Subject: |
Re: carbon emacs won't build with Dec 2002 dev tools? |
Date: |
Sat, 21 Dec 2002 22:24:10 GMT |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 |
Hugo Wolf <hwolf@deutsches.lieder.net> writes:
> In article <m265tn3x2t.fsf@owlbear.local>, Andrew Choi wrote:
> > An obvious thing to try to modify unexmacosx.c to treat the section
> > `__cfstring' like other sections not requiring relocation, such as
> > `__la_symbol_ptr' and others.
>
> Obvious to you maybe :) I'll look into this and see if I can figure
> something out. Thanks for the hint.
It really is, if you use gdb to check where temacs failed.
The change to make is to add an additional comparison
|| strncmp (sectp->sectname, "__cfstring", 16) == 0
to the following comparison in unexmacosx.c (copy_data_segment).
...
else if (strncmp (sectp->sectname, "__la_symbol_ptr", 16) == 0
|| strncmp (sectp->sectname, "__nl_symbol_ptr", 16) == 0
|| strncmp (sectp->sectname, "__dyld", 16) == 0
|| strncmp (sectp->sectname, "__const", 16) == 0)
Would appreciate it if you can report the result to the list, for the
benefit of those who are thinking about installing the new developer
tools.
>From help-gnu-emacs-bounces@gnu.org Sat Dec 21 18:20:17 2002
Path:
shelby.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!cyclone2.usenetserver.com!news.webusenet.com!news01.optonline.net!news4.srv.hcvlny.cv.net.POSTED!53ab2750!not-for-mail
Message-ID: <3E04F672.2090606@rcn.com>
From: Tribhuvan <loka@rcn.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US;
rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.sys.mac.apps,comp.sys.mac.advocacy,comp.text.tex,gnu.emacs.help
References: <041220020952400758%ajanta@no.spam> <m2hedrm4oc.fsf@owlbear.local>
<84bs3xsyi8.fsf@lucy.cs.uni-dortmund.de>
<071220021155280606%ajanta@no.spam>
<5ld6obj8il.fsf@rum.cs.yale.edu> <091220021652087216%ajanta@no.spam>
<101220021125583826%ajanta@no.spam> <vf3cp5ix2u.fsf@rpc71.cs.man.ac.uk>
<vf3cp4k92x.fsf@rpc71.cs.man.ac.uk> <111220021101520860%ajanta@no.spam>
<vfadjcif3n.fsf@rpc71.cs.man.ac.uk> <111220021253524057%ajanta@no.spam>
<5l65u0i8zj.fsf@rum.cs.yale.edu> <111220022053507599%ajanta@no.spam>
<84k7ifo3s2.fsf@lucy.cs.uni-dortmund.de>
<87u1hjdwta.fsf@hurd.crasseux.com>
<121220021324043990%ajanta@no.spam>
<m3el8iar9g.fsf@mika.informatik.uni-freiburg.de>
<171220021132381961%ajanta@no.spam> <3DFFA457.1020103@rcn.com>
<844r9b3exh.fsf@lucy.cs.uni-dortmund.de> <un0n2yi04.fsf@synopsys.com>
<87y96m3xhg.fsf@tc-1-100.kawasaki.gol.ne.jp>
<1mr8ceoypu.fsf@Tempo.Update.UU.SE>
<87wum4w7nj.fsf@tc-1-100.kawasaki.gol.ne.jp>
<1mfzsrblka.fsf@Tempo.Update.UU.SE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 20
Date: Sat, 21 Dec 2002 23:15:45 GMT
NNTP-Posting-Host: 24.189.235.22
X-Trace: news4.srv.hcvlny.cv.net 1040512545 24.189.235.22 (Sat, 21 Dec 2002
18:15:45 EST)
NNTP-Posting-Date: Sat, 21 Dec 2002 18:15:45 EST
Organization: Optimum Online
Xref: shelby.stanford.edu comp.sys.mac.apps:349501
comp.sys.mac.advocacy:919531 comp.text.tex:238700 gnu.emacs.help:108411
To: help-gnu-emacs@gnu.org
Subject: Re: Software/HD ecology
X-BeenThere: help-gnu-emacs@gnu.org
X-Mailman-Version: 2.1b5
Precedence: list
List-Id: Users list for the GNU Emacs text editor <help-gnu-emacs.gnu.org>
List-Help: <mailto:help-gnu-emacs-request@gnu.org?subject=help>
List-Post: <mailto:help-gnu-emacs@gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/help-gnu-emacs>,
<mailto:help-gnu-emacs-request@gnu.org?subject=subscribe>
List-Archive: <http://mail.gnu.org/pipermail/help-gnu-emacs>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/help-gnu-emacs>,
<mailto:help-gnu-emacs-request@gnu.org?subject=unsubscribe>
X-List-Received-Date: Sat, 21 Dec 2002 23:20:17 -0000
Fredrik Staxeng wrote:
> Yes, coding standards do not, on their own, actually do anything.
> The addition to the coding standards would be "the configure script
> should check for the existence of gnu-install".
Which doesn't at all get in the way of anyone who does not want
to implement gnu-install
> I would like to be able to force packages to use a tool that I trust.
> If it is easy enough to do, I would implement support for it and send
> patches to the maintainer.
If it's kept to basically to:
1) logging the cp operations of `make install`
2) providing a script to remove part or all of what's in the log
It shouldn't get too monsterous.