Așa am făcut (și nu pt prima oară, dar zic, hai că ma un sistem reinstalat proaspăt). Ei nu.
Hihi, păi nu-mi fac speranțe, vreau să știu…
Dar bănuiesc totuși că e ceva care poate fi rezolvat, fiindcă la alții nu face așa.
Uite iar o bucată din crashlog:
Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  0 Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   LaunchCFMApp               0xb815ac07 spin_lock_wrapper + 89967
1   LaunchCFMApp               0xb8179fb4 CallPPCFunctionAtAddressInt + 98620
2   LaunchCFMApp               0xb80c6b13 0xb8000000 + 813843
3   LaunchCFMApp               0xb80c0037 0xb8000000 + 786487
4   LaunchCFMApp               0xb80dd8e8 0xb8000000 + 907496
5   LaunchCFMApp               0xb8145397 spin_lock_wrapper + 1791
6   LaunchCFMApp               0xb801ceb7 0xb8000000 + 118455

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x00000000 ebx: 0xb8179f16 ecx: 0x00000000 edx: 0x00000001
  edi: 0x0000c43c esi: 0x00000006 ebp: 0xb7fff978 esp: 0xb7fff954
  ss: 0x0000001f efl: 0x00000246 eip: 0xb815ac07   cs: 0x00000017
  ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0xb8179f08

Primul crash log era mai graitor (mai complet):

Ce se vede in el: moare un proces numit FreeHand MX (cu process id 2281) care contine cod PPC.
El a fost pornit de un alt proces denumit tot FreeHand MX (process id 2270) care supravietuieste crash-ului -> de unde probabil si efectul ca aplicatia nu-ti moare complet, doar iti afiseaza un dialog box.

Asta ar insemna ca FreeHand porneste un sub-proces, care moare si nu este critic pentru functionarea aplicatiei.

Mai interesant este felul in care sub procesul moare (SIGABRT e abort - nu e un crash obisnuit - aplicatia ajunge intr-o stare neasteptata si decide sa iasa pentru ca nu poate continua executia).
Combinat cu faptul ca incerci sa rulezi o aplicatie Carbon (LaunchCFMApp) PPC pe un Intel - probabil din OS-ul tau lipseste ceva fata de ce au ceilalti instalat.
Un posibil scenariu: tu ai instalat 10.6 “de la zero” iar ei au facut upgrade de la 10.4/10.5 si le-au ramas pe disc fisiere de OS care la tine nu exista.

Banuiesc ca iti moare componenta de activare mentionata aici:
http://kb2.adobe.com/cps/504/cpsid_50468.html

Va fi foarte greu sa-ti dai seama ce se intampla din cauza combinatiei nefericite (Carbon PPB rulat prin Rosetta) -> teoretic ai putea sa pornesti un debugger sa vezi ce se intampla in jurul 0xb815ac07 (valoare instruction pointer-ului la momentul crash-ului, vezi la thread state EIP) dar avand in vedere ca procesul iese cu abort nu cred ca vei gasi mare lucru.

Înțeleg logica (nu tehnica) a ceea ce explici. În fine ceva! Mulțumesc mult!

Componenta aia am instalat-o de mai multe ori. O să mai încerc să instalez FH odată, dar de pe disc de instalare din ultima generație – dacă există: care instaează direct 11.2, fără update – există? Eu am numai 11.o și fără actualizare la 11.1 (care e inaccesibilă) nu se poate nici 11.2, deci am făcut niște acrobații pînă acum.

Dacă intr-adevăr se poate detecta ce anume componente lipsesc, ele se pot recupera de pe discurile de sistem vechi, sau pot face o reinstalare completă de la siteme mai vechi – întrebarea e de la care, și care pot fo sărite… Durează cam o zi… Dar merită? FH e ok după eroare, la urma urmei.

Fapul că se agață cînd lucrez în el mai mult de 20 minute fără să salvez e o bubă pe care a avut-o dintotdeauna, deci nu cred că e relevant un crashlog de-acolo (nici n-am unul la îndemînă, în general le evit cu succes și cu atenție )

Mi-am mai adus aminte ceva, de la rîndul ăsta:
0x805de000 - 0x805ecfe7 libz.1.dylib 1.2.3 (compatibility 1.0.0) <33C1B260-ED05-945D-FC33-EF56EC791E2E> /usr/lib/libz.1.dylib

Și anume că, mergînd o dată pe firul unor (sau al acestei) probleme am ajuns la niște explicații despre dylib, care erau tehnice și nu includeau o soluție. Rezultă cumva de mai sus că, în loc de libz.1.2.3.dylib ar trebui să am versiunea 1.0.0 sau să le am pe ambele în
/usr/lib/libz.1.2.3.dylib ? Această library e de altfe și o componentă a SDK (/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.1.2.3.dylib) deci poate se poate doar extrage din SDK fără să mai instalez un sistem complet? Scuze pentru „ingenuitate” 

VlAdLitteram - 05 Februarie 2012 01:12 PM

Dar merită? FH e ok după eroare, la urma urmei.

Nu cred sa merite - mai ales ca nu sunt nici un fel de garantii ca de-acolo e problema.

VlAdLitteram - 05 Februarie 2012 01:28 PM

Mi-am mai adus aminte ceva, de la rîndul ăsta:
0x805de000 - 0x805ecfe7 libz.1.dylib 1.2.3 (compatibility 1.0.0) <33C1B260-ED05-945D-FC33-EF56EC791E2E> /usr/lib/libz.1.dylib

Și anume că, mergînd o dată pe firul unor (sau al acestei) probleme am ajuns la niște explicații despre dylib, care erau tehnice și nu includeau o soluție. Rezultă cumva de mai sus că, în loc de libz.1.2.3.dylib ar trebui să am versiunea 1.0.0 sau să le am pe ambele în
/usr/lib/libz.1.2.3.dylib ? Această library e de altfe și o componentă a SDK (/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.1.2.3.dylib) deci poate se poate doar extrage din SDK fără să mai instalez un sistem complet? Scuze pentru „ingenuitate” 

1.0.0 nu ar trebui sa fie o versiune de libz, ci mai degraba o declaratie de compatibilitate.
Cand un program depinde de un dynamic library extern, se stabileste o versiune de baza de care depinde, pentru a evita o dependinta directa de o versiune minora (daca apare un bug sa sa faca update doar la versiunea minora).

Spre exemplu libpng depinde de libz (PNG face compresie cu Zlib - lib-ul de criptare din libz):

libpng se declara dependent de libz versiunea 1.0.0.
Totusi, eu nu am libz 1.0.0 pe disc ci 1.2.5, care in schimb spune ca este compatibil cu 1.0.0:

Mai mult, cand OS-ul nu gaseste un dylib de care depinde un program, in crash log-ul programului apare “image not found”.

Din pacate Rosetta e un animal ciudat deci nu stiu daca ce am scris mai sus e valabil pentru cod “interpretat” (i.e. PPC rulat pe Intel).

Mulțumesc pentru explicație și pentru timp!
…apare “image not found” – aha, aici nu e cazul, deci nu lipsește nimic, e o incompatibilitate. A ce cu ce – nu se poate stabili numai din protocolul de eroare, dacă înțeleg bine. Adică bibliotecile menționate acolo sunt ok, hiba e altundeva. Pentru mine, asta este (dacă am priceput bine), o informație nouă și clară: s-a rezolvat, nu se poate citi din crashlog ceva care să ducă direct la o soluție sau workaround*. Și dacă mă încăpățînez totuși, ce se poate face (teroetic și/sau practic)?
* (cum traducem workaround?)