[gentoo-java] icedtea6 bootstrap

[gentoo-java] icedtea6 bootstrap

[Alon Bar-Lev]

Hello,

I just curious... How do you see the boostrap process for normal users?

You need jdk to setup icedtea... So we have somekind of loop...
Users who do not want non open source package to run on their computers should:

1. Install gcj
2. Install icedtea
3. Reinstall icedtea so it compiles with icedtea and drop gcj dependency???
4. Uninstall gcj

Portage do not support these sequences...

So we have several options:
1. Have users do this manually.
2. Create a script similar to crossdev that perform the sequence.
3. Add a private gcj build into the compile stage of icedtea, and drop
the jdk dependency.

Any thoughts?
Alon.

---

I am almost sure you already know that... But just for the record:

 * QA Notice: The following files contain executable stacks
 *  Files with executable stacks will not work properly (or at all!)
 *  on some architectures/operating systems.  A bug should be filed
 *  at http://bugs.gentoo.org/ to make sure the file is fixed.
 *  For more information, see http://hardened.gentoo.org/gnu-stack.xml
 *  Please include this file in your report:
 *  /var/tmp/portage/dev-java/icedtea6-1.2/temp/scanelf-execstack.log
 * RWX --- --- usr/lib/icedtea6-1.2/jre/lib/i386/server/libjvm.so
 * RWX --- --- usr/lib/icedtea6-1.2/jre/lib/i386/client/libjvm.so


 * QA Notice: Package has poor programming practices which may compile
 *            fine but exhibit random runtime failures.
 * ../../../src/solaris/native/java/net/Inet4AddressImpl.c:385:
warning: implicit declaration of function 'gettimeofday'
 * ../../../src/solaris/native/java/net/Inet6AddressImpl.c:520:
warning: implicit declaration of function 'gettimeofday'
 * ../../../src/solaris/native/java/net/Inet4AddressImpl.c:385:
warning: implicit declaration of function 'gettimeofday'
 * ../../../src/solaris/native/java/net/Inet6AddressImpl.c:520:
warning: implicit declaration of function 'gettimeofday'

Re: [gentoo-java] icedtea6 bootstrap

[Andrew John Hughes]

On 15:38 Sun 14 Sep     , Alon Bar-Lev wrote:
> Hello,
> 
> I just curious... How do you see the boostrap process for normal users?
> 
> You need jdk to setup icedtea... So we have somekind of loop...

Yes, such a bootstrap issue is hardly limited to IcedTea.
The same occurs with gcc for example, and other Free Java VMs.

> Users who do not want non open source package to run on their computers should:
> 
> 1. Install gcj
> 2. Install icedtea
> 3. Reinstall icedtea so it compiles with icedtea and drop gcj dependency???
> 4. Uninstall gcj
> 

You don't need stage 3 (there is no 'gcj dependency'), and stage 4 is completely optional.
Other Free VMs can be used, but they also have bootstrap issues.

In the long run, we probably need a binary option for lower spec. machines,
as I've already said.

> Portage do not support these sequences...
> 

Well this is probably a flaw in portage then, but the solution is only
a two-step emerge process:

emerge gcj-jdk
emerge icedtea6

I don't think that's inherently difficult.

> So we have several options:
> 1. Have users do this manually.
> 2. Create a script similar to crossdev that perform the sequence.
> 3. Add a private gcj build into the compile stage of icedtea, and drop
> the jdk dependency.
> 

I don't see any problem with 1.  Why is gcj not enabled in the bootstrap
gcc on the install CDs? 

> Any thoughts?
> Alon.
> 
> ---
> 
> I am almost sure you already know that... But just for the record:
> 
>  * QA Notice: The following files contain executable stacks
>  *  Files with executable stacks will not work properly (or at all!)
>  *  on some architectures/operating systems.  A bug should be filed
>  *  at http://bugs.gentoo.org/ to make sure the file is fixed.
>  *  For more information, see http://hardened.gentoo.org/gnu-stack.xml
>  *  Please include this file in your report:
>  *  /var/tmp/portage/dev-java/icedtea6-1.2/temp/scanelf-execstack.log
>  * RWX --- --- usr/lib/icedtea6-1.2/jre/lib/i386/server/libjvm.so
>  * RWX --- --- usr/lib/icedtea6-1.2/jre/lib/i386/client/libjvm.so
> 
> 
>  * QA Notice: Package has poor programming practices which may compile
>  *            fine but exhibit random runtime failures.
>  * ../../../src/solaris/native/java/net/Inet4AddressImpl.c:385:
> warning: implicit declaration of function 'gettimeofday'
>  * ../../../src/solaris/native/java/net/Inet6AddressImpl.c:520:
> warning: implicit declaration of function 'gettimeofday'
>  * ../../../src/solaris/native/java/net/Inet4AddressImpl.c:385:
> warning: implicit declaration of function 'gettimeofday'
>  * ../../../src/solaris/native/java/net/Inet6AddressImpl.c:520:
> warning: implicit declaration of function 'gettimeofday'
> 

These are OpenJDK issues that need to be raised with Sun.

Cheers,
-- 
Andrew :)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: [gentoo-java] icedtea6 bootstrap

[Alon Bar-Lev]

On 9/14/08, Andrew John Hughes <gnu_andrew@member.fsf.org> wrote:
> On 15:38 Sun 14 Sep     , Alon Bar-Lev wrote:
>  > Hello,
>  >
>  > I just curious... How do you see the boostrap process for normal users?
>  >
>  > You need jdk to setup icedtea... So we have somekind of loop...
>
>
> Yes, such a bootstrap issue is hardly limited to IcedTea.
>  The same occurs with gcc for example, and other Free Java VMs.

This is OK to have these issues, I just want user to be able to setup
their configuration correctly and easily.

>  > Users who do not want non open source package to run on their computers should:
>  >
>  > 1. Install gcj
>  > 2. Install icedtea
>  > 3. Reinstall icedtea so it compiles with icedtea and drop gcj dependency???
>  > 4. Uninstall gcj
>  >
>
>
> You don't need stage 3 (there is no 'gcj dependency'), and stage 4 is completely optional.
>  Other Free VMs can be used, but they also have bootstrap issues.

Great!

>  In the long run, we probably need a binary option for lower spec. machines,
>  as I've already said.

I don't like binaries... we really need to find a way to build from source.

>  > Portage do not support these sequences...
>  >
>
>
> Well this is probably a flaw in portage then, but the solution is only
>  a two-step emerge process:
>
>  emerge gcj-jdk
>  emerge icedtea6
>
>  I don't think that's inherently difficult.

You forgot:
java-config -S icedtea6
emerge --unmerge gcj-jdk

It is not difficult for me or you. It is difficult for regular user
who want open source jdk and doing emerge openoffice for example. The
first jdk will be pulled... If the first jdk is gcj then this will be
installed and used by openoffice. If you want to use icedtea then you
need to complete some more stages. Most users will need some help.

>  > So we have several options:
>  > 1. Have users do this manually.
>  > 2. Create a script similar to crossdev that perform the sequence.
>  > 3. Add a private gcj build into the compile stage of icedtea, and drop
>  > the jdk dependency.
>  >
>
>
> I don't see any problem with 1.  Why is gcj not enabled in the bootstrap
>  gcc on the install CDs?

Because it takes space and not needed for many configurations.

I think a simple script in the spirit of crossdev will enable users to
correctly and quickly set up their jdk.

Alon.

Re: [gentoo-java] icedtea6 bootstrap

[Alon Bar-Lev]

On 9/15/08, Alon Bar-Lev <alon.barlev@gmail.com> wrote:
>  > Well this is probably a flaw in portage then, but the solution is only
>  >  a two-step emerge process:
>  >
>  >  emerge gcj-jdk
>  >  emerge icedtea6
>  >
>  >  I don't think that's inherently difficult.
>
>
> You forgot:
>  java-config -S icedtea6
>  emerge --unmerge gcj-jdk

And on a second thought... You need also add the gcj USE flag to gcc,
reemerge gcc, then at the end remove the gcj USE flag from gcc and
reemerge gcc.

So it is much more complex.

So basically, provided that >=gcc-4.3 is stable, this is the outline
of what I thought, you can make it more efficient if you check for
other valid jdks and not force only gcj...

if installed icedtea6; then
    exit 0
fi
if ! has_use gcc gcj; then
    should_remove_gcj_use_from_gcc=1
    USE="gcj" emerge --oneshot gcc || die
fi
if ! installed gcj-jdk; then
    should_remove_gcj_jdk=1
    emerge --oneshot gcj-jdk || die
fi
old_java=$(java-config -f)
java-config -S gcj-jdk || die
emerge icedtea6 || die
if [ ${old_java}" = "gcj-jdk" -a -n "${should_remove_gcj_jdk}" ]; then
    java-config -S icedtea6 || die
else
    java-config -S $(old_java) || die
fi
[ -n "${should_remove_gcj_jdk}" ] && emerge --unmerge gcj-jdk
[ -n "${should_remove_gcj_use_from_gcc}" ] && emerge --oneshot gcc

exit 0

Re: [gentoo-java] icedtea6 bootstrap

[Philipp Riegger]

On Sun, 2008-09-14 at 21:38 +0100, Andrew John Hughes wrote:
> emerge gcj-jdk
> emerge icedtea6

Somehow gcj-jdk pulls in icedtea6 for me, which is a cyclic dependency.

Philipp

Re: [gentoo-java] icedtea6 bootstrap

[Philipp Riegger]

On Mon, 2008-09-15 at 13:35 +0200, Philipp Riegger wrote:
> On Sun, 2008-09-14 at 21:38 +0100, Andrew John Hughes wrote:
> > emerge gcj-jdk
> > emerge icedtea6
> 
> Somehow gcj-jdk pulls in icedtea6 for me, which is a cyclic dependency.

Sorry for the noise. It wa my fault, wrong eclipse-ecj version.

Philipp

Re: [gentoo-java] icedtea6 bootstrap

[Andrew John Hughes]

2008/9/15 Alon Bar-Lev <alon.barlev@gmail.com>:
> On 9/14/08, Andrew John Hughes <gnu_andrew@member.fsf.org> wrote:
>> On 15:38 Sun 14 Sep     , Alon Bar-Lev wrote:
>>  > Hello,
>>  >
>>  > I just curious... How do you see the boostrap process for normal users?
>>  >
>>  > You need jdk to setup icedtea... So we have somekind of loop...
>>
>>
>> Yes, such a bootstrap issue is hardly limited to IcedTea.
>>  The same occurs with gcc for example, and other Free Java VMs.
>
> This is OK to have these issues, I just want user to be able to setup
> their configuration correctly and easily.
>
>>  > Users who do not want non open source package to run on their computers should:
>>  >
>>  > 1. Install gcj
>>  > 2. Install icedtea
>>  > 3. Reinstall icedtea so it compiles with icedtea and drop gcj dependency???
>>  > 4. Uninstall gcj
>>  >
>>
>>
>> You don't need stage 3 (there is no 'gcj dependency'), and stage 4 is completely optional.
>>  Other Free VMs can be used, but they also have bootstrap issues.
>
> Great!
>
>>  In the long run, we probably need a binary option for lower spec. machines,
>>  as I've already said.
>
> I don't like binaries... we really need to find a way to build from source.
>

There is a way to build from source... but it's always going to be one
that's a little
complicated and have high requirements (~6gb disk space, a long build time).  It
may not be possible to build it on some machines.

>>  > Portage do not support these sequences...
>>  >
>>
>>
>> Well this is probably a flaw in portage then, but the solution is only
>>  a two-step emerge process:
>>
>>  emerge gcj-jdk
>>  emerge icedtea6
>>
>>  I don't think that's inherently difficult.
>
> You forgot:
> java-config -S icedtea6
> emerge --unmerge gcj-jdk
>

I didn't forgot the second of these because it's not something I'd do or
recommend.  It's a waste of time rebuilding gcc again.  IcedTea doesn't
provide the AOT compilation that gcj does, which is used by other ebuilds.

> It is not difficult for me or you. It is difficult for regular user
> who want open source jdk and doing emerge openoffice for example. The
> first jdk will be pulled... If the first jdk is gcj then this will be
> installed and used by openoffice. If you want to use icedtea then you
> need to complete some more stages. Most users will need some help.
>

well, the obvious solution is to depend on gcj-jdk directly, but even
more people
whined about this when we used to do it.

>>  > So we have several options:
>>  > 1. Have users do this manually.
>>  > 2. Create a script similar to crossdev that perform the sequence.
>>  > 3. Add a private gcj build into the compile stage of icedtea, and drop
>>  > the jdk dependency.
>>  >
>>
>>
>> I don't see any problem with 1.  Why is gcj not enabled in the bootstrap
>>  gcc on the install CDs?
>
> Because it takes space and not needed for many configurations.
>
> I think a simple script in the spirit of crossdev will enable users to
> correctly and quickly set up their jdk.
>

Well, feel free to contribute and maintain one then.

> Alon.
>



-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: [gentoo-java] icedtea6 bootstrap

[Andrew Cowie]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

On Mon, 2008-09-15 at 08:08 +0300, Alon Bar-Lev wrote:

> And on a second thought... You need also add the gcj USE flag to gcc,
> reemerge gcc, then at the end remove the gcj USE flag from gcc and
> reemerge gcc.

Which is a hideous thought.

Could we not make it depend on dev-java/jamvm + dev-java/gnu-classpath
in order to bootstrap? The impact of these is a hell of a lot less.

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-java] icedtea6 bootstrap

[Andrew John Hughes]

2008/9/17 Andrew Cowie <andrew@operationaldynamics.com>:
> On Mon, 2008-09-15 at 08:08 +0300, Alon Bar-Lev wrote:
>
>> And on a second thought... You need also add the gcj USE flag to gcc,
>> reemerge gcc, then at the end remove the gcj USE flag from gcc and
>> reemerge gcc.
>
> Which is a hideous thought.
>
> Could we not make it depend on dev-java/jamvm + dev-java/gnu-classpath
> in order to bootstrap? The impact of these is a hell of a lot less.
>
> AfC
> Sydney
>
> --
> Andrew Frederick Cowie
>
> Operational Dynamics is an operations and engineering consultancy
> focusing on IT strategy, organizational architecture, systems
> review, and effective procedures for change management. We actively
> carry out research and development in these areas on behalf of our
> clients, and enable successful use of open source in their mission
> critical enterprises, worldwide.
>
> http://www.operationaldynamics.com/
>
> Sydney   New York   Toronto   London
>

First of all, there is no need to go to such lengths removing gcj afterwards.
It's not going to hurt to leave it on.

Also, the build depends on jdk >= 1.5 already, so CACAO or JamVM would
do the job fine.  But you'd have similar bootstrap issues, because these
require GNU Classpath and that requires ecj, etc.

Building a Java environment can be a nightmare to be honest :)
I guess the only non-GCJ way would be to use Jikes, then an older Classpath
to get ecj working, then build the new ones.
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: [gentoo-java] icedtea6 bootstrap

[Alon Bar-Lev]

On 9/17/08, Andrew John Hughes <gnu_andrew@member.fsf.org> wrote:
> First of all, there is no need to go to such lengths removing gcj afterwards.
>  It's not going to hurt to leave it on.

It takes a lot of resources (disk, time rebuilding, unused components).
So there is a reason to keep system as small as possible.

>  Also, the build depends on jdk >= 1.5 already, so CACAO or JamVM would
>  do the job fine.  But you'd have similar bootstrap issues, because these
>  require GNU Classpath and that requires ecj, etc.

So gcj is the best alternative. But what happens if gcc stops
providing this in favor of OpenJDK?

>  Building a Java environment can be a nightmare to be honest :)
>  I guess the only non-GCJ way would be to use Jikes, then an older Classpath
>  to get ecj working, then build the new ones.

I guess I am asking that icedtea6 does not have such boostrap in package...
If it does not provide this, users should have a simple way to
bootstrap it in Gentoo... Providing a simple script is sufficient.

Thanks,
Alon.

Re: [gentoo-java] icedtea6 bootstrap

[Andrew John Hughes]

2008/9/17 Alon Bar-Lev <alon.barlev@gmail.com>:
> On 9/17/08, Andrew John Hughes <gnu_andrew@member.fsf.org> wrote:
>> First of all, there is no need to go to such lengths removing gcj afterwards.
>>  It's not going to hurt to leave it on.
>
> It takes a lot of resources (disk, time rebuilding, unused components).
> So there is a reason to keep system as small as possible.
>

Err.. time rebuilding is part of the reason _not_ to remove it.
Applications like ecj benefit from being natively compiled by gcj in
my experience.
There is a gcj USE flag in Gentoo for this purpose.

You're probably talking about ~150mb vs. a long re-build time.  I'd take the
150mb and potential future use, especially with today's hard disc sizes.
gcc still takes a while to build even on new machines.

>>  Also, the build depends on jdk >= 1.5 already, so CACAO or JamVM would
>>  do the job fine.  But you'd have similar bootstrap issues, because these
>>  require GNU Classpath and that requires ecj, etc.
>
> So gcj is the best alternative. But what happens if gcc stops
> providing this in favor of OpenJDK?
>

Not likely anytime in the near future.

>>  Building a Java environment can be a nightmare to be honest :)
>>  I guess the only non-GCJ way would be to use Jikes, then an older Classpath
>>  to get ecj working, then build the new ones.
>
> I guess I am asking that icedtea6 does not have such boostrap in package...

That's pretty much impossible, unless you plan to write a compiler that can
cope with 1.5 bytecode in either C or C++, and then alter the OpenJDK
build system to use it :)

Basically you need to be able to build the OpenJDK langtools (written in Java
with 1.5 constructs), then run them (which needs a 1.5-capable Java VM).  Or
some equivalent.

> If it does not provide this, users should have a simple way to
> bootstrap it in Gentoo... Providing a simple script is sufficient.
>

Then feel free to write one as I said.

> Thanks,
> Alon.
>



-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8