Super Bisquit
2012-04-08 23:26:04 UTC
I've received feedback from Harvard. What I want is to be sure that I
understand the concept and can execute it correctly.
http://docs.freebsd.org/cgi/getmsg.c...3.freebsd-java
I have SSH set up to log into the iMac running Debian. The assumption
is that the script is run on the iMac and it is exported to the
QuickSilver.
Is the SSH setup right? PMac to iMac? Also assume that the script is
run on the iMac and I am running a simple SSH ***@. Is it
$EXPORTED_ENV to $WORKING_DIRECTORY or $EXPORTED_ENVIRONMENT
ln -s
$USER_BINARY_PATHS?
.
I have Debian running on an iMac G4 and FreeBSD running on a QuickSilver G4.
1. The assumption is that the script is ran on the iMac. Considering
that SSH between both machines is set up, is the exporting:
a) From the iMac to the QuickSilver.
b) The inverse of the above.
And
c) Is it ran from the same terminal used for the SSH login
d) Or from another terminal connected on the target to the SSHed login?
If the exporting is done such as stated in d above, then how do I set
that up properly?
Also, does the shell type in the original environment need to match
the shell of the target environment or is it an irrelevant point?
I'm using the standard ssh user@ for logins.
If the method to use is NFS with a and b being replaced with the NFS
variables- being both server and client, then which similar method is
the correct one? Is the script setup in /usr/share/java,
/usr/lib/java, or both?
The following is what Harvard and I discussed with my reply to him added.
the target of your porting efforts. There's just a few times
java needs to be run during the building. But since you don't
have a usable java on your target host, you need assistance from
another host where you have a usable java compiler.
In my setup I made the porting tree available via the same path
name on the "assist me" machine as on the actual target, using
NFS. I suggest you do the same, to stroke the dog with the
hairs...
my case it has embedded the host name of the assist host I used, and
the full pathname on the assistance host of the actual working java
#! /bin/sh
d=`pwd`
where "bean" is the name of the NetBSD/i386 host I used to bootstrap
the java on NetBSD/amd64. You need to modify these scripts to fit
your environment.
I meant that I want to build the necessary parts on the target and,
once that is complete, do a native build on the target environment
understand everything; unfortunately, I'm afraid I'm losing people on
it. So, I'm going to post on the netbsd tech-misc help.
Yes, I will use what you told me here.
Anywhere that I am wrong, please let me know.
Thanks.
understand the concept and can execute it correctly.
http://docs.freebsd.org/cgi/getmsg.c...3.freebsd-java
I have SSH set up to log into the iMac running Debian. The assumption
is that the script is run on the iMac and it is exported to the
QuickSilver.
Is the SSH setup right? PMac to iMac? Also assume that the script is
run on the iMac and I am running a simple SSH ***@. Is it
$EXPORTED_ENV to $WORKING_DIRECTORY or $EXPORTED_ENVIRONMENT
ln -s
$USER_BINARY_PATHS?
.
I have Debian running on an iMac G4 and FreeBSD running on a QuickSilver G4.
1. The assumption is that the script is ran on the iMac. Considering
that SSH between both machines is set up, is the exporting:
a) From the iMac to the QuickSilver.
b) The inverse of the above.
And
c) Is it ran from the same terminal used for the SSH login
d) Or from another terminal connected on the target to the SSHed login?
If the exporting is done such as stated in d above, then how do I set
that up properly?
Also, does the shell type in the original environment need to match
the shell of the target environment or is it an irrelevant point?
I'm using the standard ssh user@ for logins.
If the method to use is NFS with a and b being replaced with the NFS
variables- being both server and client, then which similar method is
the correct one? Is the script setup in /usr/share/java,
/usr/lib/java, or both?
The following is what Harvard and I discussed with my reply to him added.
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=89377+0+archive/2008/freebsd-java/20080203.freebsd-java
I need a walk through with this or a skeleton to build on.
I want to do similar using Debian PowerPC as the original environment
and FreeBSD PowerPC as the target environment.
o java needs to be able to read from stdin. This means you
can't use "ssh -n", which again means that the build job has
to run in the foreground with access to the tty (yuk...).
Ok, is this from the source to the target or vice versa?
Most of the building is being done using the native C compiler onI need a walk through with this or a skeleton to build on.
I want to do similar using Debian PowerPC as the original environment
and FreeBSD PowerPC as the target environment.
o java needs to be able to read from stdin. This means you
can't use "ssh -n", which again means that the build job has
to run in the foreground with access to the tty (yuk...).
Ok, is this from the source to the target or vice versa?
the target of your porting efforts. There's just a few times
java needs to be run during the building. But since you don't
have a usable java on your target host, you need assistance from
another host where you have a usable java compiler.
In my setup I made the porting tree available via the same path
name on the "assist me" machine as on the actual target, using
NFS. I suggest you do the same, to stroke the dog with the
hairs...
I understand that this is advanced compiling.
Well...TtyX -> ttyY such that Y is the SSH session and X is the local tty.
How is it done?
The ssh'ing is done as part of the "java" script in boot-java/bin/, inHow is it done?
my case it has embedded the host name of the assist host I used, and
the full pathname on the assistance host of the actual working java
#! /bin/sh
d=`pwd`
where "bean" is the name of the NetBSD/i386 host I used to bootstrap
the java on NetBSD/amd64. You need to modify these scripts to fit
your environment.
I'm thinking that building the java dependencies such as ANT on the
target environment and then building the javavm and plugin. I could
then do a native build of everything again.
I'm not sure that's necessary.target environment and then building the javavm and plugin. I could
then do a native build of everything again.
once that is complete, do a native build on the target environment
ANT isn't installed on the host I did
the port to NetBSD/amd64 on. Then again I did this a fair while ago,
ref. 1.5 being "current" at the time, and I've not re-tried the
procedure with openjdk 7 (isn't that the current version at the
moment?)
OpenJDK8 is available; but, OpenJDK7 is the "standard."the port to NetBSD/amd64 on. Then again I did this a fair while ago,
ref. 1.5 being "current" at the time, and I've not re-tried the
procedure with openjdk 7 (isn't that the current version at the
moment?)
Regards,
- HÃ¥vard
Thanks for replying. I'm asking about to be certain everything that I- HÃ¥vard
understand everything; unfortunately, I'm afraid I'm losing people on
it. So, I'm going to post on the netbsd tech-misc help.
Yes, I will use what you told me here.
Anywhere that I am wrong, please let me know.
Thanks.