Bugzilla Bug 92606

Please find attached patch for eclipse-sdk 3.1 M7.

Created an attachment (id=58881) [details]
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 an attachment (id=59659) [details]
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 an attachment (id=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 an attachment (id=62081) [details]
Patch to fix small problems to correct build all native libraries

Created an attachment (id=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 an attachment (id=62108) [details]
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 ***