[M3devel] another Snow Leopard compiler crash
Mika Nystrom
mika at async.caltech.edu
Sun Jan 9 00:51:39 CET 2011
I started from scratch (working cm3 install) several times. No go.
upgrade.py was just not able to upgrade my particular setup (current
as of a few weeks ago).
Starting from the previous release worked, but now there's this
configure_system_libs thing---this seems to be a config file issue?
(Also something not taken care of by upgrade.py)
A lot of futzing around...
Mika
jay.krell at cornell.edu writes:
>Yes. When upgrade.py fails, you may or may not be in a bad state. I can see a=
>bout making it safer. There are unavoidable depenedencies among cm3, cm3cg, a=
>nd m3core, and maybe libm3.
>
>Starting point is a working cm3, and its cm3cg, and its config files, and m3=
>core, and possible its libm3. =20
>
>I think maybe I should write a feature in upgrade.py that can start from scr=
>atch -- download old install archive or start from a specified local copy th=
>ereof. Interest? I might use it myself. I think upgrade should also have opt=
>ion to build all.
>
> - Jay
>
>On Jan 8, 2011, at 1:17 PM, Mika Nystrom <mika at async.caltech.edu> wrote:
>
>> Do I need to go back to the release and install that, and then upgrade.py?=
>
>> As far as I know my compiler was working fine...
>>=20
>> Jay K writes:
>>> --_1def5bc1-96d7-442f-bd33-2522abadf97d_
>>> Content-Type: text/plain; charset=3D"iso-8859-1"
>>> Content-Transfer-Encoding: quoted-printable
>>>=20
>>> Tony's instructions imho are too much work=3D2C error-prone. Upgrade.py d=
>oes =3D
>>> rebuild cm3cg. Don't do it manually=3D2C as you have to be careful when y=
>ou s=3D
>>> witch from old to new=3D2C and upgrade.py knows. There was a problem rega=
>rdin=3D
>>> g m3bundle=3D2C fairly recently. So try head. Not a few weeks ago. The sc=
>ript=3D
>>> s specifically had a problem.
>>>=20
>>> Jay/phone
>>>=20
>>>> To: jay.krell at cornell.edu
>>>> Subject: Re: [M3devel] another Snow Leopard compiler crash=3D20
>>>> Date: Sat=3D2C 8 Jan 2011 08:10:01 -0800
>>>> From: mika at async.caltech.edu
>>>> =3D20
>>>> Jay K writes:
>>>>> --_8699851d-dc9a-486c-965d-eaed43f71a51_
>>>>> Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1"
>>>>> Content-Transfer-Encoding: quoted-printable
>>>>>=20
>>>>> It no longer builds m3bundle I think. There was a problem regarding m3b=
>=3D
>>> und=3D3D
>>>>> le for a while=3D3D2C because I had followed upgrade.sh too closely=3D3=
>D2C w=3D
>>> hich ha=3D3D
>>>>> d this problem. And this is a sign of using old cm3cg. Are you sure you=
> =3D
>>> did=3D3D
>>>>> n't do something weird? Uograde.py does upgrade cm3cg appropriately. Tr=
>y=3D
>>> he=3D3D
>>>>> ad?
>>>>>=20
>>>> =3D20
>>>> I'm not sure I didn't do anything weird. I have a CM3 distribution that=
>
>>>> was release=3D2C then I upgraded it to head as of three weeks ago using
>>>> the procedure Tony described to me a few years ago. I've been using
>>>> that with no special problems since then. I then updated to the CVS hea=
>d
>>>> and ran "python upgrade.py". It does not rebuild cm3cg=3D2C but I can d=
>o i=3D
>>> t
>>>> manually and try again.
>>>> =3D20
>>>> Mika
>>> =3D
>>>=20
>>> --_1def5bc1-96d7-442f-bd33-2522abadf97d_
>>> Content-Type: text/html; charset=3D"iso-8859-1"
>>> Content-Transfer-Encoding: quoted-printable
>>>=20
>>> <html>
>>> <head>
>>> <style><!--
>>> .hmmessage P
>>> {
>>> margin:0px=3D3B
>>> padding:0px
>>> }
>>> body.hmmessage
>>> {
>>> font-size: 10pt=3D3B
>>> font-family:Tahoma
>>> }
>>> --></style>
>>> </head>
>>> <body class=3D3D'hmmessage'>Tony's instructions imho are too much work=3D=
>2C err=3D
>>> or-prone. Upgrade.py does rebuild cm3cg. Don't do it manually=3D2C as you=
> hav=3D
>>> e to be careful when you switch from old to new=3D2C and upgrade.py knows=
>. Th=3D
>>> ere was a problem regarding m3bundle=3D2C fairly recently. So try head. N=
>ot a=3D
>>> few weeks ago. The scripts specifically had a problem.<br><br> Jay/phone<=
>b=3D
>>> r><br>> To:=3D3B jay.krell@=3D3Bcornell.edu<br>> Subject:=3D3B R=
>e:=3D3B=3D
>>> [=3D3BM3devel]=3D3B another Snow Leopard compiler crash <br>> Date&=
>#58=3D
>>> =3D3B Sat=3D2C 8 Jan 2011 08:=3D3B10:=3D3B01 -0800<br>> From:=3D=
>3B mika@=3D
>>> =3D3Basync.caltech.edu<br>> <br>> Jay K writes:=3D3B<br>> >=3D3B--_=
>8699851d=3D
>>> -dc9a-486c-965d-eaed43f71a51_<br>> >=3D3BContent-Type:=3D3B text/pl=
>ain=3D
>>> 9=3D3B charset==3D3B"=3D3Biso-8859-1"=3D3B<br>> >=3D3BContent=
>-Transfer-En=3D
>>> coding:=3D3B quoted-printable<br>> >=3D3B<br>> >=3D3B It no long=
>er build=3D
>>> s m3bundle I think. There was a problem regarding m3bund==3D3B<br>> &#=
>62=3D
>>> =3D3Ble for a while==3D3B2C because I had followed upgrade.sh too clos=
>ely=3D
>>> 1=3D3B2C which ha==3D3B<br>> >=3D3Bd this problem. And this is a si=
>gn of us=3D
>>> ing old cm3cg. Are you sure you did==3D3B<br>> >=3D3Bn'=3D3Bt do=
> somethi=3D
>>> ng weird?=3D3B Uograde.py does upgrade cm3cg appropriately. Try he==
>=3D3B<=3D
>>> br>> >=3D3Bad?=3D3B<br>> >=3D3B<br>> <br>> I'=3D3Bm not sure I=
> didn'=3D
>>> =3D3Bt do anything weird. I have a CM3 distribution that<br>> was releas=
>e=3D2C=3D
>>> then I upgraded it to head as of three weeks ago using<br>> the procedure=
> =3D
>>> Tony described to me a few years ago. I'=3D3Bve been using<br>> that w=
>ith=3D
>>> no special problems since then. I then updated to the CVS head<br>> and r=
>=3D
>>> an "=3D3Bpython upgrade.py"=3D3B. It does not rebuild cm3cg=3D2C b=
>ut I can=3D
>>> do it<br>> manually and try again.<br>> <br>> Mika<br> =20
>>> <=3D
>>> /body>
>>> </html>=3D
>>>=20
>>> --_1def5bc1-96d7-442f-bd33-2522abadf97d_--
More information about the M3devel
mailing list