Hello friends,
thanks to many hints, especially by ~suv, a new ready-for-testing inkscape aqua can be downloaded here:
http://verkehrsplanung.com/Inkscape_aqua_PPC_047.zip
It should launch alone without any macports environment, may immediately kill the X11 after its launch - and makes a quite useable impression.
It was made on a PPC, 10.4.11. Unluckily I cannot switch to the universal variants at the moment, so I'd be grateful if some intel owner would check whether it runs on rosetta. I manually removed i386 python components, this may cause intel machines to get in trouble. Also, I couldnt check whether it works on Leopard or Snowie…
If somebody has some spare time, maybe he wants to have a look at it.
The recipe can be found here:
http://wiki.inkscape.org/wiki/index.php/ CompilingMacOsX#Building_Aqua_February_2010
Yours,
Wolf
A quick test was positive for a G4 iBook running Leopard (WOW!) and negative for MacPro Intel running Snowleopard (see crashlog below). Will there be any way to remap the control keys so that we can use command * instead of control *? If there's something I can help you with on the intel side let me know - but I'm not a porter, packager or much of a coder - so keep it simple ; ) Great work - thanks
Stu
Process: inkscape-bin [75613] Path: /Applications/Inkscape_PPC.app/Contents/Resources/bin/inkscape-bin Identifier: inkscape-bin Version: ??? (???) Code Type: PPC (Translated) Parent Process: Inkscape [75607]
Date/Time: 2010-02-12 12:46:09.279 -0500 OS Version: Mac OS X 10.6.2 (10C540) Report Version: 6
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 inkscape-bin 0xb815ad8b spin_lock_wrapper + 89967 1 inkscape-bin 0xb817a080 CallPPCFunctionAtAddressInt + 98620 2 inkscape-bin 0xb80c6c97 0xb8000000 + 814231 3 inkscape-bin 0xb80c01bb 0xb8000000 + 786875 4 inkscape-bin 0xb80dda6c 0xb8000000 + 907884 5 inkscape-bin 0xb814551b spin_lock_wrapper + 1791 6 inkscape-bin 0xb801d03b 0xb8000000 + 118843
Thread 1: 0 libSystem.B.dylib 0x800c58da mach_msg_trap + 10 1 libSystem.B.dylib 0x800c6047 mach_msg + 68 2 inkscape-bin 0xb819448f CallPPCFunctionAtAddressInt + 206155 3 libSystem.B.dylib 0x800f2fbd _pthread_start + 345 4 libSystem.B.dylib 0x800f2e42 thread_start + 34
Thread 2: 0 inkscape-bin 0xb815ae44 spin_lock_wrapper + 90152 1 inkscape-bin 0xb8179d27 CallPPCFunctionAtAddressInt + 97763 2 inkscape-bin 0xb80c6c97 0xb8000000 + 814231 3 inkscape-bin 0xb80c01bb 0xb8000000 + 786875 4 inkscape-bin 0xb80dda6c 0xb8000000 + 907884 5 inkscape-bin 0xb814551b spin_lock_wrapper + 1791 6 inkscape-bin 0xb801d03b 0xb8000000 + 118843
Thread 3: 0 inkscape-bin 0xb815aa83 spin_lock_wrapper + 89191 1 inkscape-bin 0xb8176f29 CallPPCFunctionAtAddressInt + 85989 2 inkscape-bin 0xb80c6c97 0xb8000000 + 814231 3 inkscape-bin 0xb80c01bb 0xb8000000 + 786875 4 inkscape-bin 0xb80dda6c 0xb8000000 + 907884 5 inkscape-bin 0xb814551b spin_lock_wrapper + 1791 6 inkscape-bin 0xb801d03b 0xb8000000 + 118843
Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0xb8179fe2 ecx: 0x00000000 edx: 0x00000001 edi: 0x0001275d esi: 0x00000006 ebp: 0xb7fff978 esp: 0xb7fff954 ss: 0x0000001f efl: 0x00000246 eip: 0xb815ad8b cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x780ae000
Binary Images: 0x80000000 - 0x8006afe7 libstdc++.6.dylib ??? (???) <411D87F4-B7E1-44EB-F201-F8B4F9227213> /usr/lib/libstdc++.6.dylib 0x800c5000 - 0x80269feb libSystem.B.dylib ??? (???) <D45B91B2-2B4C-AAC0-8096-1FC48B7E9672> /usr/lib/libSystem.B.dylib 0x802e9000 - 0x802ecfe7 libmathCommon.A.dylib ??? (???) <1622A54F-1A98-2CBE-B6A4-2122981A500E> /usr/lib/system/libmathCommon.A.dylib 0x8fe00000 - 0x8fe4162b dyld 132.1 (???) <211AF0DD-42D9-79C8-BB6A-1F4BEEF4B4AB> /usr/lib/dyld 0xb8000000 - 0xb81defff +inkscape-bin ??? (???) <3E4E06B8-E1FC-B232-1371-643DC0FBE8C9> /Applications/Inkscape_PPC.app/Contents/Resources/bin/inkscape-bin 0xffff0000 - 0xffff1fff libSystem.B.dylib ??? (???) <D45B91B2-2B4C-AAC0-8096-1FC48B7E9672> /usr/lib/libSystem.B.dylib
Translated Code Information: NO CRASH REPORT
On Feb 12, 2010, at 10:51 AM, Wolf Drechsel wrote:
Hello friends,
thanks to many hints, especially by ~suv, a new ready-for-testing inkscape aqua can be downloaded here:
http://verkehrsplanung.com/Inkscape_aqua_PPC_047.zip
It should launch alone without any macports environment, may immediately kill the X11 after its launch - and makes a quite useable impression.
It was made on a PPC, 10.4.11. Unluckily I cannot switch to the universal variants at the moment, so I'd be grateful if some intel owner would check whether it runs on rosetta. I manually removed i386 python components, this may cause intel machines to get in trouble. Also, I couldnt check whether it works on Leopard or Snowie…
If somebody has some spare time, maybe he wants to have a look at it.
The recipe can be found here:
http://wiki.inkscape.org/wiki/index.php/ CompilingMacOsX#Building_Aqua_February_2010
Yours,
Wolf
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 12 February 2010 19:40, Stuart Edwards <sedwards2@...1846...> wrote:
A quick test was positive for a G4 iBook running Leopard (WOW!) and negative for MacPro Intel running Snowleopard (see crashlog below). Will there be any way to remap the control keys so that we can use command * instead of control *? If there's something I can help you with on the intel side let me know - but I'm not a porter, packager or much of a coder - so keep it simple ; )
For me inkscape runs on 10.5 Aqua with modded Fink packages but there was some problem. iirc it could not find any fonts and would display just squares everywhere.
I have built a few more gtk apps but did not get around to testing them. It requires that I physically walk to the mac and it's somewhat impractical when I don't need anything on it otherwise.
I hope I will eventually get to looking into this issue but I have basically no clue what the problem might be so far.
Thanks
Michal
Am 12.02.2010 um 19:40 schrieb Stuart Edwards:
Will there be any way to remap the control keys so that we can use command * instead of control *?
Experts will know more than I do - but probabely using ige-mac- integration is a possibility:
http://trac.macports.org/browser/trunk/dports/devel/ige-mac- integration/Portfile
According to people on the "GTK+ Mac OS X" mailing list the inkscape source code has to be patched to make use of it. So probabely occasionally somebody will find the time to do that. Sorry, this is far beyond my possibilities, if not anyone gives me some instruction what to do.
Yours
Wolf Drechsel
On Feb 15, 2010, at 2:34 AM, Wolf Drechsel wrote:
Am 12.02.2010 um 19:40 schrieb Stuart Edwards:
Will there be any way to remap the control keys so that we can use command * instead of control *?
Experts will know more than I do - but probabely using ige-mac- integration is a possibility:
I've actually got that keyboard cleanup as part of my planned extended input device support.
What we would have to do is decouple the hardcoding where masks are checked against events. A combination of changing events and using dynamic values for masks will allow us to switch modifier keys on OS X, to use extended input devices like wacom tablets with express keys for modifiers, and even other input devices as well.
Will there be any way to remap the control keys so that we can use command * instead of control *?
I've actually got that keyboard cleanup as part of my planned extended input device support.
Hello Jon,
good to hear that things are in progress.
Will there be a possibility to user-edit and modify keyboard shortcuts? - IMHO, a real "shortcut editor" as in Open Office is not really necessary, but an editable ASCII file within the package - or even better within my home directory - would be great, as I'm never ever happy with shortcuts fixed by program designers.
Greetings,
Wolf
reposting - former message too long!
Wolf -
The project moves forward and to my great surprise -- almost success.
Unlike your build, mine contains no text or numbers within the inkscape screen. Little square boxes are rendered - one for each character. See below. There's a series of error messages relating to GLib-GObject and Pango (also see below) so they are likely the cause of the problem. Everything else seems to be working (very minimal testing) and quite encouraging.
Any suggestions for fixing the problem?
I haven't built the Mac package yet - this is just based on executing the file in /Build/bin
Best
Stu
Last login: Tue Feb 16 00:07:59 on ttys002 SEsMacPro:~ stu$ /Users/stu/inkscape_port/inkscape-0.47/Build/bin/inkscape ; exit;
(inkscape:24605): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed
(inkscape:24605): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed
(inkscape:24605): Pango-WARNING **: shaping failure, expect ugly output. shape-engine='BasicEngineFc', font='Lucida Grande Medium 9.599609375', text='100'
(inkscape:24605): Pango-WARNING **: shaping failure, expect ugly output. shape-engine='BasicEngineFc', font='Lucida Grande Medium 6.34765625', text='0'
(inkscape:24605): Pango-WARNING **: shaping failure, expect ugly output. shape-engine='BasicEngineFc', font='Bitstream Vera Sans Mono 10', text='•'
(inkscape:24605): Pango-WARNING **: shaping failure, expect ugly output. shape-engine='BasicEngineFc', font='Lucida Grande Medium 12', text='The quick brown fox jumps over the lazy dog.'
(inkscape:24605): Pango-WARNING **: shaping failure, expect ugly output. shape-engine='BasicEngineFc', font='Lucida Grande Semi-Bold 10', text='Layer 1'
(inkscape:24605): Pango-WARNING **: shaping failure, expect ugly output. shape-engine='BasicEngineFc', font='Bitstream Vera Sans Mono 9.599609375', text=' 857.14 '
(inkscape:24605): Pango-WARNING **: shaping failure, expect ugly output. shape-engine='BasicEngineFc', font='Lucida Grande Semi-Bold 12', text='Alt'
(inkscape:24605): Gtk-WARNING **: Unable to find default local directory monitor type
** (inkscape:24605): WARNING **: Unable to open linked file: /Users/stu/PA300001.JPG
Hi,
I don't see this message as part of a thread. I don't know wether it has been answered yet or not. Just in case:
On Tue, Feb 16, 2010 at 16:28, Stuart Edwards <SEDWARDS2@...1846...> wrote:
Unlike your build, mine contains no text or numbers within the inkscape screen. Little square boxes are rendered - one for each character. See below. There's a series of error messages relating to GLib-GObject and Pango (also see below) so they are likely the cause of the problem. Everything else seems to be working (very minimal testing) and quite encouraging.
Any suggestions for fixing the problem?
I haven't built the Mac package yet - this is just based on executing the file in /Build/bin
This is indeed related to pango. IIRC, when I tried this, pango has no quartz variant but when it is build "against" an x11 variant of gtk/cairo, it won't work when those are switched to quartz. In other words: if you switch between x11 and quartz variants, rebuild pango in the process. If you went quartz only from the beginning, then there should be no problem.
However, related to the packaging, if you built Inkscape with --enable-osxapp (which is enabled by default if you use osx-build.sh) I think you need to build the app for Inkscape to find all the dependencies correctly. So I would try this if I were you. The alternative, if you want to speed this up by avoiding the app step is to remove the option --enable-osxapp from osx-build.sh and run from the command line until you are satisfied. when this work, you can go back to the app. This will have the added benefit of isolating the bundling problems from the more fundamental problems in Inkscape itself.
JiHO --- http://maururu.net
JiHO -
It was a little strange - my message never made it to the board because it was too big (there were attachments) so I reduced it below the legal limit and it still never showed up. So, not sure how you came by it - but no matter, thanks for the response.
I've been working under the watchful eye of Wolf who has provided a few ideas that I need to try. Will keep you informed of progress (hopefully).
Stu
On Mar 1, 2010, at 12:10 PM, JiHO wrote:
Hi,
I don't see this message as part of a thread. I don't know wether it has been answered yet or not. Just in case:
On Tue, Feb 16, 2010 at 16:28, Stuart Edwards <SEDWARDS2@...1846...> wrote:
Unlike your build, mine contains no text or numbers within the inkscape screen. Little square boxes are rendered - one for each character. See below. There's a series of error messages relating to GLib-GObject and Pango (also see below) so they are likely the cause of the problem. Everything else seems to be working (very minimal testing) and quite encouraging.
Any suggestions for fixing the problem?
I haven't built the Mac package yet - this is just based on executing the file in /Build/bin
This is indeed related to pango. IIRC, when I tried this, pango has no quartz variant but when it is build "against" an x11 variant of gtk/cairo, it won't work when those are switched to quartz. In other words: if you switch between x11 and quartz variants, rebuild pango in the process. If you went quartz only from the beginning, then there should be no problem.
However, related to the packaging, if you built Inkscape with --enable-osxapp (which is enabled by default if you use osx-build.sh) I think you need to build the app for Inkscape to find all the dependencies correctly. So I would try this if I were you. The alternative, if you want to speed this up by avoiding the app step is to remove the option --enable-osxapp from osx-build.sh and run from the command line until you are satisfied. when this work, you can go back to the app. This will have the added benefit of isolating the bundling problems from the more fundamental problems in Inkscape itself.
JiHO
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Some success -- built pango 1.26 with the portfile you suggested - and we're in business ........ Looks great and seems to work fine, but no time for a thorough test right now. Packaging next. Thanks for all your help.
Later
Stu
On Mar 1, 2010, at 12:10 PM, JiHO wrote:
Hi,
I don't see this message as part of a thread. I don't know wether it has been answered yet or not. Just in case:
On Tue, Feb 16, 2010 at 16:28, Stuart Edwards <SEDWARDS2@...1846...> wrote:
Unlike your build, mine contains no text or numbers within the inkscape screen. Little square boxes are rendered - one for each character. See below. There's a series of error messages relating to GLib-GObject and Pango (also see below) so they are likely the cause of the problem. Everything else seems to be working (very minimal testing) and quite encouraging.
Any suggestions for fixing the problem?
I haven't built the Mac package yet - this is just based on executing the file in /Build/bin
This is indeed related to pango. IIRC, when I tried this, pango has no quartz variant but when it is build "against" an x11 variant of gtk/cairo, it won't work when those are switched to quartz. In other words: if you switch between x11 and quartz variants, rebuild pango in the process. If you went quartz only from the beginning, then there should be no problem.
However, related to the packaging, if you built Inkscape with --enable-osxapp (which is enabled by default if you use osx-build.sh) I think you need to build the app for Inkscape to find all the dependencies correctly. So I would try this if I were you. The alternative, if you want to speed this up by avoiding the app step is to remove the option --enable-osxapp from osx-build.sh and run from the command line until you are satisfied. when this work, you can go back to the app. This will have the added benefit of isolating the bundling problems from the more fundamental problems in Inkscape itself.
JiHO
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Will there be a possibility to user-edit and modify keyboard shortcuts? - IMHO, a real "shortcut editor" as in Open Office is not really necessary, but an editable ASCII file within the package - or even better within my home directory - would be great, as I'm never ever happy with shortcuts fixed by program designers.
Hello,
sorry for annoying people with stupid questions - ~suv told me that the thing I suggested (~/.config/inkscape/keys/default.xml) already exists. A brief test shows that editing it works on the aqua version as well. Nice!
Greetings,
Wolf
2010/2/15 Jon Cruz <jon@...18...>:
On Feb 15, 2010, at 2:34 AM, Wolf Drechsel wrote:
Am 12.02.2010 um 19:40 schrieb Stuart Edwards:
Will there be any way to remap the control keys so that we can use command * instead of control *?
Experts will know more than I do - but probabely using ige-mac- integration is a possibility:
I've actually got that keyboard cleanup as part of my planned extended input device support.
What we would have to do is decouple the hardcoding where masks are checked against events. A combination of changing events and using dynamic values for masks will allow us to switch modifier keys on OS X, to use extended input devices like wacom tablets with express keys for modifiers, and even other input devices as well.
Would it be possible to eventually submit a patch for GDK? This would benefit the largest number of people.
This can be as simple as defining portable variants of masks in GdkModifierType, the correct values being determined at compile time, based on whether we are compiling for Mac or not.
Regards, Krzysztof
On 12/2/10 16:51, Wolf Drechsel wrote:
It should launch alone without any macports environment, may immediately kill the X11 after its launch - and makes a quite useable impression.
Why not completely remove the part that launches X11 (what if the user has other x11 apps running and needs to save data before quitting X11)?
It was made on a PPC, 10.4.11. Unluckily I cannot switch to the universal variants at the moment, so I'd be grateful if some intel owner would check whether it runs on rosetta. I manually removed i386 python components, this may cause intel machines to get in trouble. Also, I couldnt check whether it works on Leopard or Snowie…
Summary: Inkscape 0.47 Tiger PPC Quartz fails on OS X 10.5.8 Leopard i386 with the same error as your other build (0.47 Tiger PPC X11) on Tiger and Leopard Macs with Intel architecture (see related bug reports #513335, #517883, #520022)
tested with these local changes: - script modified to remove X11 launching part - removed X11 font path from 'Contents/Resources/etc/fonts/fonts.conf' - separate font cache configured in 'Contents/Resources/etc/fonts/fonts.conf' - added empty 'Contents/Resources/etc/pango/pangox.aliases'
~suv
detailed Results:
A) double-click in the finder crashes with (weirdly colored) dialog message (attached)
B) launching outer shell script wrapper from the command line It doesn't make a difference whether I click the Platypus launcher or call the launcher script with its full pathname '/path/to/Inkscape.app/Contents/Resources/script' on the command line - both fail with 'task_get_state failed'.
LeWitt:~ suv$ /Volumes/blue/src/Inkscape/0_47/Inkscape-0.47-1.TIGER-Quartz-PPC/Inkscape-0_47-1-Tiger-Quartz-PPC.app-orig/Contents/Resources/script-LeWitt.sh Setting Language: .UTF-8
(process:76914): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale.
(inkscape-bin:76914): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed task_get_state failed
Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it.
C) launching the inner shell script from the command line cd'ing to the root of the application package and launching the inner shell script wrapper with its full path name '/path/to/Inkscape.app/Contents/Resources/bin/inkscape' sets the environment for Inkscape correctly and results in the same crash as when launching the application from the finder:
LeWitt:Inkscape-0_47-1-Tiger-Quartz-PPC.app-orig suv$ /Volumes/blue/src/Inkscape/0_47/Inkscape-0.47-1.TIGER-Quartz-PPC/Inkscape-0_47-1-Tiger-Quartz-PPC.app-orig/Contents/Resources/bin/inkscape Setting Language: .UTF-8
(process:77145): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale.
(inkscape-bin:77145): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed task_get_state failed
Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it. Killed LeWitt:Inkscape-0_47-1-Tiger-Quartz-PPC.app-orig suv$
D) launching inner shell script wrapper from the command line crash (as expected) when launching the shell script directly with its full path '/path/to/Inkscape.app/Contents/Resources/bin/inkscape' from the command line (in $HOME).
(Note: inkscape-bin can't find its resources because the necessary variable pointing to the root of the application bundle is not set correctly if the outer shell script wrapper is not used or the current directory is not the root of the application bundle. Some other variables are set correctly e.g. $DYDL_LIBRARY_PATH.)
Console messages:
LeWitt:~ suv$ /Volumes/blue/src/Inkscape/0_47/Inkscape-0.47-1.TIGER-Quartz-PPC/Inkscape-0_47-1-Tiger-Quartz-PPC.app-orig/Contents/Resources/bin/inkscape Setting Language: .UTF-8
(process:77044): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale.
** (inkscape-bin:77044): CRITICAL **: Inkscape::XML::Document* sp_repr_read_file(const gchar*, const gchar*): assertion `Inkscape::IO::file_test( filename, G_FILE_TEST_EXISTS )' failed
** (inkscape-bin:77044): WARNING **: Unable to read keys file Contents/Resources/keys/default.xml Unable to find: org.inkscape.help.manual Unable to find: org.inkscape.help.keys Unable to find: org.inkscape.help.askaquestion Unable to find: org.inkscape.help.commandline Unable to find: org.inkscape.help.faq Unable to find: org.inkscape.help.relnotes Unable to find: org.inkscape.help.reportabug Unable to find: org.inkscape.help.svgspec
(inkscape-bin:77044): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed
(inkscape-bin:77044): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed 2010-02-13 04:49:16.106 inkscape-bin[77044:613] *** -[NSDragDestination autorecalculatesContentBorderThicknessForEdge:]: unrecognized selector sent to instance 0x17d20500 2010-02-13 04:49:16.276 inkscape-bin[77044:613] An uncaught exception was raised 2010-02-13 04:49:16.284 inkscape-bin[77044:613] *** -[NSDragDestination autorecalculatesContentBorderThicknessForEdge:]: unrecognized selector sent to instance 0x17d20500 2010-02-13 04:49:16.288 inkscape-bin[77044:613] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSDragDestination autorecalculatesContentBorderThicknessForEdge:]: unrecognized selector sent to instance 0x17d20500' 2010-02-13 04:49:16.309 inkscape-bin[77044:613] Stack: ( 2483498224, 2505680108, 2483527352, 2483520692, 2483521352, 2417697092, 2483043748, 2483048268, 2447563544, 2447562916, 2447562620, 2417689160, 2417687552, 28329228, 34161852, 34162996, 24676336, 24728, 20704, 12540, 11776 ) Trace/BPT trap
The crash report says the PPC (translated) inkscape-bin process crashes in '/usr/libexec/oah/translate'
E) launching binary without shell script wrapper Calling the 'inkscape-bin' binary directly from the command line crashes immediately in '/usr/libexec/oah/translate'. It doesn't even get as far as trying to load (but not find) resources needed (fonts, loader and pango modules, gtkrc) presumably because DYLD_LIBRARY_PATH is not set.
LeWitt:~ suv$ /Volumes/blue/src/Inkscape/0_47/Inkscape-0.47-1.TIGER-Quartz-PPC/Inkscape-0_47-1-Tiger-Quartz-PPC.app-orig/Contents/Resources/bin/inkscape-bin dyld: Library not loaded: /opt/local/lib/libgtkmm-2.4.1.dylib Referenced from: /Volumes/blue/src/Inkscape/0_47/Inkscape-0.47-1.TIGER-Quartz-PPC/Inkscape-0_47-1-Tiger-Quartz-PPC.app-orig/Contents/Resources/bin/inkscape-bin Reason: image not found Trace/BPT trap
It should launch alone without any macports environment, may immediately kill the X11 after its launch - and makes a quite useable impression.
Why not completely remove the part that launches X11 (what if the user has other x11 apps running and needs to save data before quitting X11)?
You are very wellcome to tell me a less brutal solution. Unluckily I dont know the place where the X11 launcher script is called - and how I can abandon it.
It was made on a PPC, 10.4.11. Unluckily I cannot switch to the universal variants at the moment, so I'd be grateful if some intel owner would check whether it runs on rosetta. I manually removed i386 python components, this may cause intel machines to get in trouble. Also, I couldnt check whether it works on Leopard or Snowie…
Summary: Inkscape 0.47 Tiger PPC Quartz fails on OS X 10.5.8 Leopard i386 with the same error as your other build (0.47 Tiger PPC X11) on Tiger and Leopard Macs with Intel architecture (see related bug reports #513335, #517883, #520022)
Bare in mind that it is NOT an universal build - it's PPC only. IMHO there is not much of a clou to make the whole thing "rosetta proof". Rather we should go for a native intel build - probabely less effort and a much better result.
Unluckily I cannot build an universal one at the moment, as applying the patch
http://trac.macports.org/ticket/22451
fails when I try to invoke the +universal variant - and the author of the patch doesnt have an idea what's going wrong with it. But building an intel version from scratch should not really be difficult - as even I could do it on the PPC side.
Maybe Stuart will… ???? ((((-;
Greetings,
Wolf
Wolf ok -- you shamed me into it - at least giving it a try. Didn't have a macports installed so that was a pain -- ~120 dependencies and 3 Gb later we're almost ready to start the real business. Quick question - gtk2 installed +quartz+no_x11 without a murmur using macports - does this mean that the necessary patch is preinstalled now or should I uninstall it and use the procedure you wrote up in the wiki? thx
Stu On Feb 13, 2010, at 4:21 PM, Wolf Drechsel wrote:
It should launch alone without any macports environment, may immediately kill the X11 after its launch - and makes a quite useable impression.
Why not completely remove the part that launches X11 (what if the user has other x11 apps running and needs to save data before quitting X11)?
You are very wellcome to tell me a less brutal solution. Unluckily I dont know the place where the X11 launcher script is called - and how I can abandon it.
It was made on a PPC, 10.4.11. Unluckily I cannot switch to the universal variants at the moment, so I'd be grateful if some intel owner would check whether it runs on rosetta. I manually removed i386 python components, this may cause intel machines to get in trouble. Also, I couldnt check whether it works on Leopard or Snowie…
Summary: Inkscape 0.47 Tiger PPC Quartz fails on OS X 10.5.8 Leopard i386 with the same error as your other build (0.47 Tiger PPC X11) on Tiger and Leopard Macs with Intel architecture (see related bug reports #513335, #517883, #520022)
Bare in mind that it is NOT an universal build - it's PPC only. IMHO there is not much of a clou to make the whole thing "rosetta proof". Rather we should go for a native intel build - probabely less effort and a much better result.
Unluckily I cannot build an universal one at the moment, as applying the patch
http://trac.macports.org/ticket/22451
fails when I try to invoke the +universal variant - and the author of the patch doesnt have an idea what's going wrong with it. But building an intel version from scratch should not really be difficult - as even I could do it on the PPC side.
Maybe Stuart will… ???? ((((-;
Greetings,
Wolf
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev_________________________________________... Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (7)
-
JiHO -
Jon Cruz -
Krzysztof Kosiński -
Michal Suchanek -
Stuart Edwards -
Wolf Drechsel -
~suv