Bugzilla – Full Text Bug Listing
| Summary: | Start building 64-bit cocoa | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kevin Barnes <cocoakevin> | ||||||||||||||||||||||||
| Component: | Releng | Assignee: | Kim Moir <kim.moir> | ||||||||||||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||||||||||||
| Severity: | normal | ||||||||||||||||||||||||||
| Priority: | P3 | CC: | acambrell+eclipsebugs, aniefer, antoine, grant_gayed, heath.borders, kim.moir, renanse, Silenio_Quarti, skovatch, snorthov | ||||||||||||||||||||||||
| Version: | 3.5 | ||||||||||||||||||||||||||
| Target Milestone: | 3.5 M4 | ||||||||||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||||||||||
| OS: | Mac OS X | ||||||||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||||||||
| Bug Depends on: | 255687 | ||||||||||||||||||||||||||
| Bug Blocks: | 239301 | ||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||
|
Description
Kevin Barnes
The launcher fragment org.eclipse.equinox.launcher.cocoa.macosx.x86_64 is in cvs, tagged and added to the map file. Kim, the features including both the swt and launcher fragments don't specify an arch for the 32 bit version (since they work on both x86 and ppc and lists aren't supported). I'm not sure what will happen when we add x86_64. If we are lucky, things would just work, however there is a chance of build breakage, or of the 32 bit ones showing up in the x86_64 zip. We might want to change the features to include the 32 bit versions twice: <include plugin="org.eclipse.swt.cocoa.macosx" ... arch="x86" /> <include plugin="org.eclipse.swt.cocoa.macosx" ... arch="ppc" /> <include plugin="org.eclipse.swt.cocoa.macosx.x86_64" ... arch="x86_64" /> Created attachment 118931 [details]
patch
Ran a test build today and encountered into some issues, still investigating. Created attachment 119059 [details]
other patchs
Created attachment 119060 [details]
patch
The test build failed with this
!MESSAGE Unsatisfied dependency: [org.eclipse.platform.feature.group 3.5.0.N20081128-0951-9M9SGC9FQEmMMjtsiiWkFHqkU3pYfOyf6CG43] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.equinox.security.macosx/[1.0.100.N20081128-0951,1.0.100.N20081128-0951]
!SUBENTRY 1 org.eclipse.equinox.p2.director 4 0 2008-11-28 15:54:06.964
!MESSAGE Unsatisfied dependency: [org.eclipse.platform.feature.group 3.5.0.N20081128-0951-9M9SGC9FQEmMMjtsiiWkFHqkU3pYfOyf6CG43] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.core.filesystem.macosx/[1.0.0.N20081128-0951,1.0.0.N20081128-0951]
~
The org.eclipse.core.filesystem.macosx fragment and equinox.security.macosx fragments in platform feature need to specify their arches, for both x86 and ppc, so the dependancies are satisfied when provisioning. Also, should the manifest for these fragments now include x86_64?
(In reply to comment #5) > > The org.eclipse.core.filesystem.macosx fragment and equinox.security.macosx > fragments in platform feature need to specify their arches, for both x86 and > ppc, so the dependancies are satisfied when provisioning. Also, should the > manifest for these fragments now include x86_64? > These fragments will need to compile new x86_64 versions before they can add it to the manifest. It is possible for these fragments to contain 1 library that will work on all 3 platforms, or the fragment could contain 2 libraries, one for x86/ppc and the other for x86_64. Just started another test build. Created attachment 119177 [details]
patch
Created attachment 119214 [details]
maser root patch
Created attachment 119228 [details]
changes to rcp feature
Created attachment 119261 [details]
director log
Andrew, I'm still having problems building the macosx.cocoa.x86_64 drops. Here is the the log from the nightly build. Any suggestions?
!ENTRY org.eclipse.equinox.p2.director 4 0 2008-12-01 22:55:13.372
!MESSAGE Problems resolving provisioning plan.
!SUBENTRY 1 org.eclipse.equinox.p2.director 2 0 2008-12-01 22:55:13.373
!MESSAGE Unable to satisfy dependency from org.eclipse.platform.sdk 3.5.0.N20081201-2011 to requiredCapability: toolingorg.eclipse.platform.sdk/org.eclipse.platform.sdk.config/[3.5.0.N20081201-2011,3.5.0.N20081201-2011].
!SUBENTRY 1 org.eclipse.equinox.p2.director 2 0 2008-12-01 22:55:13.373
!MESSAGE Unable to satisfy dependency from org.eclipse.platform.sdk.launcher.cocoa.macosx.x86_64 3.5.0.N20081201-2011 to requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.equinox.launcher.cocoa.macosx/0.0.0.
!SUBENTRY 1 org.eclipse.equinox.p2.director 4 0 2008-12-01 22:55:13.374
!MESSAGE No solution found because the problem in /tmp/p2Encoding54380.opb is unsatisfiable.
Created attachment 119494 [details]
log
I ran another test build again because I thought the issue where the simple.configurator required 3.4.0 of equinox.common might be the problem (this was moved to 3.5.0) on Tuesday. Anyways, the same result occurred. Andrew, do you have any suggestions on how to address this issue so the director will provision the macosx.cocoa.x86_64 bits correctly? The launchers appear to be specified correctly in the the rcp feature and their manifests look good in cvs.
The build dir is
/builds/N200812031031/
The repo is /builds/transfer/files/testUpdates-N on eclipsebuildserv.
Created attachment 119519 [details]
metadata.generator jar
There is a bug in the metadata generator which causes it to generate unsatisfiable metadata in this case. I have fixed it in HEAD, here is a jar you can try in your basebuilder.
Thanks Andrew, I'll start another test build shortly with the new generator + the latest bundles from this week's i-build. Created attachment 119576 [details]
log
Andrew, still seem to be having problems with the current test build with new I-build bundles plus metadata.generator jar.
build is /builds/N200812041539 same repo as before
Created attachment 119665 [details]
patch
The latest problem was due to a typo in the build.properties for the master-root feature. Running another test build now.
Released changes for tonight's build and tagged the features for Sunday's integration build. Kevin, please verify the content is as expected I should have said, that the test build was successful in the earlier comment. >Kevin, please verify the content is as expected
Where is the build?
A bug in our build file meant our "int /*long*/" weren't getting converted to "long /*int*". I've updated the build file. I'll test some more this afternoon. Eclipse.app is missing its icon and I get a ClassNotFoundException when launching java.lang.ClassNotFoundException: org.eclipse.core.runtime.adaptor.EclipseStarter at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:316) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:547) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:505) at org.eclipse.equinox.launcher.Main.run(Main.java:1237) I20081208-1351 looks good. closing. |