Issue 69944 - Running SDK on Mac OS X Intel
Summary: Running SDK on Mac OS X Intel
Status: CONFIRMED
Alias: None
Product: porting
Classification: Code
Component: MacOSX (show other issues)
Version: OOo 2.0.4
Hardware: Mac Mac OS X, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-28 14:53 UTC by sparcmoz
Modified: 2013-07-30 02:47 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
screenshot of the SDK running (526.79 KB, image/png)
2006-09-28 14:59 UTC, sparcmoz
no flags Details
verbose fail log (41.91 KB, text/plain)
2006-09-28 15:01 UTC, sparcmoz
no flags Details
run nm and strip address maho libjpipe.dylib (860 bytes, text/plain)
2006-09-28 15:08 UTC, sparcmoz
no flags Details
run nm and strip addresses on jim libjpipe.dylib (1.10 KB, text/plain)
2006-09-28 15:08 UTC, sparcmoz
no flags Details
diff -u the two nm libs (1.25 KB, text/plain)
2006-09-28 15:09 UTC, sparcmoz
no flags Details
verbose log when success (51.91 KB, text/plain)
2006-09-28 21:53 UTC, sparcmoz
no flags Details
add symlink for libjpipe.jnilib (601 bytes, patch)
2006-10-07 11:41 UTC, sparcmoz
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description sparcmoz 2006-09-28 14:53:59 UTC
The SDK unpacks into folder "OpenOffice.org SDK" but the configure script wants it in "Openoffice.org" 
so I just move the whole thing there. Configure fails until the environment is set with OFFICE_HOME='/
Applications/OpenOffice.org 2.0.app/Contents/MacOS'
cd examples/DevelopersGuide/FirstSteps and run "make" is OK. 

But the first test fails like this:

jim-watsons-computer:~/OpenOffice.org/examples/DevelopersGuide/FirstSteps jim$ make 
FirstUnoContact.run
"/usr/bin/java" -Dcom.sun.star.lib.loader.unopath="/Applications/OpenOffice.org 2.0.app/Contents/
MacOS/program" -jar /Users/jim/OpenOffice.org/MACOSXexample.out/class/FirstStepsExamples/
FirstUnoContact.jar
CE> /Applications/OpenOffice.org 2.0.app/Contents/MacOS/program/soffice: line 108: [: /Users/jim/
OpenOffice.org/macosx/lib:/Users/jim/OpenOffice.org/MACOSXexample.out/lib:/Applications/
OpenOffice.org: unary operator expected

If I copy my own build of jurt/unxmacxi.pro/lib/libjpip.dylib and the symlink into MacOS/program then 
the examples suceeds, with the expected extra lines at the end:
Connected to a running office ...
remote ServiceManager is available 

And the other 2 examples in FirstSteps run nicely - remote documeent creation and editing in calc and 
writer.
I use XCode2.4, maho build was Xcode 2.2.1

I will upload some attachments with more information about what is different in the libs, both are 
OOD680_m4
Comment 1 sparcmoz 2006-09-28 14:59:34 UTC
Created attachment 39419 [details]
screenshot of the SDK running
Comment 2 sparcmoz 2006-09-28 15:01:03 UTC
Created attachment 39420 [details]
verbose fail log
Comment 3 sparcmoz 2006-09-28 15:08:00 UTC
Created attachment 39421 [details]
run nm and strip address maho libjpipe.dylib
Comment 4 sparcmoz 2006-09-28 15:08:48 UTC
Created attachment 39422 [details]
run nm and strip addresses on jim libjpipe.dylib
Comment 5 sparcmoz 2006-09-28 15:09:30 UTC
Created attachment 39423 [details]
diff -u the two nm libs
Comment 6 sparcmoz 2006-09-28 21:53:09 UTC
Created attachment 39430 [details]
verbose log when success
Comment 7 sparcmoz 2006-09-28 22:32:02 UTC
Another observation - when the failed test is run with a fresh installtion, then the 'First Start Wizard' runs 
and will do so until it is accepted and not cancelled. 
btw this is with 2.0.4rc2, so I will wait and see when 2.0.4 rc3 is released as that might be built on Xcode 
2.4
Comment 8 sparcmoz 2006-09-28 22:39:36 UTC
This may be related to the stripping issue? i will need to test by using files from solver (not done yet).
Comment 9 maho.nakata 2006-09-30 03:57:52 UTC
I'll switch from Xcode 2.2.1 to Xcode 2.4...
I belive it is safe, no backward compatiblities here.
Comment 10 sparcmoz 2006-10-01 12:57:01 UTC
While issue 68052 is fixed in rc3 (with Xcode 2.4) the SDK issue is not fixed. Further digging reveals the 
real cause of the problem: missing a symbolic link libjpipe.jnilib -> libjpipe.dylib
This link exists in my own build in jurt module and in solver, but is missing in both maho and my own 
installed product. Just add this link in the program folder and SDK examples run OK. I assume something 
is needed in scp2 to fix this?
Comment 11 eric.bachard 2006-10-06 23:36:22 UTC
ericb->sparcmoz

If you mean create a shortcut using scp2, scp2/souce/ooo/shortcut_ooo.scp should help, but I wonder if 
such symlink isn't created in deliver or using create-bundle.

I'll try to remember what we did (well known issue)
Comment 12 sparcmoz 2006-10-06 23:52:31 UTC
It is issue 44154. There are many such symlinks created by deliver but not in the installation. 
Comment 13 sparcmoz 2006-10-07 11:41:40 UTC
Created attachment 39623 [details]
add symlink for libjpipe.jnilib
Comment 14 florian 2007-01-12 20:37:10 UTC
fheckl -> sparcmoz
Has this been integrated yet? Anybody working on it?
Comment 15 sparcmoz 2007-01-14 10:35:54 UTC
sparcmoz -> fheckel: short answer - no. 
Long answer: 
(a) I only know that this link allows the boostrap to run. I do not understand
much about jnilib/dylib stuff and have no idea if this link has any possible bad
effects.
(b) Probably the same link should be needed for any library that uses java
native interface (JNI), but I have no investigated this yet.
(c) Strangely there are jnilib links created when files are delivered into
solver, but the same links are not packaged (by scp2)
(d) I have no time to work on this for a while anyway so I would be happy if you
or anyone else can fix this, thanks
Comment 16 florian 2007-01-14 22:15:41 UTC
OK, I'll take this one.
Comment 17 florian 2007-01-14 22:16:24 UTC
.
Comment 18 eric.bachard 2007-01-14 22:25:16 UTC
ericb->fheckl 

Is this issue very urgent ? IMHO native port is more urgent than Java at this time
Comment 19 Rob Weir 2013-07-30 02:47:31 UTC
Reset assignee on issues not touched by assignee in more than 1000 days.