Comment 1 Kim Moir 2005-02-03 13:12:03 EST

As a first step, please provide the patches to the source build scripts required
to compile solaris-gtk-x86.  The source build scripts force the recompilation of
the swt libraries and launcher if you specify the -compilelibs parameter when
running the build.  Here are the source build instructions for the latest
integration build.

http://download.eclipse.org
/downloads/drops/I20050202-0800/srcIncludedBuildInstructions.html

Also, please provide any patches as necessary to the launcher and swt build scripts.

Comment 2 Kyrill Alyoshin 2005-02-03 14:47:32 EST

I really don't have any patches. What I do is download SPARC version, and
recompile swt source there, put the two .so libraries instead of the SPARC ones.
And do the same for eclipse launcher file. It is that simple. I've been using it
for 6 months now, and eclipse works beautifully on Solaris x86.

Kyrill

Comment 3 Kim Moir 2005-02-03 15:32:11 EST

I'm sure that it is simple to recompile it. However, if it is not as an option
in the current source build scripts to recompile this configuration. If the
scripts indicate that it is an option, people will be more likely to use it :-)

Since you've already compiled it, I'm asking that you download a source build
and modify the build scripts so that it will support this configuration. Then we
can apply the patches to the repository and provide other people with the
ability to build this configuration.

We don't have the software to test this configuration in our lab.  Since you do,
it would be great if we could leverage your existing work and help others who
are interested in this port.

Comment 4 Kim Moir 2005-02-18 15:47:55 EST

Please reopen this bug when you have patches we can incorporate to build this
port of eclipse.

Comment 5 Kyrill Alyoshin 2005-02-24 09:57:29 EST

I understand your position. However I don't feel comfortable to start changing
Eclipse build scripts. I looked at them and they are quite involved. The
directory structure will also have to change to accomodate Solaris on x86
release. The most important thing is that any person with the knowledge of
Eclipse build process should be able to do that fairly quickly, whereas I would
have to spend days figuring it out. And the crucial thing is that if you can
build Eclipse on Solaris SPARC, which you obviously do, building it on Solaris
x86 is a just a simple recompile. Nothing would have to change, the source for
Solaris SPARC and x86 is identical. 
I can however offer access to Solaris x86 build machines. Anyway, all you need
is just a PC, you can load Solaris 10 on it, which is completely free, has quite
decent driver support, and comes with gcc compiler. If you need, I can mail you
installation CDs. 
Let's make it happen. 

Comment 6 Kim Moir 2005-02-28 11:53:32 EST

If you can provide the patches to the existing source build scripts we can
incorporate it into our source build scripts, that would be great.  Otherwise,
it will not be incorporated into the source builds.  We simply too busy at this
time.

With the eclipse platform project, the best way to ensure that a new platform
gets incoporated into a project is to provide a patch for it yourself so the
committers can test it and apply it to the code base.  For instance, Intel and
HP conpile ports for us that we do not have the hardware to test.  Otherwise, it
is inevitable that it will not be incorporated into a project until we have a
spare day to set find a spare lab machine, install the new platform, compile
eclipse and figure out how to change the build scripts so it works on the new
platform.  It may be easy to do so in theory, but at this time, we simply do not
have the time or resources to do so.  

I can help you out with any questions that you may have on the build scripts. 
Of if you feel that uncomfortable with the build scripts you may want to
solicite someone else who is interested in this port to help you out with this bug.

Comment 7 Kim Moir 2005-03-04 17:01:10 EST

I have assigned this bug the helpwanted keyword.  If people are interested in
testing the scripts for this port, they are welcome to provide patches.

Comment 8 Steve Northover 2005-05-20 11:00:36 EDT

*** Bug 6286 has been marked as a duplicate of this bug. ***

Comment 9 Chris Cheetham 2005-05-25 06:00:59 EDT

I've made patches to the 3.1M7 source tree.  With the exception of invoking Ant
targets, this initial pass seems usable for what I'd describe as typical Java
development; the Java and Synch(CVS) perspectives haven't displayed any errors.
 Prior to posting the patches, some clarification on the eclipse patch
submission process as well as any guidelines on items 2 and 3:

1: patches.  No patch guidelines jumped out at me after a quick site perusal. 
Presumably GNU patch is preferred.  Any guidelines on preferred switches,
invocation in general, where to post, etc?

2: accompanying SWT patches.  Made changes to the corresponding SWT source
zipfile.  Do the generated binaries simply get copied into the main eclipse
tree?  Required/recommended gcc versions?

3: "launcher" patches.  Same basic question as #2 but perhaps different in that
the launcher source is included in the main eclipse source zipfile.

Maybe I have these questions because I didn't use eclipse (chicken) to build
eclipse (egg).

Comment 10 Kim Moir 2005-05-26 14:44:43 EDT

The patches should be against the source build files scripts.  It would be
helpful if the patches could be against a newer source build that M7 as the
scripts were  changed significantly recently. For instance, using today's
I20050526-1200 build would be great.

I'm not aware of any eclipse.org patching guidelines.  Just do what you would
usually do to submit a patch.  Yes, the generated swt binaries get copied back
to the appropriate location. I haven't seen any versions of gcc that cause
problems, use whatever version you have on your box.

Comment 11 Chris Cheetham 2005-06-08 23:51:21 EDT

Created attachment 22661 [details]
patches to I20050527-1300 (eclipse, swt) for Solaris x86 gtk

Notes:
* Solaris 10, x86
* Sun JDK 1.5.0_03
* Ant 1.6.5
* Sun's gpatch (/usr/bin/gpatch) and gdiff (/opt/sfw/bin/gdiff) from CCD.

The swt patch is straightforward.  The eclipse patch as run below:

  gpatch -p1 < ../eclipse-I20050527-1300-solaris-gtk-x86.diff

fails presumably because of the spaces in a directory's name?  Regardless, only
one of the files fails to patch via the above command and thus it is explicitly
included in the attached tar file.

Comment 12 Ed Burnette 2005-07-16 23:03:08 EDT

It would be great to get Solaris x86 on the official builds list. This would
help RCP programs like Azureus (see the current workaround (source build
instructions) here: http://azureus.aelitis.com/wiki/index.php/AzureusForSolarisX86).

Comment 13 Kim Moir 2005-07-18 08:57:23 EDT

I'll ask if this platform is in the plans for 3.2.

Comment 14 Kim Moir 2005-08-05 15:50:49 EDT

Solaris 10 is in the plan, but for sparc

http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_2.html

Comment 15 Douglas Atique 2005-09-15 14:05:01 EDT

I have been looking at this problem. From what I have seen, it looks like
Solaris i386 is just a matter of some tweaking in the lots of build.xml files,
creating some *.source.solaris.gtk.i386 and *.source.solaris.motif.i386 plugin
directories and patching the launcher and swt build.sh and make_solaris.mak
files. Sometimes you have to open a file and add the solaris i386 equivalent
content to the solaris sparc that is already there, sometimes you have a file
specific for solaris sparc that you have to duplicate for solaris i386 and
sometimes there is a directory for solaris sparc you have to duplicate as
solaris i386. I have had progress with the 3.1 release, but I couldn't finish my
build yet. Even though the build generates the package, it won't run because
some jar is missing (and it is a very big source tree to look), but I have had
success with all the native swt and launcher builds, such as solaris gtk and
solaris motif. With the motif launcher, I had to tweak a little bit the
make_solaris.mak file to be able to compile it with gcc, as it was ready for Sun
compilers. As I succeed in doing my patch I will provide my patches, but I'm
afraid it will be lost work if future releases don't maintain that platform. So
what should be done so that Solaris i386 could be officially supported? Please
provide me some directions, as I really want to do it.

A specific question I have on this is: as I download a release, the swt and
launcher sources come archived in a zip file. To fix the files I have to unpack
these zip files, but if I don't pack the changes back to the zip file, it won't
work, as the build process unzips the sources to a launchertmp directory and
doesn't get my changes. What is the right way to do that so that my changes
won't be lost when I submit them? 
Cheers,
Doug

(In reply to comment #14)
> Solaris 10 is in the plan, but for sparc
> 
> http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_2.html

Comment 16 Kim Moir 2005-09-16 09:55:39 EDT

Pack the changes into zip file and attach the modified zip along with other
required patches to this bug.

Comment 17 Kim Moir 2005-09-16 11:54:30 EDT

*** Bug 107852 has been marked as a duplicate of this bug. ***

Comment 18 Douglas Atique 2005-10-07 06:18:18 EDT

Created attachment 28022 [details]
Differences to Eclipse release 3.1 sources to build under Solaris 10 x86 (or SPARC, for that matter) with gcc for both GTK and Motif

Contains new and modified files from Eclipse 3.1 that enable to build with gcc
in Solaris x86, both GTK and Motif. Prerequisites are gcc and make that come
with Solaris 10 and ant-1.6.5, all on your PATH.
Get Eclipse 3.1 release sources and unpack to a directory. Unpack this file
over that directory, merging it to the release sources (the files that were
modified will be overwritten by these, as well as some new files I've created).

Do cd to the base directory and build with the command
CLASSPATH=./ecj.jar ./build -os solaris -ws gtk -arch i386 -compilelibs
or 
CLASSPATH=./ecj.jar ./build -os solaris -ws motif -arch i386 -compilelibs

This build *will* fail. Don't despair. This is an unrelated bug which my
insufficient knowledge of ant couldn't fix.
Do cd to jdtcoresrc and do
CLASSPATH=./ecj.jar ant -buildfile compilejdtcorewithjavac.xml
It will build the ecj.jar files with javac.
Then in the same directory do
CLASSPATH=./ecj.jar ant -buildfile compilejdtcore.xml
This will build the ecj.jar with the other ecj.jar.
Do cd to the base directory.
Repeat the build command
CLASSPATH=./ecj.jar ./build -os solaris -ws gtk -arch i386 -compilelibs
or 
CLASSPATH=./ecj.jar ./build -os solaris -ws motif -arch i386 -compilelibs
It will (if everything is ok) build the eclipse release in the release
subdirectory.

Comment 19 Kim Moir 2005-10-07 09:55:56 EDT

regarding comment #18, if you would like these changes incorporated into the
source build scripts, it would be better if the files were diffs between the
original and modified files.  Also, since 3.1.x is only a maintenance stream
that is not being actively updated at this time, the patches should be against
3.2 stream builds.

Comment 20 Douglas Atique 2005-10-07 10:02:35 EDT

(In reply to comment #16)
> Pack the changes into zip file and attach the modified zip along with other
> required patches to this bug.

Please see my previous comment and the attachment. Is this enough? I am running
Eclipse 3.1 successfully on Solaris 10 x86 with both GTK and Motif and compiled
it with the gcc (sfw) that comes with Solaris 10.
Will someone support Solaris x86 as an official build? What should I do to help
this happen? I can redo the work I did for 3.1 for some newer release or for the
latest CVS sources, if needed. Let me know.

Comment 21 Douglas Atique 2005-10-07 12:51:25 EDT

(In reply to comment #19)
> regarding comment #18, if you would like these changes incorporated into the
> source build scripts, it would be better if the files were diffs between the
> original and modified files.  Also, since 3.1.x is only a maintenance stream
> that is not being actively updated at this time, the patches should be against
> 3.2 stream builds.

OK, I'll try to do the same to 3.2 as I have time. Let's hope I can finish it
before 3.3 comes out :-)

Comment 22 Kim Moir 2005-10-07 14:10:39 EDT

I apologize if my comments in comment #16 were ambiguous and confusing.

The best way to ensure that support for a port is included in the source build
is to provide diffs against the existing source build in the current development
stream.  Having a new download on the platform on the download page requires
approval of the PMC but providing patches to allow us to build it is the first step.

Comment 23 Iain MacDonnell 2005-12-18 01:50:57 EST

Incase it's worth anything, I'd like to add my vote for Solaris (10+) x86 (GTK)
becoming a supported platform...

Comment 24 Md. Zahangir Alam 2005-12-20 03:34:23 EST

Created attachment 32014 [details]
Here is a 'eclipse' launcher and 'org.eclipse.swt.gtk.solaris.sparc_3.1.1.jar' file works for Solaris 10x86

These files are built by Solaris 10 x86 for eclipse distribution.

Here is a simple and esiest detailed solution to get the Eclipse-3.1.1 for Solaris 10 x86 distribution. 

I have compiled and generated two files 
    1. 'eclipse' launcher of eclipse and 
    2. 'org.eclipse.swt.gtk.solaris.sparc_3.1.1.jar' for swt on Solaris 10 x86

Step-01: 
Now just compile the eclipse-3.1.1 source for sparc 
     $sh build -os solaris -ws gtk -arch sparc

There will be 'result' directory which will contain 'solaris-gtk-sparc-sdk.zip' file 

Step-02:
And then extract 'solaris-gtk-sparc-sdk.zip' into a directory like /usr/local/eclipse 

Step-03:
3.1 Copy My 'eclipse' launcher into /usr/local/eclipse/ directory
3.2 Replacing My 'org.eclipse.swt.gtk.solaris.sparc_3.1.1.jar' into /usr/local/eclipse/plugins/ directory

These two files are attached here. 

Step-04: And now just run
        $cd /usr/local/eclipse
        $./eclipse

That's all.

Follwing is the detailed and full procedure to generate eclipse distribution for solaris 10 x86 platform:


Prerequisites: 	1. apache-ant-1.6.5 
		2. eclipse-3.1.1 source. 

		Download 'apache-ant-1.6.5'  
		And then extracted in a directory (i.e. /usr/apache-ant-1.6.5) 
	
		Download eclipse-3.1.1 source. 	


Step 01: Set the following environment variables into $HOME/.profile file
	(i.e. $gedit $HOME/.profile)
	
	Write down following lines into this file:
	
	JAVA_HOME=/usr/j2se
	export JAVA_HOME

	ANT_HOME=/usr/apache-ant-1.6.5
	export ANT_HOME

	PATH=/usr/bin:/usr/ucb:/etc:.
	PATH=/usr/sfw/bin:$ANT_HOME/bin:$PATH
	export PATH

	And save this file.

Step 02:
	logout and then login into the system

Step 03:
	Now 
		3.1. Test your java is working on path (i.e. $java)
		3.2. Test that your java version is 1.5+ (i.e. $java -version)
		3.3. Test your ant is working on poth (i.e. $ant)
		3.4. Test your gcc is working on path (i.e. $gcc) 

	If all are working then your environment is ready to build the eclipse source. 

	In Solaris 10 installtion has already java 1.5+ and gcc on /usr/sfw/bin directory.
	Only ant has to donload and extract 

Step 04: Downloaded eclipse-3.1.1 source. This will come as named 'eclipse-sourceBuild-srcIncluded-3.1.1.zip'
	 Extract these sources in a directory 
				( i.e. 
				 $cp eclipse-sourceBuild-srcIncluded-3.1.1.zip $HOME/Projects/eclipse/		
				 $cd $HOME/Projects/eclipse					 
				 $unzip eclipse-sourceBuild-srcIncluded-3.1.1.zip)

Step 05: Correct the ant build script by writing 'build' file.
	(i.e. 
		$cd $HOME/Projects/eclipse
		$gedit build)
	
	Write the following lines into the first of this file.

	ANT_OPTS=-Xmx1000M
	export ANT_OPTS
	PWD=`pwd`
	export PWD

	Where is writen 'export ANT_OPTS=-Xmx1000M'. This was wrong for Solaris 10 x86 
	 

Step 06: Now build eclipse by following command

	$cd $HOME/Projects/eclipse
	$sh build -os solaris -ws gtk -arch sparc

	Notice: How it's got "sparc" instead of "x86"? Yep, leave it as sparc, 
	even though we're building for x86. If you put in x86 instead, 
	you'll get errors because it'll look for x86 versions of files 
	that aren't there, and using "sparc" does work for us.

	After this you should get a message saying the build was successful, and 
	there will be a "result" subdirectory with a file in it called "solaris-gtk-sparc-sdk.zip". 
	That's the main part of our Solaris x86 built Eclipse. 	

Step 07: Extract the 'solaris-gtk-sparc-sdk.zip' somewhere.
	(i.e. /usr/local/eclipse)
 	
	(example:
		$cd $HOME/Projects/eclipse/result
		$cp solaris-gtk-sparc-sdk.zip /usr/local
		$cd /usr/local
		$unzip solaris-gtk-sparc-sdk.zip
	You will see that there is a folder named 'eclipse')

Step 08: Copy My 'eclipse' file to the extracted eclipse directory
	(i.e. $cp eclipse /usr/local/eclipse/)

	This is the eclipse launcher generated by x86	

Step 09: Replace the 'org.eclipse.swt.gtk.solaris.sparc_3.1.1.jar' jar file into the location of
	 ~/eclipse/plugins/ directory. 

	(i.e. $cp org.eclipse.swt.gtk.solaris.sparc_3.1.1.jar /usr/local/eclipse/plugins/)

	These are the shared library generated by x86 for swt 

Step 10: Run the eclipse the following command

	$./eclipse

	(i.e.
		1. $cd /usr/local/eclipse
		2. $./eclipse)

	That's all.


Its working fine.

Have a good time!

Comment 25 Iain MacDonnell 2005-12-20 03:51:45 EST

Here's the procedure I've used to build on Solaris 10 x86 (using Sun Studio 11,
and ant 1.6.5). This is rather brute-force, but it results in a clean and almost
complete build. The only problem is that it doesn't copy the 'eclipse' launcher
binary into the 'result' zip file (even though it gets built in launchertmp) and
I have to run it with "./eclipse -arch x86". Haven't figured out those last two
bits yet.

I've used this procedure with 3.1.1 and a recent 3.2 snapshot.


export ANT_HOME=~/ant
export JAVA_HOME=/usr/j2se
export CDE_HOME=/usr/dt
export SS_HOME=/opt/SUNWspro

export PATH=$ANT_HOME/bin:$JAVA_HOME/bin:$SS_HOME/bin:/usr/sfw/bin:/opt/sfw/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/dt/bin:/usr/X/bin:/usr/ccs/bin

export CC=cc

mkdir eclipse-sourceBuild-srcIncluded-I20051213-0010
cd eclipse-sourceBuild-srcIncluded-I20051213-0010
unzip -qq ../eclipse-sourceBuild-srcIncluded-I20051213-0010.zip

mv ./plugins/org.eclipse.platform.source.solaris.gtk.sparc ./plugins/org.eclipse.platform.source.solaris.gtk.x86
mv ./plugins/org.eclipse.platform.source.solaris.motif.sparc ./plugins/org.eclipse.platform.source.solaris.motif.x86
mv ./plugins/org.eclipse.rcp.source.solaris.motif.sparc ./plugins/org.eclipse.rcp.source.solaris.motif.x86
mv ./plugins/org.eclipse.jdt.source.solaris.gtk.sparc ./plugins/org.eclipse.jdt.source.solaris.gtk.x86
mv ./plugins/org.eclipse.pde.source.solaris.motif.sparc ./plugins/org.eclipse.pde.source.solaris.motif.x86
mv ./plugins/org.eclipse.swt.motif.solaris.sparc ./plugins/org.eclipse.swt.motif.solaris.x86
mv ./plugins/org.eclipse.jdt.source.solaris.motif.sparc ./plugins/org.eclipse.jdt.source.solaris.motif.x86
mv ./plugins/org.eclipse.pde.source.solaris.gtk.sparc ./plugins/org.eclipse.pde.source.solaris.gtk.x86
mv ./plugins/org.eclipse.rcp.source.solaris.gtk.sparc ./plugins/org.eclipse.rcp.source.solaris.gtk.x86
mv ./plugins/org.eclipse.swt.gtk.solaris.sparc ./plugins/org.eclipse.swt.gtk.solaris.x86
mv ./features/org.eclipse.platform.launchers/bin/gtk/solaris/sparc ./features/org.eclipse.platform.launchers/bin/gtk/solaris/x86
mv ./features/org.eclipse.platform.launchers/bin/motif/solaris/sparc ./features/org.eclipse.platform.launchers/bin/motif/solaris/x86

mv ./assemble.org.eclipse.sdk.solaris.motif.sparc.xml ./assemble.org.eclipse.sdk.solaris.motif.x86.xml
mv ./assemble.org.eclipse.sdk.solaris.gtk.sparc.xml ./assemble.org.eclipse.sdk.solaris.gtk.x86.xml

perl -pi -e 's/sparc/x86/g' assemble.*.xml build **/build.xml **/build.sh **/*build.properties **/MANIFEST.MF **/.project **/feature.xml **/*.args

bash build -os solaris -ws gtk -arch x86 -compilelibs

Comment 26 Andrew Stepanenko 2005-12-21 15:30:11 EST

Hello Zahangir,

your aproach worked for me. Now I can run eclipse 3.1.1 on my Solaris 10 x86 Express box:)

Thank you.

(In reply to comment #24)
> Created an attachment (id=32014) [edit]
> Here is a 'eclipse' launcher and 'org.eclipse.swt.gtk.solaris.sparc_3.1.1.jar'
> file
> 
> These files are built by Solaris 10 x86 for eclipse distribution.
> 
> Here is a simple and esiest detailed solution to get the Eclipse-3.1.1 for
> Solaris 10 x86 distribution. 
> 
> I have compiled and generated two files 
>     1. 'eclipse' launcher of eclipse and 
>     2. 'org.eclipse.swt.gtk.solaris.sparc_3.1.1.jar' for swt on Solaris 10 x86
> 
> Step-01: 
> Now just compile the eclipse-3.1.1 source for sparc 
>      $sh build -os solaris -ws gtk -arch sparc
> 
> There will be 'result' directory which will contain 'solaris-gtk-sparc-sdk.zip'
> file 
> 
> Step-02:
> And then extract 'solaris-gtk-sparc-sdk.zip' into a directory like
> /usr/local/eclipse 
> 
> Step-03:
> 3.1 Copy My 'eclipse' launcher into /usr/local/eclipse/ directory
> 3.2 Replacing My 'org.eclipse.swt.gtk.solaris.sparc_3.1.1.jar' into
> /usr/local/eclipse/plugins/ directory
> 
> These two files are attached here. 
> 
> Step-04: And now just run
>         $cd /usr/local/eclipse
>         $./eclipse
> 
> That's all.
> 
> Follwing is the detailed and full procedure to generate eclipse distribution
> for solaris 10 x86 platform:
> 
> 
> Prerequisites:  1. apache-ant-1.6.5 
>                 2. eclipse-3.1.1 source. 
> 
>                 Download 'apache-ant-1.6.5'  
>                 And then extracted in a directory (i.e. /usr/apache-ant-1.6.5) 
> 
>                 Download eclipse-3.1.1 source.  
> 
> 
> Step 01: Set the following environment variables into $HOME/.profile file
>         (i.e. $gedit $HOME/.profile)
> 
>         Write down following lines into this file:
> 
>         JAVA_HOME=/usr/j2se
>         export JAVA_HOME
> 
>         ANT_HOME=/usr/apache-ant-1.6.5
>         export ANT_HOME
> 
>         PATH=/usr/bin:/usr/ucb:/etc:.
>         PATH=/usr/sfw/bin:$ANT_HOME/bin:$PATH
>         export PATH
> 
>         And save this file.
> 
> Step 02:
>         logout and then login into the system
> 
> Step 03:
>         Now 
>                 3.1. Test your java is working on path (i.e. $java)
>                 3.2. Test that your java version is 1.5+ (i.e. $java -version)
>                 3.3. Test your ant is working on poth (i.e. $ant)
>                 3.4. Test your gcc is working on path (i.e. $gcc) 
> 
>         If all are working then your environment is ready to build the eclipse
> source. 
> 
>         In Solaris 10 installtion has already java 1.5+ and gcc on /usr/sfw/bin
> directory.
>         Only ant has to donload and extract 
> 
> Step 04: Downloaded eclipse-3.1.1 source. This will come as named
> 'eclipse-sourceBuild-srcIncluded-3.1.1.zip'
>          Extract these sources in a directory 
>                                 ( i.e. 
>                                  $cp eclipse-sourceBuild-srcIncluded-3.1.1.zip
> $HOME/Projects/eclipse/          
>                                  $cd $HOME/Projects/eclipse                     
>                                  $unzip
> eclipse-sourceBuild-srcIncluded-3.1.1.zip)
> 
> Step 05: Correct the ant build script by writing 'build' file.
>         (i.e. 
>                 $cd $HOME/Projects/eclipse
>                 $gedit build)
> 
>         Write the following lines into the first of this file.
> 
>         ANT_OPTS=-Xmx1000M
>         export ANT_OPTS
>         PWD=`pwd`
>         export PWD
> 
>         Where is writen 'export ANT_OPTS=-Xmx1000M'. This was wrong for Solaris
> 10 x86 
> 
> 
> Step 06: Now build eclipse by following command
> 
>         $cd $HOME/Projects/eclipse
>         $sh build -os solaris -ws gtk -arch sparc
> 
>         Notice: How it's got "sparc" instead of "x86"? Yep, leave it as sparc, 
>         even though we're building for x86. If you put in x86 instead, 
>         you'll get errors because it'll look for x86 versions of files 
>         that aren't there, and using "sparc" does work for us.
> 
>         After this you should get a message saying the build was successful,
> and 
>         there will be a "result" subdirectory with a file in it called
> "solaris-gtk-sparc-sdk.zip". 
>         That's the main part of our Solaris x86 built Eclipse.  
> 
> Step 07: Extract the 'solaris-gtk-sparc-sdk.zip' somewhere.
>         (i.e. /usr/local/eclipse)
> 
>         (example:
>                 $cd $HOME/Projects/eclipse/result
>                 $cp solaris-gtk-sparc-sdk.zip /usr/local
>                 $cd /usr/local
>                 $unzip solaris-gtk-sparc-sdk.zip
>         You will see that there is a folder named 'eclipse')
> 
> Step 08: Copy My 'eclipse' file to the extracted eclipse directory
>         (i.e. $cp eclipse /usr/local/eclipse/)
> 
>         This is the eclipse launcher generated by x86   
> 
> Step 09: Replace the 'org.eclipse.swt.gtk.solaris.sparc_3.1.1.jar' jar file
> into the location of
>          ~/eclipse/plugins/ directory. 
> 
>         (i.e. $cp org.eclipse.swt.gtk.solaris.sparc_3.1.1.jar
> /usr/local/eclipse/plugins/)
> 
>         These are the shared library generated by x86 for swt 
> 
> Step 10: Run the eclipse the following command
> 
>         $./eclipse
> 
>         (i.e.
>                 1. $cd /usr/local/eclipse
>                 2. $./eclipse)
> 
>         That's all.
> 
> 
> Its working fine.
> 
> Have a good time!
> 
> 
> 
> 
> 
> 

Comment 27 Justin Clift 2006-03-13 04:01:31 EST

Hi,

Which is the very best build for me to create a patch set against, so Solaris x86 support can be added into the main source?

I've already done it with 3.0.2 and 3.1.2 for private use, so I might as well do it again for the very latest integration build (would latest CVS be better?) and provide the patches here.

Regards and best wishes,

Justin Clift

Comment 28 Kim Moir 2006-03-14 17:36:04 EST

It is always best to provide patches against the latest integration build.  However, given that we are approaching M6, it is unlikely that the patches will be applied. When the 3.3 project plan comes out, be sure to comment on the eclipse-dev mailing list that you would like this platform included.

http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_2.html

Comment 29 Justin Clift 2006-03-15 01:25:17 EST

Thanks Kim.

Will do.

Regards and best wishes,

Justin Clift

Comment 30 Ed Burnette 2006-03-15 08:42:36 EST

Patches have been available for almost 10 months. Solaris x86 is a very important platform and its popularity was not anticipated at the time the 3.2 plan was first started. Please appeal this to the PMC and help get it into 3.2 and Callisto.

Comment 31 Kim Moir 2006-03-15 11:01:23 EST

We always prioritize our bugs because we will always too many requests for enhancement and not enough time or people to fix them.  This is the reality of open source.

This bug was not a high priority for us because it is not listed as a reference platform in the project plan.  The releng team is not a PMC lobby group for including more stuff in the platform :-)If you want to include a new platform as an official build, not just in the source build, you should comment on the project plan when it is updated and sent to eclipse-dev for comment and ask that this platform be included.  If you submit libraries to the build as is done for motif.hpux.ia64_32 and gtk.linux.ia64 this is even better because you are taking ownership.

To be honest, it is the end of the release cycle and we have an enormous amount of work to do and very little time left.  

Comment 32 Douglas Atique 2006-03-15 11:39:12 EST

(In reply to comments #30 and #31)
There have been quite a few attempts to support Solaris x86 but I think we all have missed one point. We usually worked in an already released version and that work was only valid for that release because it was not incorporated to the main development stream. In the process I learned that it must be done in the latest sources and Solaris x86 support must add to Solaris SPARC, not break it and certainly not make it vanish. It is not an easy job and there are too many details for those who don't know the Eclipse development and build process. I did the patching on release 3.1 source tarball and it worked quite well, both for GTK and for Motif. Even though my changes were not incorporated into the sources, the patch is attached to this page for anyone that wants to build upon it. Since then, some people have asked me to send them the binaries and I even uploaded them to one or two. Now I am in a tight schedule, but in the future I will try it again if no one has done it yet. But beware, this job shouldn't be taken lightly.
It would help a lot if someone would collect information on the details of the Eclipse build process as well as CVS access rules and placed a comment about all that on this page. When we come back to do it, the information will be very useful.
-- Douglas

Comment 33 Ernesto Celis 2006-04-12 04:15:32 EDT

Today I was tryng to build the I20060331-2000 drop without success. The guidelines to build a port are not very accurate to my understanding and Google is not very useful. It is late and I'm going to sleep, tomorrow I will look to the Douglas patches to see if this can work for this I20060331-2000. If not, I will be asking to eclipse-dev mailing list for some hints to get this done.

Comment 34 Douglas Atique 2006-04-13 09:30:57 EDT

No, no, no! Don't use my patches against I2006-0331-2000 or any other development snapshot. AFAIK my patches will work only for release 3.1. If that's enough for you, it should work well.
-- Douglas

(In reply to comment #33)
> Today I was tryng to build the I20060331-2000 drop without success. The
> guidelines to build a port are not very accurate to my understanding and Google
> is not very useful. It is late and I'm going to sleep, tomorrow I will look to
> the Douglas patches to see if this can work for this I20060331-2000. If not, I
> will be asking to eclipse-dev mailing list for some hints to get this done.
> 

Comment 35 Suresh Raju 2006-05-11 11:08:55 EDT

Created attachment 41128 [details]
An output of the diff cmd between the original and changed source files.

Comment 36 Justin Clift 2006-05-11 11:27:56 EDT

Hi Suresh,

Thanks for that.  It's that much closer.  :)

The version you've included (haven't tried it, only scanned over the first part) doesn't appear to include Motif support.  Did I get that wrong?

If it doesn't, would you be able to include it?  I use the GTK version as well, but heck, if we can include the Motif version to that would be great.

:)

Regards and best wishes,

Justin Clift

Comment 37 Suresh Raju 2006-05-11 12:05:32 EDT

Created attachment 41149 [details]
Additional source directories and xml files for solaris gtk i386

Comment 38 Kim Moir 2006-05-11 15:15:26 EDT

Thanks Suresh.  We intend to incorporate the source build changes to support solaris-gtk-x86.

Since you are intending to use the releng source build to contribute this build to eclipse.org, I've asked the webmasters to create a  org.eclipse.swt.gtk.solaris.x86 project in CVS.  Once this has been created, we'll incorporate the changes to the source build.  Subsquently, we'll have a vote for your commit rights on this fragment.

You are also welcome to contribute a org.eclipse.core.filesystem.solaris if you are interested.  See bug 12358. We have done this in the past for HPUX specific fragments and are happy to do so for other operating systems.

Steve, Kevin, Jeff please provide your vote for inclusion of solaris-gtk-x86 source build support into RC4.

Comment 39 Jeff McAffer 2006-05-11 15:23:49 EDT

Great.  +1

I also encourage you to produce a solaris x86 version of the filesystem fragment.  If you are interested in contributing such a thing, perhaps we can get a similar fragment dir created in the repo.

Comment 40 Kevin Haaland 2006-05-11 15:54:18 EDT

++1 

Comment 41 Steve Northover 2006-05-11 16:32:33 EDT

+1

Comment 42 Kim Moir 2006-05-11 17:13:25 EDT

I've made the changes for the 8pm RC4 build.

Suresh, I changed your the architecture you specified from i386 to x86 as is the eclipse convention.  

Comment 43 Kim Moir 2006-05-12 08:32:04 EDT

Suresh, I've verified that the required scripts are in the 8pm build.  Please download

http://download.eclipse.org/eclipse/downloads/drops/I20060511-2000/eclipse-sourceBuild-srcIncluded-I20060511-2000.zip

and verify that you can build solaris-gtk-x86 using these scripts

You should run the source build with these arguments

./build -os solaris -ws gtk -arch x86 -compilelibs -java5home <path_to_jdk15>

If additional patches are required, please attach them to this bug.

Comment 44 Iain MacDonnell 2006-05-13 00:52:13 EDT

BUILD SUCCESSFUL
Total time: 16 minutes 30 seconds
/export/stuff/ws/eclipse/eclipse-sourceBuild-srcIncluded-I20060511-2000% uname -a
SunOS ... 5.10 Generic_118844-27 i86pc i386 i86pc
/export/stuff/ws/eclipse/eclipse-sourceBuild-srcIncluded-I20060511-2000%

Woohoo! Build works for me ;)



One small problem - when I try to run the GUI, though - it thinks I'm on SPARC:


!SESSION 2006-05-12 21:52:31.831 -----------------------------------------------
eclipse.buildId=I20060511-2000
java.version=1.5.0_04
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=solaris, ARCH=sparc, WS=gtk, NL=en_US
Command-line arguments:  -os solaris -ws gtk -arch sparc

!ENTRY org.eclipse.osgi 4 0 2006-05-12 21:52:35.938
!MESSAGE An error occurred while automatically activating bundle org.eclipse.ui.workbench (15).
!STACK 0
org.osgi.framework.BundleException: The activator org.eclipse.ui.internal.WorkbenchPlugin for bundle org.eclipse.ui.workbench is invalid
...etc...

if I tell it '-arch x86', it runs OK.

I had this problem with my own hacked builds on x86 before .. never figured out why...

Comment 45 Justin Clift 2006-05-14 07:56:43 EDT

Hmmm, well as this stuff is going to be included in RC4 rather than having to go through a complete new release, we should probably make sure things are working rather than not.

The recent problem mentioned, of Eclipse thinking it's on sparc rather than x86 (once compiled) is fixable.  I remember having that exact same problem when I did a first port of 3.0.x (3.0.2?) way back when, and couldn't be bothered taking a lot of time and effort.  It led to bad problems though (sparc versions of compiled packages would download, not good), so I had to go back and do it again properly, taking a decent amount of effort.

For my recent recent 3.1.1 build, I took the approach of doing a recursive grep for the word "sparc" (and or "solaris" I don't remember exactly), then generated a list of "sparc" files that needed an x86 equivalent, copied them across, changed the references, included these files alongside the sparc listings and it all worked out of the box.

I remember having trouble building the slash screen, but got around that eventually too.  The splash screen was the hardest bit from memory, the rest was easy, just time consuming.

Anyway, I digress.. ;)

Regards and best wishes,

Justin Clift

Comment 46 Iain MacDonnell 2006-05-14 14:49:52 EDT

Created attachment 41417 [details]
Patch for build.sh scripts to detect processor type on Solaris

With this patch, the build.sh scripts will detect whether they're on SPARC or x86, and set the "default OS arch" accordingly. It appears that these build.sh scripts are contained within at least one zip file (plugins/org.eclipse.platform/launchersrc.zip) - someone with better knowledge of the source structure needs to apply the patch in any other appropriate places...

Comment 47 Kim Moir 2006-05-15 13:53:59 EDT

regarding comment #44 and comment #46

Before starting the build, did you set these environment variables

# This makefile expects the following environment variables set:
#
# DEFAULT_OS      - the default value of the "-os" switch
# DEFAULT_OS_ARCH - the default value of the "-arch" switch
# DEFAULT_WS      - the default value of the "-ws" switch

to solaris, x86 and gtk respectively 

as specified in features/org.eclipse.platform.launchers/library/gtk/make_solaris.mak

Comment 48 Iain MacDonnell 2006-05-15 14:01:48 EDT

(In reply to comment #47)
> regarding comment #44 and comment #46
> 
> Before starting the build, did you set these environment variables
> 
> # This makefile expects the following environment variables set:
> #
> # DEFAULT_OS      - the default value of the "-os" switch
> # DEFAULT_OS_ARCH - the default value of the "-arch" switch
> # DEFAULT_WS      - the default value of the "-ws" switch

Erm, that's what build.sh does!?!

Comment 49 Kim Moir 2006-05-15 17:05:49 EDT

Grant, could you review the patch in comment #46 since they are for your build scripts.

Comment 50 Suresh Raju 2006-05-16 02:26:51 EDT

(In reply to comment #49)
> Grant, could you review the patch in comment #46 since they are for your build
> scripts.
> 

Also, if gcc is being used instead of cc then the -K PIC flag should be replaced by -fPIC.  I had to make the change in make_solaris.mak before building it.  I'm not sure if this should go in as a patch.

Comment 51 Grant Gayed 2006-05-16 16:28:05 EDT

The changes in comment 46 look good, so I've committed them to HEAD with minor modification.  There is no change needed for the swt libraries.

Comment 50 applies to both the launcher and the swt libraries.  Given this and eclipse's late stage, it is preferrable to not make compiler switch changes (-fPIC vs. -fPIC on linux) until post-3.2.

Comment 52 Grant Gayed 2006-05-16 16:29:12 EDT

(I meant -fPIC vs. -fpic)

Comment 53 Kim Moir 2006-05-17 17:26:30 EDT

Suresh has built a solaris-gtk-x86 drop for 3.2RC4 which is now available 

http://download.eclipse.org/eclipse/downloads/drops/S-3.2RC4-200605121600/index.php

Thanks Suresh for your contribution!

Comment 54 Suresh Raju 2006-05-19 09:20:45 EDT

(In reply to comment #51)
> The changes in comment 46 look good, so I've committed them to HEAD with minor
> modification.  There is no change needed for the swt libraries.
> 
> Comment 50 applies to both the launcher and the swt libraries.  Given this and
> eclipse's late stage, it is preferrable to not make compiler switch changes
> (-fPIC vs. -fPIC on linux) until post-3.2.
> 

(In reply to comment #51)
> The changes in comment 46 look good, so I've committed them to HEAD with minor
> modification.  There is no change needed for the swt libraries.
> 
> Comment 50 applies to both the launcher and the swt libraries.  Given this and
> eclipse's late stage, it is preferrable to not make compiler switch changes
> (-fPIC vs. -fPIC on linux) until post-3.2.
> 

I downloaded abd built eclipse.  I still need to launch eclipse by passing the -arch with x86.  Correct me if 'm wrong -- wasn't the fix supposed to address that issue?

Comment 55 Grant Gayed 2006-05-19 09:54:21 EDT

Yes, this change did not get tagged.  There will be an RC5 rebuild happening soon, so it will be picked up then.

Comment 56 Sonia Dimitrov 2006-05-31 16:21:31 EDT

I believe this is fixed.  Closing.

Comment 57 Rutger Ovidius 2006-07-04 09:28:35 EDT

Is there any plan for a 3.2 final binary build of solaris-x86 to be made available from eclipse.org?


http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.gtk.solaris.x86/

Looks empty.

Comment 58 Kim Moir 2006-07-05 09:57:19 EDT

They will be available soon, I have just advised them of the build to base the 3.2 build on which is M20060629-1905. This drop is not produced as part of the build.

Comment 59 Donald H Locker 2006-11-01 21:20:14 EST

I still don't see a Solaris-x86 binary.  Any activity in this area?

(In reply to comment #58)
> They will be available soon, I have just advised them of the build to base the
> 3.2 build on which is M20060629-1905. This drop is not produced as part of the
> build.
> 

(In reply to comment #58)
> They will be available soon, I have just advised them of the build to base the
> 3.2 build on which is M20060629-1905. This drop is not produced as part of the
> build.
> 

Comment 60 Kim Moir 2006-11-01 22:05:43 EST

For 3.2, the solaris-gtk-x86 binary is here under Eclipse SDK

http://download.eclipse.org/eclipse/downloads/drops/R-3.2-200606291905/index.php

Comment 61 Sriram Narayanan 2006-11-02 10:21:49 EST

I'd like to build Eclipse for Solaris x86. Which list do I be a part of, and where would I find instructions for this ? I'm stuck with trying to build Firefox/Mozilla on Solaris/OpenSolaris x86, and would really appreciate any instructions/pointers in this direction.

Comment 62 Grant Gayed 2006-11-02 10:52:43 EST

re: comment 61
Instructions for building mozilla-based browsers can be found at http://developer.mozilla.org/en/docs/Build_Documentation .  However note that support is not currently in the swt Browser widget for using a native browser on solaris, so building mozilla will not help you with the eclipse effort.

Comment 63 Donald H Locker 2006-11-02 22:20:32 EST

Thank you for the link, Kim.  All my searches didn't turn up this page.  I downloaded and installed; seems to work as it should, though I haven't (and maybe won't really) stress test it.

Thanks again!

(In reply to comment #60)
> For 3.2, the solaris-gtk-x86 binary is here under Eclipse SDK
> 
> http://download.eclipse.org/eclipse/downloads/drops/R-3.2-200606291905/index.php
> 

Comment 64 Thorbjørn Ravn Andersen 2007-01-02 05:18:24 EST

There is no binary for 3.2.1, only for 3.2.

Is there any particular reason for this?

Comment 65 Kim Moir 2007-01-02 09:20:14 EST

Sun contributes builds and contributes the binary for solaris-gtk-x86.  They contributed one for 3.2 there isn't one available for 3.2.1.  Suresh, are you planning  to contribute a build for 3.2.1 or 3.2.2?  (3.2.2 is scheduled to be released with the Callisto maintenance stream in mid February)

Comment 66 Iain MacDonnell 2007-01-05 21:26:25 EST

(In reply to comment #65)
> Sun contributes builds and contributes the binary for solaris-gtk-x86.  They
> contributed one for 3.2 there isn't one available for 3.2.1.

I'd be willing to contribute a 3.2.1 build, but I have a stupid question first...

I built from the 3.2.1 eclipse-sourceBuild-srcIncluded-3.2.1.zip, using command:

./build -os solaris -ws gtk -arch x86 -compilelibs -java5home /usr/jdk/instances/jdk1.5.0

The build succeeded, but what I end up with (in the result directory) identifies itself as:

Eclipse Platform
Version 3.2.0
Build id: M20060921-0945


whereas the pre-build Solaris/SPARC version identifies as:

Eclipse SDK
Version 3.2.1
Build id: M20060921-0945


Is there something different I need to do to build the SDK instead of (/as well as?) the "Platform" ???

Comment 67 Kim Moir 2007-01-18 17:31:03 EST

Regarding comment #66, don't worry about it, I think there was a bug regarding that issue that has since been fixed in the 3.2.2 stream.

Comment 68 Ricky Ng-Adam 2007-01-19 10:17:00 EST

Just like to point out newly opened bug #170544 for those interested in not just source support but helping out for binary builds.  Thanks.

Comment 69 Martin Oberhuber 2007-05-02 05:05:38 EDT

Anyone interested in a Solaris x86 build of Eclipse may want to know that there is currently no native liblocalfile for Solaris x86 checked in. For more details, see bug 170544#c23.

Comment 70 Douglas Atique 2007-11-26 20:16:59 EST

Hi Kim,
I have been checking the latest posts for bug 84344 and it seems that since 2005 not much has been accomplished in Solaris x86 becoming an official build (or even support being provided for whoever wants to build from sources).

I have downloaded 3.3.1.1 source dist and there seems to be more difficult to arrange for Eclipse to build now than back in 3.1.1 when I succeeded by recreating several build configuration files from their sparc counterparts.

Though some blog I've read mentions that there is a committer from Sun working to provide Solaris x86 support, it looks as if there has been no progress there.

Honestly, I'd like to help, but I have limited knowledge about the Eclipse build process, and what seems most difficult is the plugins that have native code. From 3.1.1 there seems to be at least two more native SOs to be built. And though the SWT and launcher both have a build.sh and make_solaris.mak to build correctly for the platform they detect, these new SOs (liblocalfile and the native code in org.eclipse.update.core.linux plugin -- by the way, how come the build on Solaris try to build a plugin with linux in its name?) have much cruder build support.

To make it short, I would like to be able to separate the parts of the build that are platform-dependent so that I could make them independently (or provide 100% pure Java replacements to ease the port) and that means I need to know which plugins or modules are native and which are just Java. Do you have a list of all native code plugins that are required to make a working distribution?

Moreover, if I wanted to resume this work I have once done for 3.1.1 in the current development stream and contribute it, do I need to become a committer? Or can I provide the sources to some "sponsor" committer that will do that for me?

And finally, two newbie questions I would appreciate your help with:
1. what is the canonical process to do a contribution? I mean if I wanted to build it for myself I would grab the sources for the latest release, patch them until they worked and that's all (that's what I did with 3.1.1), but if I want my work to be useful for future releases how should I do it?
2. there are features and plugins, and I used to think that features are aggregates of plugins and do not contain code themselves; however in 3.3.1.1 there is native code inside the features directory (namely org.eclipse.equinox.executable), so what is the difference between features and plugins?

Cheers,
Douglas

Comment 71 Martin Oberhuber 2007-11-27 07:07:01 EST

FYI, liblocalfile is not a required native library. Eclipse works fine if you don't have it. Only thing you get when you have it, is support for detecting symbolic links in the workspace.

Comment 72 Kim Moir 2007-11-27 14:25:22 EST

Regarding comment #70

There are two mandatory platform dependant pieces
org.eclipse.equinox.launcher.ws.os.arch
org.eclipse.swt.ws.os.arch

There are also optional fragments for the following
org.eclipse.update.core
org.eclipse.core.filesystem
org.eclipse.core.resources

There is a document that describes the process to contribute a port here...
http://wiki.eclipse.org/Platform-releng-faq#I_would_like_to_recompile_eclipse_on_a_platform_that_is_not_currently_supported._What_is_the_best_approach_to_this.3F__How_can_I_ensure_that_the_community_can_use_my_work.3F

Usually, the swt team usually prefers that the contributing team maintains the swt fragment since they are very busy and the contributing team actually has access to the hardware to compile the libaries.  We only have the hardware we need to compile the ports included in the build.

There is a committer from Sun who gained commit rights on the solaris.gtk.x86 swt fragment.  However, looking at the fragment in cvs, I can't see any libraries there and note that the fragment hasn't been updated quite a while.
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.gtk.solaris.x86/

Features are collections of plugins and possibly other features that are assembled together to represent a unit of functionality.  They do not usually include code themselves.  

Regarding the equinox launchers being in a feature, there is a bug regarding this issue...
https://bugs.eclipse.org/bugs/show_bug.cgi?id=152034

My understanding is that there is support in the source build to compile a build for solaris gtk x86 but it hasn't been updated in a while.  So please try it out and submit patches as required :-) to make it work for 3.4.

Comment 73 Thorbjørn Ravn Andersen 2007-11-28 08:10:53 EST

(In reply to comment #70)
> Hi Kim,
> I have been checking the latest posts for bug 84344 and it seems that since
> 2005 not much has been accomplished in Solaris x86 becoming an official build
> (or even support being provided for whoever wants to build from sources).

I have tried looking at this but it is rather steep uphill since there needs to be a lot of supportive libraries which needs to be built and the "just work with building the native stuff" is rather hard to locate in a raw source distribution in a plain Solaris Developer Express vmware instance.

If you get this up and running, would you care to summarize bootstrap instructions?

Comment 74 Douglas Atique 2007-11-28 12:27:41 EST

(In reply to comment #72)
> There is a committer from Sun who gained commit rights on the solaris.gtk.x86
> swt fragment.  However, looking at the fragment in cvs, I can't see any
> libraries there and note that the fragment hasn't been updated quite a while.
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.gtk.solaris.x86/

Do you know who this committer is? I would like to get in touch with him/her.


> 
> My understanding is that there is support in the source build to compile a
> build for solaris gtk x86 but it hasn't been updated in a while.  So please try
> it out and submit patches as required :-) to make it work for 3.4.
> 
(Warning: possible stupid question!)
Recap, if I want to work on the latest development builds in order to be able to contribute something that will be checked into CVS, where can I get a source tarball for it? Or must I absolutely check it out from CVS?

Cheers,
Doug

Comment 75 Kim Moir 2007-11-28 16:11:42 EST

Regarding comment #74 question 1, please see comment #35, comment #37.
 
For the latest source tarball, use the source build source included from the latest integration build.  For instance, 

http://download.eclipse.org/eclipse/downloads/drops/I20071127-0800/sourceBuilds.php

Comment 76 Douglas Atique 2007-11-29 15:45:07 EST

Another (possibly stupid) question:
Does the word "fragment" below have a special meaning? What is a fragment in Eclipse terminology?

-- Doug

(In reply to comment #72)
> There are also optional fragments for the following
> org.eclipse.update.core
> org.eclipse.core.filesystem
> org.eclipse.core.resources
> 

Comment 77 Kim Moir 2007-11-29 17:20:50 EST

Fragments provide functionality through a host plugin.  For instance, they can be used to supply operating system specific code or locale specific code (language packs).  At runtime, the code from a fragment is merged into that of the host plugin.  An example of a fragment would be org.eclipse.swt.gtk.solaris.x86.  

If you look at the Manifest of this fragment you will note the Fragment-Host is specified as org.eclipse.swt and there is a platform filter for the ws, os and arch combination that it applies to.

Manifest-Version: 1.0
Fragment-Host: org.eclipse.swt; bundle-version="[3.0.0,4.0.0)"
Bundle-Name: %fragmentName
Bundle-Vendor: %providerName
Bundle-SymbolicName: org.eclipse.swt.gtk.solaris.x86; singleton:=true
Bundle-Version: 3.4.0.HEAD
Bundle-ManifestVersion: 2
Bundle-Localization: fragment
Export-Package: 
 org.eclipse.swt.internal.accessibility.gtk; x-internal:=true,
 org.eclipse.swt.internal.cairo; x-internal:=true,
 org.eclipse.swt.internal.cde; x-internal:=true,
 org.eclipse.swt.internal.gnome; x-internal:=true,
 org.eclipse.swt.internal.gtk; x-internal:=true,
 org.eclipse.swt.internal.mozilla; x-internal:=true,
 org.eclipse.swt.internal.opengl.glx; x-internal:=true
Eclipse-PlatformFilter: (& (osgi.ws=gtk) (osgi.os=solaris) (osgi.arch=x86))
Bundle-RequiredExecutionEnvironment: CDC-1.0/Foundation-1.0,
 J2SE-1.3

Comment 78 Douglas Atique 2007-11-30 15:52:11 EST

Building I20071127-0800 for solaris, gtk, x86...

SWT problem 1: plugins/org.eclipse.swt/Eclipse SWT OpenGL/glx/library/* is not being copied to swttmp and make fails. How must I change the build files to make these files get copied to swttmp?

SWT problem 2 (after copying files by hand to work around problem 1 above): plugins/org.eclipse.swt/Eclipse SWT PI/gtk/library/build.sh defines MOZILLA_INCLUDES and MOZILLA_LIBS from pkg-config (seems correct) but make_solaris.mak uses locally defined MOZILLACFLAGS and MOZILLALIBS. MOZILLACFLAGS is hardcoded with a score of gcc-specific options, while the rest of make_solaris.mak is made for Sun Studio. MOZILLACFLAGS uses MOZILLA_SDK which is not defined anywhere.
Can I just throw MOZILLACFLAGS and MOZILLALIBS from make_solaris.mak away and use $(MOZILLA_INCLUDES) and $(MOZILLA_LIBS) instead?

-- Doug

Comment 79 Grant Gayed 2007-11-30 17:21:01 EST

re: comment 78

problem 1: I think this was a bug in the swt build scripts, which I've just fixed.  So if you download a newer build in the future this should work for you.

problem 2: Browser support is not implemented on solaris, so the make_mozilla target is never run (which makes the variables that this target uses irrelevent).

Comment 80 Douglas Atique 2007-12-01 07:50:45 EST

(In reply to comment #79)
> re: comment 78
> 

Hi Grant,
Thanks for your reply.

> problem 1: I think this was a bug in the swt build scripts, which I've just
> fixed.  So if you download a newer build in the future this should work for
> you.
Great. I'll try the next integration drop (maybe I will just get from CVS, if corrections are frequent...)
> 
> problem 2: Browser support is not implemented on solaris, so the make_mozilla
> target is never run (which makes the variables that this target uses
> irrelevent).
What exactly do you mean?
1. If you mean Eclipse does not support building for Mozilla on Solaris, then there is a bug in build.sh, as SWT's build.sh should never check for XPCOM support and invoke make with make_mozilla.
or 
2. If you mean Solaris doesn't have Mozilla support, so that build.sh may check but will never find XPCOM support, then I must inform you that in Solaris Express Community Edition (see http://opensolaris.org/os/downloads/) pkg-config firefox-xpcom returns 0, and yes, build.sh *does* direct make to build for Firefox XPCOM. The problem is that it will fail with compiler errors due to problem 2 I reported in comment #78.

Either way, I think something has yet to be changed.

Cheers,
Doug

Comment 81 Douglas Atique 2007-12-01 08:00:16 EST

(In reply to comment #78)

Hmmmm, I forgot an important detail.

> Building I20071127-0800 for solaris, gtk, x86...
> 
> SWT problem 1: plugins/org.eclipse.swt/Eclipse SWT OpenGL/glx/library/* is not
> being copied to swttmp and make fails. How must I change the build files to
> make these files get copied to swttmp?
> 
> SWT problem 2 (after copying files by hand to work around problem 1 above):
> plugins/org.eclipse.swt/Eclipse SWT PI/gtk/library/build.sh defines
> MOZILLA_INCLUDES and MOZILLA_LIBS from pkg-config (seems correct) but
> make_solaris.mak uses locally defined MOZILLACFLAGS and MOZILLALIBS.
> MOZILLACFLAGS is hardcoded with a score of gcc-specific options, while the rest
> of make_solaris.mak is made for Sun Studio. MOZILLACFLAGS uses MOZILLA_SDK
> which is not defined anywhere.

And MOZILLA_SDK not being defined anywhere, the -I flags in MOZILLACFLAGS lead to nowhere, the compiler cannot find the headers and compilation fails.

> Can I just throw MOZILLACFLAGS and MOZILLALIBS from make_solaris.mak away and
> use $(MOZILLA_INCLUDES) and $(MOZILLA_LIBS) instead?
> 
> -- Doug
> 

Comment 82 Hanno Wagner 2007-12-04 05:38:05 EST

I just tried to compile the nightly build N20071203-0010 with Java-1.6.0_03 and ant-1.7.0. It failed with the following error:
BUILD FAILED
/export/home/rince/src/eclipse/src/build.xml:79: /export/home/rince/src/eclipse/src/plugins/org.eclipse.rcp.source.solaris.gtk.x86/src not found.


In fact, $SRC/plugins/org.eclipse.rcp.source.solaris.gtk.x86 is missing ; in the plugins-directory there is only org.eclipse.rcp.source. And in this directory there is no src-Directory.

Am I missing something or how can I fix that problem?

(I also tried the I20071127-0800, but it failed too. After I copied the gtk-stuff it complained not to find GL/gtk.h and there I gave up...)

Comment 83 Douglas Atique 2007-12-04 13:16:42 EST

(In reply to comment #79)
> re: comment 78
> 
> problem 1: I think this was a bug in the swt build scripts, which I've just
> fixed.  So if you download a newer build in the future this should work for
> you.

Hi Grant,
Could you tell me what exactly you fixed? I am having trouble to access the Eclipse CVS repository so I would like to apply these changes to I20071127-0800 to try to make some more progress before the next integration build comes out.

Thx.
Doug

Comment 84 Steve Northover 2007-12-04 16:01:59 EST

Grant isn't around, Bogdan?

Comment 85 Douglas Atique 2007-12-06 11:37:53 EST

(In reply to comment #84)
> Grant isn't around, Bogdan?
> 

In fact, I have now succeeded to checkout the CVS repository. However, the instructions (http://download.eclipse.org/eclipse/downloads/drops/I20071204-1547/srcFetchBuildInstructions.html) don't tell me how to build from the CVS working copy.
Shouldn't the CVS working copy have the build script and the lots of assemble* xml files? Where are they?

-- Douglas

Comment 86 Bogdan Gheorghe 2007-12-06 17:06:44 EST

Hi Douglas - like Steve mentioned, Grant is gone for the next little while but I can try to help. Reading through the comments, I don't feel that I have a clear picture of how far along you are. There are a number of steps that need to happen in order to have a stand alone deployment:

1) You need to build the SWT native libraries for solaris. 

2) You need to create a jar of the SWT libraries.

3) You need to have a launcher for the native platform.

4) You need to bundle the rest of the Eclipse plugins.

So, first question: did you manage to build the native libraries in your workspace and can you run an SWT snippet with them?

Comment 87 Grant Gayed 2007-12-06 19:35:09 EST

Created attachment 84690 [details]
attempt to remove mozilla from solaris scripts

(I'm away but saw the discussion here remotely).

re: comment 80
swt does not have Browser support on solaris, so when swt's libraries are built on solaris the make_mozilla target should not be invoked.  If the presence of this target and the variables it uses are causing problems in other contexts then it should be removable.  I've attached a patch that (I think) will do this, but can't test it because I don't have access to a Solaris machine.  Bogdan can you apply the patch and fix/release it if it works?

re: comment 85
Files like the assemble* ones come from releng, not from swt.  FAQ entry http://www.eclipse.org/swt/faq.php#howbuilddll describes how to build the swt libraries when checked out from cvs, but it doesn't use the build-eclipse-from-source mechanism that you're using, since some of the pieces for this don't come from swt.

Comment 88 Douglas Atique 2007-12-07 13:20:37 EST

(In reply to comment #86)
> Hi Douglas - like Steve mentioned, Grant is gone for the next little while but
> I can try to help. Reading through the comments, I don't feel that I have a
> clear picture of how far along you are. There are a number of steps that need
> to happen in order to have a stand alone deployment:
> 
> 1) You need to build the SWT native libraries for solaris. 
> 
> 2) You need to create a jar of the SWT libraries.
> 
> 3) You need to have a launcher for the native platform.
> 
> 4) You need to bundle the rest of the Eclipse plugins.
> 
> So, first question: did you manage to build the native libraries in your
> workspace and can you run an SWT snippet with them?
> 

Hi Bogdan,

I have checked out all modules from the Eclipse CVS repository. I have made some changes to build.sh and make_solaris.mak that reside in org.eclipse.swt/Eclipse SWT PI and I have managed once to build the native libraries from the command line. However that was with the zip file from I20071127-0800. I want to work directly with the CVS HEAD so that I stop having to setup everything again everytime a new sources zip file comes out (and also to be able to update quickly when someone makes changes to the CVS repository -- updated zips come out once a week or so).
Please keep in mind that I don't have Eclipse, I am running Solaris x86, so how can I bootstrap the build of SWT for my platform from the command-line and from the CVS working copy?
I have tried issuing ant from org.eclipse.swt directory and it fails because it cannot find ant task eclipse.versionReplacer. I am probably missing something very basic from the build system, but I haven't found any clues in the docs (all require Eclipse to build). Can you help me get started?

Cheers,
Douglas

Comment 89 Douglas Atique 2007-12-07 13:27:41 EST

(In reply to comment #87)
> Created an attachment (id=84690) [details]
> attempt to remove mozilla from solaris scripts
> 
> (I'm away but saw the discussion here remotely).
> 
> re: comment 80
> swt does not have Browser support on solaris, so when swt's libraries are built
> on solaris the make_mozilla target should not be invoked.  If the presence of
> this target and the variables it uses are causing problems in other contexts
> then it should be removable.  I've attached a patch that (I think) will do
> this, but can't test it because I don't have access to a Solaris machine. 
> Bogdan can you apply the patch and fix/release it if it works?

Hi Grant,
I have made some changes to make_solaris.mak myself which seem to build the swt mozilla library without errors. I don't know if they work, but they build. So, if you want to wait until I can get my changes in place then this will not get in the way of the build even if it doesn't work.

> 
> re: comment 85
> Files like the assemble* ones come from releng, not from swt.  FAQ entry
> http://www.eclipse.org/swt/faq.php#howbuilddll describes how to build the swt
> libraries when checked out from cvs, but it doesn't use the
> build-eclipse-from-source mechanism that you're using, since some of the pieces
> for this don't come from swt.
> 
But I assume there is some shell script or ant script that you can invoke that will build eclipse from freshly checked out CVS sources. Right? Or how do I get from CVS to some useful buildable source tree? I cannot find this information anywhere.

Please don't forget that I must be able to build from the command line with ant alone, I don't have Eclipse running on my machine yet.

Cheers,
Douglas

Comment 90 Douglas Atique 2007-12-07 14:13:30 EST

Created attachment 84767 [details]
Patch to build SWT on solaris-gtk-x86

With these files I can build SWT for Solaris x86 without any errors.

Comment 91 Douglas Atique 2007-12-07 14:15:16 EST

(In reply to comment #90)
> Created an attachment (id=84767) [details]
> Patch to build SWT on solaris-gtk-x86
> 
> With these files I can build SWT for Solaris x86 without any errors.
> 

oops, sorry. I just found that everything is in org.eclipse.swt.gtk.solaris.x86...

Comment 92 Sriram Narayanan 2007-12-08 12:55:52 EST

(In reply to comment #91)
> (In reply to comment #90)
> > Created an attachment (id=84767) [details] [details]
> > Patch to build SWT on solaris-gtk-x86
> > 
> > With these files I can build SWT for Solaris x86 without any errors.
> > 
> 
> oops, sorry. I just found that everything is in
> org.eclipse.swt.gtk.solaris.x86...
> 

Grrr.. I'm so mad at myself for not giving this time. It's great to see you work on this.

I just finished building FF 2.0.0.11 on Solaris Express Community Edition build 68 , and am waiting for my eclipse source checkout to complete. This weekend is Eclipse weekend !

What's your exact OS specification ?

Comment 93 Douglas Atique 2007-12-09 07:04:58 EST

(In reply to comment #92)
> (In reply to comment #91)
> > (In reply to comment #90)
> > > Created an attachment (id=84767) [details] [details] [details]
> > > Patch to build SWT on solaris-gtk-x86
> > > 
> > > With these files I can build SWT for Solaris x86 without any errors.
> > > 
> > 
> > oops, sorry. I just found that everything is in
> > org.eclipse.swt.gtk.solaris.x86...
> > 
> 
> Grrr.. I'm so mad at myself for not giving this time. It's great to see you
> work on this.
> 
> I just finished building FF 2.0.0.11 on Solaris Express Community Edition build
> 68 , and am waiting for my eclipse source checkout to complete. This weekend is
> Eclipse weekend !
> 
> What's your exact OS specification ?
> 

Hi Sriram,

Great to see that you are also interested. I am using Solaris Express Community Edition (a.k.a. SXCE) build 77 -- but I'm checking everyday for the b78 images :-)

I think what I am doing will apply equally to any Solaris version > 10 that has SunStudio 11 and ant in PATH. Maybe Solaris 10 will not have very up to date gtk libraries, but I am not sure about that.

When you have the sources from CVS, could you perhaps lend me a hand in checking how to do the full build from there? I'm very curious about this process too.

Cheers,
Doug

Comment 94 Douglas Atique 2007-12-12 07:26:03 EST

(In reply to comment #82)
> I just tried to compile the nightly build N20071203-0010 with Java-1.6.0_03 and
> ant-1.7.0. It failed with the following error:
> BUILD FAILED
> /export/home/rince/src/eclipse/src/build.xml:79:
> /export/home/rince/src/eclipse/src/plugins/org.eclipse.rcp.source.solaris.gtk.x86/src
> not found.

Hi Hanno,

Sorry but I had missed your post. I am getting this error too (now trying I20071210-1300). Apparently the platform-specific fragments of plugin org.eclipse.rcp.source are gone. Could anyone confirm this?

What I am trying right now is to build after removing the build.xml fragment that tries to copy files from plugins/org.eclipse.rcp.source.solaris.gtk.x86/src. However, I am not sure this is the right thing to do.

Help appreciated.

-- Douglas

Comment 95 Douglas Atique 2007-12-12 08:25:00 EST

> What I am trying right now is to build after removing the build.xml fragment
> that tries to copy files from
> plugins/org.eclipse.rcp.source.solaris.gtk.x86/src. However, I am not sure this
> is the right thing to do.

This didn't work, and I uncommented the build.xml fragment again and changed org.eclipse.rcp.source.solaris.gtk.x86 to org.eclipse.swt.gtk.solaris.x86. However, it seems that org.eclipse.swt.gtk.solaris.x86's build.xml must be invoked before with target "src.zip" to build the sources zip file that will be used.
I may be missing something very simple here, but I need help.

Cheers,
Douglas

Comment 96 Kim Moir 2007-12-12 15:26:01 EST

Regarding comment #94, #95

The eclipse SDK was recently changed to use individual source bundles instead of storing all the source a single source plugin associated with a feature.

I'll confirm that the source build works with these recent changes, this is reflected in bug 212805.

Comment 97 Douglas Atique 2007-12-13 07:49:40 EST

(In reply to comment #96)
> Regarding comment #94, #95
> 
> The eclipse SDK was recently changed to use individual source bundles instead
> of storing all the source a single source plugin associated with a feature.
> 
> I'll confirm that the source build works with these recent changes, this is
> reflected in bug 212805.
> 

Needless to say, I don't know what is going on. Even so, is there anything I can do to help with that bug?

Cheers,
Doug

Comment 98 Douglas Atique 2007-12-21 08:54:06 EST

As of I20071218-0800, still the same error.

Cheers,
Doug

(In reply to comment #96)
> Regarding comment #94, #95
> 
> The eclipse SDK was recently changed to use individual source bundles instead
> of storing all the source a single source plugin associated with a feature.
> 
> I'll confirm that the source build works with these recent changes, this is
> reflected in bug 212805.
> 

Comment 99 Sriram Narayanan 2008-01-01 13:18:56 EST

I took 3.4M2 and managed to get it all to build last weekend. The one problem that I'm facing is that the launcher complains about not being able to find some associated file. I think I need to go over my work again and then figure out what might have gone wrong.

I wanted to work on this tonight, but my laptop's hard disk drive died today, so there aren't any files that I can post. Luckily, I've made notes on a writing pad on what files I'd to change, so I can reconstruct this.

I'm interested in working on https://bugs.eclipse.org/bugs/show_bug.cgi?id=77217, since Mozilla support in SWT is very important for me. As a result, my focus is on getting the SWT Browser component to work first.

As before, I can only make time on a weekend. This will be the case for at least two more weeks.

Comment 100 Sriram Narayanan 2008-01-01 13:33:26 EST

I see the status as RESOLVED. Has this really been resolved, or is there some erroneous status change ? As of 3.4 M2, the source zip doesn't build out of the box on Solaris x86, and the SWT Mozilla binding needs some work too.

Comment 101 Kim Moir 2008-01-02 14:44:47 EST

reopening

Comment 102 Tim Myer 2008-01-09 00:35:40 EST

I am not sure what progress has been made on this bug recently but figured I would throw in my hat since I have had some success building Europa 3.3.0 and now Ganymede 3.4M4 on Nexenta (Gnu-Solaris) Alpha 7.  I will attach the two scripts that I have used for those two builds.  I have been able to just drop each script in a directory next to the corresponding source zip file and run the script to create an eclipse sdk distribution.  Hopefully they can be of use to someone as a place to get started.  As I only have access to a Nexenta build machine, I am not sure how other OpenSolaris distributions will fare with the scripts.
Please note the comment at the top of each script about specifying a java home directory and sun studio directory.  Also, note that the scripts use both the gcc and Sun cc compiler.  There is no Mozilla support in these scripts.  Also, I have not included any additional dependency checks for re-compiling the native libraries.
The question I have is this: there seems to be a dependency on the CDE libraries for the solaris build scripts -- but Nexenta is a distribution of OpenSolaris that does not include the CDE libraries, and I seem to be able to run Eclipse without them -- should there really be that dependency for a solaris-gtk-x86 distribution, or is Nexenta considered a different animal than Solaris?

Comment 103 Tim Myer 2008-01-09 00:38:12 EST

Created attachment 86440 [details]
Script to build Eclipse 3.3.0 for solaris-gtk-x86 on Nexenta

Script to build Eclipse 3.3.0 for solaris-gtk-x86 on Nexenta.

Comment 104 Tim Myer 2008-01-09 00:39:09 EST

Created attachment 86441 [details]
Script to build Eclipse 3.4M4 for solaris-gtk-x86 on Nexenta

Script to build Eclipse 3.4M4 for solaris-gtk-x86 on Nexenta

Comment 105 Grant Gayed 2008-01-09 10:00:31 EST

> there seems to be a dependency on the CDE libraries

swt's CDE library is used for accessing info like program associations when running in a CDE environment.  So if you're running in a non-CDE environment then eclipse will not be affected by the absence of this library in swt.

Comment 106 Tim Myer 2008-01-09 11:46:20 EST

Thanks, Grant.  Is there currently a flag or environment variable that is checked to determine whether the CDE libraries should be used for a Solaris SWT build?  If not, would it make sense to add such a flag (to the make_solaris.mak file or to the build script that calls this make file)?  I would be happy to open this as a feature request and contribute it but I do not have committer access and am not quite sure where the build scripts are located in CVS if anyone out there would be willing to show me the way :).

Comment 107 Grant Gayed 2008-01-10 10:00:31 EST

There's not currently a flag that affects which libraries are to be built.  To keep things simpler I don't think this is worth adding though, since to not build this library one can currently either remove make_cde from the "all" target, or better, invoke build.sh with the specific targets to be run.

The scripts that are run to build swt's libraries were added to the respective fragments a few weeks ago.  To see one of these, connect to dev.eclipse.org (steps: http://www.eclipse.org/swt/cvs.php) and look at the buildLibraries.csh file in (for example) the org.eclipse.swt.gtk.solaris.sparc project.

Comment 108 Douglas Atique 2008-01-18 08:24:33 EST

(In reply to comment #102)
Tim,
Thanks for your scripts, they are great help. I have used parts of the 3.4 one and they helped me get a successful build all the way to the end. I am trying to figure out what is going on because the resulting distribution still doesn't work, but getting the build to the end was sure a lot of progress.

Cheers,
Doug

Comment 109 Volker Stolz 2008-04-21 21:58:11 EDT

Created attachment 96949 [details]
Modified Tim's script for plain Solaris 10 build of 3.3.0

Comment 110 Volker Stolz 2008-04-21 22:00:40 EDT

Created attachment 96950 [details]
Modified Tim's script for plain Solaris 10 build of 3.4M4

Based on Tim's script here are modified version for building Eclipse 3.3.0 and 3.4M4 on a plain Solaris 10 installation with Sun Studio Express 12 (no gcc needed).
Binary downloads available from http://nowonder.foldr.org:8080/roller/page/vs?entry=eclipse_3_3_and_3

Comment 111 Hugo A. Garcia 2008-06-30 13:48:47 EDT

Hi

Timothy Myer and I have been working on building Eclipse 3.4 on Open Solaris x86 and organizing an open source project around our work. We have successfully partially built Eclipse 3.4 with certain limitations. We are still working on the open issues and welcome your help.

For information on building Eclipse go to http://code.google.com/p/solipse/

We welcome any comments, suggestions and questions that you may have. 

Cheers,

Timothy Myer and Hugo A. Garcia

Comment 112 Dr.Udo Grabowski 2009-03-09 12:00:09 EDT

How are the plans to integrate the solaris x86 builds into the main line ?
I see that the missing platform already is an obstacle for other software
projects depending on a mainline release of eclipse, for instance, ITTVIS
just decided to release only a commandline version of their IDL software
because of that.
What's missing to integrate the solipse project back to trunk ? 

Comment 113 Tim Myer 2009-03-09 18:24:05 EDT

(In reply to comment #112)

Hello Dr.Grabowski,
OpenGL and the internal web browser are still not supported.  Aside from that, I have been using the solipse build from 3.3 to 3.4.2.  I would love to contribute back what I can to the Eclipse community but would need guidance.
Thanks.
---Tim---

Comment 114 Sriram Narayanan 2009-03-10 00:01:13 EDT

(In reply to comment #113)
> (In reply to comment #112)
> 
> Hello Dr.Grabowski,
> OpenGL and the internal web browser are still not supported.  Aside from that,
> I have been using the solipse build from 3.3 to 3.4.2.  I would love to
> contribute back what I can to the Eclipse community but would need guidance.
> Thanks.
> ---Tim---
> 

I'd got this to work off and on, but haven't been disciplined yet to push patches into the bugzilla. The last I looked at the solipse work, it used perl - something I'm not conversant with.

Have you seen my bug reports on the issues that I've faced with getting Mozilla to run with SWT ?

We could either merge our work, or see if your perl based code could be modified into patches to the build scripts (since I don't know if introducing perl to the build mix would be acceptable or not).

In any case, if someone could take a look at diagnosing the vtable issues that I'm facing with running mozilla with SWT, we'd actually be ready to go.

Comment 115 Tim Myer 2009-03-10 01:29:38 EDT

(In reply to comment #114)
Hi Sriram,
Actually, I was thinking more along the lines of just contributing the binaries, not the solipse script itself.  Because of bug 221908, the compileLibs Ant task has been removed from the build.xml, so even with the changes the solipse script makes, without addressing that bug, users would not necessarily be able to build the solaris x86 binaries themselves anyway.  Also, some of the changes that the solipse script makes would make sense as contributed patches, some might not (for example, the compilation-related substitutions or the removal of the CDE dependency).
As for the heavy use of perl, any of those calls could easily be changed to sed.  They are all just finds-and-replaces.
As for Mozilla and SWT, I had this compiling in the past (the solipse script contains the Mozilla-related lines commented out, but they have not been maintained for a while).  I could not quite get it working, either.  Your issue unfortunately does not sound familiar to me, so I am not sure if I could help.
---Tim---
 

Comment 116 Kim Moir 2009-05-22 15:09:38 EDT

The swt gtk solaris drop is available as of M7 as described in bug 272211.  Closing this bug since the drop is now available for download.