No bootstrap classes at: c:\erl5.7.4\lib\erts-5.7.3\ebin

[Andy Till]

Hey Guys

I'm having some trouble getting erl to run and get the message...

No bootstrap classes at: c:\erl5.7.4\lib\erts-5.7.3\ebin

Have I forgot to do something?

[Robert Virding]

Have you set both the environment variables ERL_ROOT and ERTS_VSN ?
For R14B you need

ERTS_VSN=5.8.1

At least you need these for UNIXes. I use a tiny shell script for this.

Robert

[Andy Till]

Thanks Robert, you put me on the right track. It was my ERTS version
that was wrong, but adding the ERTS_VSN environment variable doesn't
make a difference. 5.7.3 is the default hardcoded erts version but it
looks like the +e 5.7.4 command line argument would also have worked.

Next problem then :D

When I run erl I get the following exception...

C:\dev\erjang>erl
Exception in thread "main" java.lang.NoClassDefFoundError: kilim/S_O7
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Unknown
Source)
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at
erjang.EModuleLoader.load_compiled_module(EModuleLoader.java:154)
at erjang.EModuleLoader.load_module(EModuleLoader.java:83)
at erjang.EModuleLoader.load_module(EModuleLoader.java:64)
at
erjang.EModuleLoader.find_and_load_module(EModuleLoader.java:60)
at erjang.ERT.load_module(ERT.java:973)
at erjang.OTPMain.main(OTPMain.java:59)
at erjang.Main.main(Main.java:162)
Caused by: java.lang.ClassNotFoundException: kilim.S_O7
at erjang.EModuleClassLoader.findClass(EModuleClassLoader.java:
77)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
... 12 more

Looking at the erjang jar the class kilim.S_O7 doesn't exist. Any
ideas what is happening here?

On Dec 5, 9:00 pm, Robert Virding <rvird...@gmail.com> wrote:
> Have you set both the environment variables ERL_ROOT and ERTS_VSN ?
> For R14B you need
>
> ERTS_VSN=5.8.1
>
> At least you need these for UNIXes. I use a tiny shell script for this.
>
> Robert
>

[Andy Till]

I missed some information here, erjang was trying to load
erl_prim_loader-c889e3b6.jar from "documents and settings\user", S_O7
was in this jar. I put this in the erjang root directory and added it
explicitly to the classpath and now it gets a NoClassDefFoundError on
erjang.EFun0

[Kresten Krab Thorup]

Hi there,

Yes, it is not going to work to put the jars on the commmand-line classpath because these jars need to be loaded by a special loader that can generate EFunX and ETupleX classes as needed.

For some reason, the right kilim.S_XX class is not being generated into the jar; this could be some problem that appears only with specific versions of erts. Dunno.

Erjang uses the ERTS_VSN or +e to construct the directory from which to load the bootstrap BEAM files (ROOT/erts-${ERTS_VSN}/ebin I believe), nothing else.

We're testing only with the R14, so you may have run into some case where there's a problem for some reason.

Perhaps people here can report which versions of erts they have working?

Kresten

________________________________________
Fra: erj...@googlegroups.com [erj...@googlegroups.com] P&#229; vegne af Andy Till [totemk...@googlemail.com]
Sendt: 12. december 2010 21:50
Til: Erjang
Emne: [erjang] Re: No bootstrap classes at: c:\erl5.7.4\lib\erts-5.7.3\ebin

[Andy Till]

Hey Kresten

I downloaded Erlang R14B01 which uses erts-5.8.2 without much luck,
kilim.S_O7 is still not found. Is Erjang known to be working on
Windows?

Cheers

On Dec 13, 1:23 am, Kresten Krab Thorup <k...@trifork.com> wrote:
> Hi there,
>
> Yes, it is not going to work to put the jars on the commmand-line classpath because these jars need to be loaded by a special loader that can generate EFunX and ETupleX classes as needed.
>
> For some reason, the right kilim.S_XX class is not being generated into the jar; this could be some problem that appears only with specific versions of erts.  Dunno.
>
> Erjang uses the ERTS_VSN or +e to construct the directory from which to load the bootstrap BEAM files (ROOT/erts-${ERTS_VSN}/ebin I believe), nothing else.  
>
> We're testing only with the R14, so you may have run into some case where there's a problem for some reason.  
>
> Perhaps people here can report which versions of erts they have working?
>
> Kresten
>
> ________________________________________

> Fra: erj...@googlegroups.com [erj...@googlegroups.com] P&#229; vegne af Andy Till [totemkopf...@googlemail.com]

[eriksoe]

I've tried building and running the Erjang (from github) with R14A,
using JDK-1.6.0_23.
Results so far:
- The start script needs some tweaking to work under Cygwin... (but it
can be made to work)
- The class kilim.SO_6 is indeed reported as missing.
- The error report says that the error occurred while loading
erl_prim_loader. (So, it is one of the classes constituting
erl_prim_loader's translation which uses S_O6).
- However: the .erjang/erl_prim_loader-*.jar archive *does* contain a
kilim/S_O6.class file!
(as verified with "unzip -l", and also "jar tvf".) It also has the
same size as in the same jar file on my Linux system.

Summa summarum: the class file is present; why Java reports that it
cannot find it remains a mystery...

[eriksoe]

Just ran a simple test:
java -classpath "$f":lib/kilim-0.6-krab.jar kilim.S_O6
where "$f" is the path to erl_prim_loader-d876a88.jar.

Result on Windows, with JDK-1.6.0_23: "NoClassDefFoundError: kilim/
S_O6"
Result on Linux, with 1.6.0_22: "NoSuchMethodError: main"
The jar files look very much the same; they have the exact same file
size, for instance.

[eriksoe]

Never mind that last experiment; the file separator is different on
Windows...
Running

java -classpath "$f;lib/kilim-0.6-krab.jar" kilim.S_O6

gives me "NoSuchMethodError: main" as expected.

On 28 Dec., 02:30, eriksoe <erik...@gmail.com> wrote:
> Just ran a simple test:
>   java -classpath "$f":lib/kilim-0.6-krab.jar  kilim.S_O6
> where "$f" is the path to erl_prim_loader-d876a88.jar.
>
> Result on Windows, with JDK-1.6.0_23: "NoClassDefFoundError: kilim/
> S_O6"
> Result on Linux, with 1.6.0_22: "NoSuchMethodError: main"
> The jar files look very much the same; they have the exact same file
> size, for instance.

[snip]

[Pavlo Baron]

I have fixed that problem in my fork on GitHub few days ago and placed
a pull request with a solution description. Cygwin works great for me
now.

[Kresten Krab Thorup]

I integrated pavlos fix in trifork/erjang

[eriksoe]

On 28 Dec. 2010, 06:52, Pavlo Baron <pbit....@googlemail.com> wrote:
> I have fixed that problem in my fork on GitHub few days ago and placed
> a pull request with a solution description.

Right problem, slightly wrong fix - Java uses '/' as separator for
resource names, no matter the platform.

(I got suspicious because Java shouldn't be behaving differently just
because it's started by Cygwin; it doesn't "run on Cygwin" in that
sense. (Unless maybe if it's a JRE which is part of Cygwin - haven't
checked if one such exists at all.))

> Cygwin works great for me now.

You didn't have to change the start script?
I had to add some "if $TERM=cygwin... then use cygpath -w on certain
paths" logic. And a "-r" switch to read. (I'll push these changes on
occasion; at the moment my source copy in Windows isn't a proper
checkout.)

[Pavlo Baron]

Hi Erik,

File.separatorChar returns "\" on Windows, no matter if Cygwin is in
between. The code there does the following:

------------------------snip----------------------
String classFileName = name.replace('.', File.separatorChar) +
".class";
InputStream resource = super.getResourceAsStream(classFileName);
------------------------snap----------------------

It tries to load classes like "erjang\S_6.class" or so. This fails. It
should always load like "erjang/S_6.class". Here your comment fits
very well - it is general Java behavior/expectation to do so, so
Erjang code does wrong there on Windows.

Sinse my first commit was as non-invasive as possible, I solved it
with a fallback :) What I would suggest is to generally replace
File.separatorChar there through a hard "/" and drop the fallback. I'm
not sure about the future build strategy on Windows, but if this would
be Cygwin only (like Erlang), this would always work. I guess it would
even work on Windows without Cygwin, too.

If we agree on that, I can commit the final version.

---

As for the start script: as I started to dig deeper and to mix my
Erlang environment with Erjang, I began to experience some problems
which I couldn't quickly solve yet. For example, The .erlang file
doesn't get loaded:

----------------------------output------------------------------
pb@PBPC01 ~/code/ex/erjang (master)
$ ./ej
01.01.2011 08:53:31 erjang.EModuleManager$ModuleInfo
warn_about_unresolved
INFO: unresolved after load: code:is_module_native/1
|
=ERROR REPORT==== 1-Jan-2011::08:53:33 ===
file:path_eval([".","c:/Users/pb"],".erlang"): unknown POSIX error
Eshell V5.8.1.1 (abort with ^G)
1> 4 - 1.
3
2> q().
01.01.2011 08:53:45 erjang.EModuleManager$FunctionInfo$1 invoke
INFO: MISSING kernel:prep_stop/1
ok
3>
pb@PBPC01 ~/code/ex/erjang (master)
$
----------------------------output------------------------------

I see a couple of unresolved functions. But I can start ej and ejc and
work with them without any obvious problems. Does it behave any
similar to yours? I didn't have to do any script modification...

rgds
Pavlo

[Erik Søe Sørensen]

Den 01-01-2011 09:35, Pavlo Baron skrev:
> Hi Erik,
>
> File.separatorChar returns "\" on Windows, no matter if Cygwin is in
> between.

Cygwin is never in between; it may start the Java process, but is out of
the picture from then on.

> The code there does the following:
>
> ------------------------snip----------------------
> String classFileName = name.replace('.', File.separatorChar) +
> ".class";
> InputStream resource = super.getResourceAsStream(classFileName);
> ------------------------snap----------------------
>
> It tries to load classes like "erjang\S_6.class" or so. This fails. It
> should always load like "erjang/S_6.class". Here your comment fits
> very well - it is general Java behavior/expectation to do so, so
> Erjang code does wrong there on Windows.
>
> Sinse my first commit was as non-invasive as possible, I solved it
> with a fallback :)

Very reasonable - and your code worked fine, but was somewhat misleading.

> What I would suggest is to generally replace
> File.separatorChar there through a hard "/" and drop the fallback. I'm
> not sure about the future build strategy on Windows, but if this would
> be Cygwin only (like Erlang), this would always work. I guess it would
> even work on Windows without Cygwin, too.
>
> If we agree on that, I can commit the final version.

I already did - just before I commented here :-)

> ---
>
> As for the start script: as I started to dig deeper and to mix my
> Erlang environment with Erjang, I began to experience some problems
> which I couldn't quickly solve yet. For example, The .erlang file
> doesn't get loaded:

That's something to look into. I'll try to see what kind of unrecognized
I/O error this is about.

> ----------------------------output------------------------------
> pb@PBPC01 ~/code/ex/erjang (master)
> $ ./ej
> 01.01.2011 08:53:31 erjang.EModuleManager$ModuleInfo
> warn_about_unresolved
> INFO: unresolved after load: code:is_module_native/1
> |
> =ERROR REPORT==== 1-Jan-2011::08:53:33 ===
> file:path_eval([".","c:/Users/pb"],".erlang"): unknown POSIX error
> Eshell V5.8.1.1 (abort with ^G)
> 1> 4 - 1.
> 3
> 2> q().
> 01.01.2011 08:53:45 erjang.EModuleManager$FunctionInfo$1 invoke
> INFO: MISSING kernel:prep_stop/1
> ok
> 3>
> pb@PBPC01 ~/code/ex/erjang (master)
> $
> ----------------------------output------------------------------
>
> I see a couple of unresolved functions. But I can start ej and ejc and
> work with them without any obvious problems. Does it behave any
> similar to yours? I didn't have to do any script modification...

I get "Unable to access jarfile /path/to/file.jar" when starting ej in a
Cygwin shell. The path is a Cygwin one, starting with "/home/", so this
makes sense; I wonder what jar path Java receives in your setup?

[eriksoe]

On 1 Jan., 14:00, Erik Søe Sørensen <erik...@gmail.com> wrote:
> Den 01-01-2011 09:35, Pavlo Baron skrev:> Hi Erik,

> > As for the start script: as I started to dig deeper and to mix my
> > Erlang environment with Erjang, I began to experience some problems
> > which I couldn't quickly solve yet. For example, The .erlang file
> > doesn't get loaded:
>
> That's something to look into. I'll try to see what kind of unrecognized
> I/O error this is about.

Doing just that:

> > ----------------------------output------------------------------
> > pb@PBPC01 ~/code/ex/erjang (master)
> > $ ./ej
> > 01.01.2011 08:53:31 erjang.EModuleManager$ModuleInfo
> > warn_about_unresolved
> > INFO: unresolved after load: code:is_module_native/1
> > |
> > =ERROR REPORT==== 1-Jan-2011::08:53:33 ===
> > file:path_eval([".","c:/Users/pb"],".erlang"): unknown POSIX error
> > Eshell V5.8.1.1  (abort with ^G)
> > 1>  4 - 1.
> > 3
> > 2>  q().
> > 01.01.2011 08:53:45 erjang.EModuleManager$FunctionInfo$1 invoke
> > INFO: MISSING kernel:prep_stop/1
> > ok
> > 3>
> > pb@PBPC01 ~/code/ex/erjang (master)
> > $
> > ----------------------------output------------------------------
>
> > I see a couple of unresolved functions.

Those warnings are benign; just ignore them.

When I try calling file:path_eval() like the above, I get {error,
{bad_response_from_port," "}}).
Same for file:consult() - and, more to the point, file:open(). But
file:read_file() behaves just fine. So something is broken there, on
Windows (it works OK on Linux).

[Pavlo Baron]

> Cygwin is never in between; it may start the Java process, but is out of
> the picture from then on.

This is not 100% correct - only in some cases (in some stupid ones :
( ) you don't see Cygwin as the "man in the middle". But for example
the code:

-----------------snip--------------------
try {
Properties env = new Properties();

env.load(Runtime.getRuntime().exec("env").getInputStream());
System.out.println(env.get("PATH"));
}
catch (Exception e) {

}
-----------------snap-------------------

works great for Cygwin returning its modified PATH chain (Cygwin'sh
instead of classic Windows with backslashes). The most stupid thing
where you cannot "catch" Cygwin is when you ask for System.getProperty
- here, Java asks Windows natively. And this includes "user.home" and
such things. Well, those things are the most important ones, too...

> I already did - just before I commented here :-)

cool :)

> > As for the start script: as I started to dig deeper and to mix my
> > Erlang environment with Erjang, I began to experience some problems
> > which I couldn't quickly solve yet. For example, The .erlang file
> > doesn't get loaded:
>
> That's something to look into. I'll try to see what kind of unrecognized
> I/O error this is about.

I couldn't figure out what happens there at the first glance, though I
found a spot where posix errors get thrown in situations like that.
Maybe I'll have a deeper look, too, and we can combine the results

> I get "Unable to access jarfile /path/to/file.jar" when starting ej in a
> Cygwin shell. The path is a Cygwin one, starting with "/home/", so this
> makes sense; I wonder what jar path Java receives in your setup?

I did "echo $ERJANG_DIR/erjang-0.1.jar" and I get "./erjang-0.1.jar"
when I execute ./ej standing in the ERJ_ROOT. No further arguments to
the script, but it also works standing in another folders. In this
case, I have ERJ_ROOT in my PATH, and the echo gives me: "/c/Users/pb/
code/ex/erjang/erjang-0.1.jar". ERJ_ROOT = ""/c/Users/pb/code/ex/
erjang".

From my experience, Cygwin's "/home" could be smth. completely
different than "~". "~" would go to your Windows user's home, while
Cygwin's "/home" can be just a folder under Cygwin installation's
root. Maybe this helps...

[Pavlo Baron]

> Those warnings are benign; just ignore them.

just yet unimplemented stuff, correct?

>
> When I try calling file:path_eval() like the above, I get {error,
> {bad_response_from_port,"    "}}).
> Same for file:consult() - and, more to the point, file:open(). But
> file:read_file() behaves just fine. So something is broken there, on
> Windows (it works OK on Linux).

Exactly, did a similar test last time. Really going to have a look at
it since I have Triq path in .erlang. Though I don't really need it
when I can run separate tests from an IDE, but anyway it's annoying
and almost the only thing which currently keeps Erjang from running on
Cygwin here.

[eriksoe]

On 1 Jan., 16:34, Pavlo Baron <pbit....@googlemail.com> wrote:
> > Cygwin is never in between; it may start the Java process, but is out of
> > the picture from then on.
>
> This is not 100% correct - only in some cases (in some stupid ones :
> ( ) you don't see Cygwin as the "man in the middle". But for example
> the code:
>
> -----------------snip--------------------
> try {
>             Properties env = new Properties();
>
> env.load(Runtime.getRuntime().exec("env").getInputStream());
>             System.out.println(env.get("PATH"));
>         }
>         catch (Exception e) {
>
>         }
> -----------------snap-------------------
>
> works great for Cygwin returning its modified PATH chain (Cygwin'sh
> instead of classic Windows with backslashes). The most stupid thing
> where you cannot "catch" Cygwin is when you ask for System.getProperty
> - here, Java asks Windows natively. And this includes "user.home" and
> such things. Well, those things are the most important ones, too...

Environment variables are passed to the Java process at the time it is
started.

> > I already did - just before I commented here :-)
>
> cool :)
>
> > > As for the start script: as I started to dig deeper and to mix my
> > > Erlang environment with Erjang, I began to experience some problems
> > > which I couldn't quickly solve yet. For example, The .erlang file
> > > doesn't get loaded:
>
> > That's something to look into. I'll try to see what kind of unrecognized
> > I/O error this is about.
>
> I couldn't figure out what happens there at the first glance, though I
> found a spot where posix errors get thrown in situations like that.
> Maybe I'll have a deeper look, too, and we can combine the results

I've found something out:
Java doesn't really support getting access to FD numbers.
EFile "cheats" and uses reflection to access the field
java.io.FileDescriptor.fd. On Unix-like systems, this field exists; on
Windows it doesn't - so the FD returned by the driver is always -1.
I don't quite know what to do on Windows, then; I hope returning a
constant dummy FD value will work.

> > I get "Unable to access jarfile /path/to/file.jar" when starting ej in a
> > Cygwin shell. The path is a Cygwin one, starting with "/home/", so this
> > makes sense; I wonder what jar path Java receives in your setup?
>
> I did "echo $ERJANG_DIR/erjang-0.1.jar" and I get "./erjang-0.1.jar"
> when I execute ./ej standing in the ERJ_ROOT. No further arguments to
> the script, but it also works standing in another folders. In this
> case, I have ERJ_ROOT in my PATH, and the echo gives me: "/c/Users/pb/
> code/ex/erjang/erjang-0.1.jar". ERJ_ROOT = ""/c/Users/pb/code/ex/
> erjang".
>
> From my experience, Cygwin's "/home" could be smth. completely
> different than "~". "~" would go to your Windows user's home, while
> Cygwin's "/home" can be just a folder under Cygwin installation's
> root. Maybe this helps...

OK, I've spotted an error in the ej script which makes it use `which
ej` rather than the version actually executed. That might explain the
differences. I'll try to make the script work in general.

[eriksoe]

On 1 Jan., 16:42, Pavlo Baron <pbit....@googlemail.com> wrote:
> > Those warnings are benign; just ignore them.
>
> just yet unimplemented stuff, correct?

Yes - and more importantly, stuff that isn't essential for these
purposes.

> > When I try calling file:path_eval() like the above, I get {error,
> > {bad_response_from_port,"    "}}).
> > Same for file:consult() - and, more to the point, file:open(). But
> > file:read_file() behaves just fine. So something is broken there, on
> > Windows (it works OK on Linux).
>
> Exactly, did a similar test last time. Really going to have a look at
> it since I have Triq path in .erlang. Though I don't really need it
> when I can run separate tests from an IDE, but anyway it's annoying
> and almost the only thing which currently keeps Erjang from running on
> Cygwin here.

Try to pull from my branch now, then.
(For what it's worth, you could also add '-eval "code:add_path(...)."'
on the command line.)

[Pavlo Baron]

> Try to pull from my branch now, then.
> (For what it's worth, you could also add '-eval "code:add_path(...)."'
> on the command line.)

cool - did the cherry-pick of your commit - the 255 dummy seems to do
just fine - no complaining about path_eval at ej startup anymore :)