| Summary: | eclipse-sdk 3.1 M7 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Maik Schreiber <blizzy-keyword-gentoo_bugs3.075080> |
| Component: | New packages | Assignee: | Karl Trygve Kalleberg (RETIRED) <karltk> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | billy.biggs, danarmak, kfm, luckyduck |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
patch for eclipse-sdk 3.1 M7
Patch to eclipse build files to allow amd64 compilation on gentoo ebuild for eclipse-3.1rc4 for amd64 Patch to fix small problems to correct build all native libraries ebuild for eclipse-3.1rc4 for amd64&x86 Patch to fix small problems to correct build all native libraries |
||
|
Description
Maik Schreiber
2005-05-14 08:42:44 UTC
Created attachment 58881 [details, diff]
patch for eclipse-sdk 3.1 M7
Works fine for me :) The eclipse-3.1 script/symlink/whatever is missing, I have to call /usr/lib/eclipse-3.1/eclipse-gtk Maybe it is a good idea to place a symlink to this file... Sorry, could be that it doesn't installed eclipse-3.1 because I merged it from a portage overlay... I also succeeded with the posted ebuild and it seems that the restriction to a JDK < 1.5 is not necessary. I used sun-jdk-1.5.0.01 (by deleting the check) and found no problems so far. Of course, this has been added to portage now and is thus eligible for closure ;) The only thing that seems odd to me is that the jdk-1.4.x restriction is still in place. However, as Dominik states, it definitely *can* be built with jdk-1.5.x which is contrary to the message conveyed in the ebuild. Is there any good reason for this? Java 1.5 provides quite good backward compatibility with jdk 1.4. I don't see any point in those restrictions, if the compilation really doesn't complain about anything serious. There still seems to be that gcc 4.0-beta-restriction too (bug #92346). I have compiled it with the old gcc 3.x and it worked fine. Created attachment 59659 [details, diff]
Patch to eclipse build files to allow amd64 compilation on gentoo
After 2 weeks of fighting I finally managed to get eclipse 3.1M7 to build on
amd64. First I spent a week in trying to get the current ebuilds do something
that would run, but failed. Then I started from scratch and spent another week
trying to persuade the eclipse's own build system to allow compilation on
gentoo.
The current ebuilds seem to break too often so I think we should try to make
the ebuild just fix the eclipse build files instead of trying just shortcut and
run some of the targets (for example the current ebuild doesn't even try to
convert the java files from 32bit to 64bit support).
I believe that with very minor changes the eclipse can be built also on ppc and
x86.
The result is as follows:
Builds all native libraries that are also in the official binary build for
amd64:
libcore_3_1_0.so
libswt-pi-gtk-3135.so
libswt-awt-gtk-3135.so
libswt-gnome-gtk-3135.so
libswt-gtk-3135.so
libswt-atk-gtk-3135.so
libswt-cairo-gtk-3135.so
Also includes the embedded browser support not included in official binary
build:
libswt-mozilla-gtk-3135.so
Only the libupdate.so native library is not included, but updates are supposed
to be done using portage anyway. The official amd64 binary build wrongly has
the 32bit version.
To build do the following:
mkdir build.tmp; cd build.tmp
unzip DISTFILES/eclipse-sourceBuild-srcIncluded-3.1M7.zip
# remove all prebundled native libraries
find . -name "*.so" -print0 | xargs -0 rm -f
# fix a bunch of build problems
patch -p1 < FILES/eclipse-amd64.patch
# define paths to mozilla (firefox should also work nicely)
export GECKO_SDK=/usr/lib/mozilla
export GECKO_INCLUDES="-include ${GECKO_SDK}/include/mozilla-config.h
-I${GECKO_SDK}/include -I${GECKO_SDK}/include/nspr -I${GECKO_SDK}/include/xpcom
-I${GECKO_SDK}/include/string -I${GECKO_SDK}/include/embed_base"
export GECKO_LIBS="-L${GECKO_SDK} -L${GECKO_SDK}/components -lgtkembedmoz
-lxpcom -lxpcom_compat -lnspr4 -lplds4 -lplc4"
# compile the actual stuff
./build -os linux -ws gtk -arch x86_64 -compilelibs
With final release of 3.1 scheduled in less than a month, I am not going to spend time rewriting the ebuild yet again at this stage, I'm afraid. Your recipe for building eclipse will not work very well on most platforms, including amd64, because 1) it does not respect the ebuild USE flags, in particular mozilla, gnome 2) it will fail to find the JNI include files on (at least) the IBM JDK. 3) it will fail to find the necessary .jar files for the jsse on the IBM JDK. In fact, if you look closely, most of the complexity of the current ebuild comes from the fact that the eclipse build system was designed to work in a fixed environment: it is tailored to be built inside the build environment used by the Eclipse team, and only there. They have provided env var hooks for most parts, which is fine, but in our ebuild we have to inspect the system and customize these hooks. I'll ask Jan to have a peek, as he actually has an amd64:) This is already available on x86. Marking as amd64 I know that using the official eclipse horror build system is not easy, but neither is the current build system because the eclipse builds keeps changing it too often. As for USE flags, one of the patched files touches a makefile which controls the built packages (I add there the mozilla and cairo). It would be really easy to just patch it to be $(BUILD_NATIVE_PACKAGES_LIST) and then the build can define the correct values there before running the build. As for IBM jdk support I was hoping that IBM would have taken care of that because they do run it with IBM jdk. If not we can easily do a similar trick and either pass the correct paths to ant as system properties or then just patch the files. But in the end I do not care what way we get the build to work. I already promised in another bug for 3.1M5 to get the amd64 build working. I spent many nights on that one but never got anything that would even start. That's why I started to do it the other way around and now we at least have a package to compare to. And we can give -d -v parameters to the ant and look at the output to try to figure why the ebuilds are not working correctly. So here are some things that I found out while doing the eclipse build: libcore_3_1_0.so - needs the patch to lugins/org.eclipse.core.resources.linux/src/Makefile and then just run make - gives eclipse control over unix permissions and other stuff native java cannot do - packaged into org.eclipse.core.resources.linux_3.1.0.jar as os/linux/x86_64/libcore_3_1_0.so libupdate.so - the plugins/org.eclipse.update.core.linux/src/build.xml needs the patch to allow it to compile the library - packaged into org.eclipse.update.core.linux_3.1.0.jar as os/linux/x86_64/libupdate.so libswt-*.so - need the GECKO defines to be correct, but I that should be already handled better by the ebuild - targets that need to be run are make_swt make_atk make_gnome make_awt make_cairo make_mozilla - packaged into org.eclipse.swt.gtk.linux.x86_64_3.1.0.jar And one important thing that the 64bit builds are currently missing: - before building the SWT stuff the .java files must be edited with sed 's|int /*long*/|long|' found at replace.32.to.64 target in plugins/org.eclipse.swt.gtk.linux.x86_64/build.xml - and that only works for the SWT GTK, the other tookits do not support it yet One thing I do not know the answer to is that if we do not use the eclipse full build system, should we use the built-in compiler (ecj.jar) or do we want to build the eclipse with the normal JDK compiler or jikes. I think the current ebuilds use the ecj.jar but it's just a matter of removing a few checks from the build.xml files to allow compiling with non-eclipse compiler. Anyway, if someone has time to create amd64 ebuilds I'll be happy to test them. I no longer want to reverse engineer the eclipse build systems and implement them as ebuild as I have now currently my own build that I use which has even working browser embedding that the binary packages lack. Note that one reason the upstream build stuff keeps changing is in response to the large packaging efforts by Linux distributions. At least on the SWT team, we have tried to improve our make files to ensure that you guys don't need to maintain crazy patches. This is tricky to coordinate though, since anything we fix means that old build scripts you have will break, but I thought we were moving forward. If there are fixes which need to be made to build on amd64 that can be done upstream please file bugs at bugs.eclipse.org or just let me know and we can ensure they're done for 3.1. At least the following patches should be pushed upstream from my attached patch.
I hope the following have enough reasoning to help push them upward.
1) the patch for /build script
- the current ant versions want the classpath in LOCALCLASSPATH (I checked also
non-gentoo ant script from official ant build and it had the same thing)
2) first part of the patch for /build.xml
- clearly a typo what they had there
3) the full patch for /plugins/org.eclipse.core.resources.linux/build.xml
- without it the libcore.so is never built (eclipse does run without it but
logs a warning every time it starts that some functionality might not work
correctly)
- also fixes the hard coded x86 to be ${arch}
4) the patch for /plugins/org.eclipse.update.core.linux/src/build.xml
- fixes another hard coded x86 to be ${arch}
5) /plugins/org.eclipse.update.core.linux/src/build.xml
- fixes a third hard coded x86
- removes the -static from gcc line because newer gcc abort if given both
-shared and -static (and clearly we do want -shared)
> 1) the patch for /build script > - the current ant versions want the classpath in LOCALCLASSPATH https://bugs.eclipse.org/bugs/show_bug.cgi?id=96845 > 2) first part of the patch for /build.xml > - clearly a typo what they had there Already fixed: http://bugs.eclipse.org/bugs/show_bug.cgi?id=96764 > 3) the full patch for /plugins/org.eclipse.core.resources.linux/build.xml https://bugs.eclipse.org/bugs/show_bug.cgi?id=96842 > 4) the patch for /plugins/org.eclipse.update.core.linux/src/build.xml > 5) /plugins/org.eclipse.update.core.linux/src/build.xml https://bugs.eclipse.org/bugs/show_bug.cgi?id=96843 The changes to the SWT build I can probably just fix. I'll add the make_mozilla and make_cairo bits. Sorry they were missed. Mikko, can you comment on this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=96845 *** Bug 94333 has been marked as a duplicate of this bug. *** *** Bug 95855 has been marked as a duplicate of this bug. *** Created attachment 62079 [details]
ebuild for eclipse-3.1rc4 for amd64
I created a new eclipse ebuild that uses the eclipse build system with very
minor patching.
The good about the new ebuild:
- smaller, does not need to know as much about eclipse building internals
- works on amd64
- I also tried to make sure the following bugs have been corrected:
#95112, #95169, #96351, #91864
- fixes #94756 (can be reverted if needed)
The bad about the new ebuild:
- has not been tested on x86/ppc. any bug reports are very wellcome
- has only been built with sun jdk 5.0_04
- removes jikes support as it was only used to bootstrap the eclipse java
compiler anyway
Created attachment 62081 [details, diff]
Patch to fix small problems to correct build all native libraries
Created attachment 62107 [details]
ebuild for eclipse-3.1rc4 for amd64&x86
The new versions of ebuild fix problem with building amd64+ibm-jdk or
x86+non-ibm-jdk.
Created attachment 62108 [details, diff]
Patch to fix small problems to correct build all native libraries
Marking as duplicate of a new bug for 3.1 final; no need to have multiple bugs open. *** This bug has been marked as a duplicate of 97347 *** |
