Please help, "package android.util does not exist"

[Aleksandar "Shark" Milenkovic]

Hi,

first post here, so don't be harsh on me if this turns out to be a
noob question.

First of all - I need to avoid Eclipse based solutions. I'm debugging
DalvikVM so I'm manually putting log calls everywhere and pretty much
rip-opening the VM because it errors on floating point calculations.
My IDE is gedit for now.

I'm running CTS tests and I've placed a few Log calls in
T_div_double_4.java, right above the return a/b and below the assert
line in Test_div_double.java; thing is, I get a "unknown symbol
variable Log" after importing android.util.Log; I need those because
i'm logging complete bytecode interpreted/executed by DalvikVM, and I
need some way to locate where to look because a 5 line test generates
about 25000 lines of bytecode.

I have the android-sdk-linux_x86 folder so I know I've got the source
somewhere. ADB works.

I figure it's a classpath thing (ergo the noob warning) but if it's
not - I need any kind of log to show up in logcat. Workarounds are
good too.

I tried java.util.logging.Logger.getLogger("MARKER").info("-----------
ABOVE THIS"); followed by adb shell setprop log.tag.MARKER VERBOSE to
no avail. My original intent is to somehow get Log.e("MARKER",
"---------- ABOVE THIS"); working so i tried hack-replacing it with
the java logger. Since it never got to work, I wanna sort this Log s#!
t out and start analyzing the relevant bytecode.

So, any ideas? Ideas followed by examples or partial solutions would
be greatly welcomed :)

Once again, LOG calls work fine from C, they just don't get recognized
from Java. In other words, logcat correctly catches everything from C,
but nothing from java because I can't even compile/build when using
log because java doesn't see the android.util package.

Thanks in advance,
Aleksandar Milenkovic - Shark

P.S. In case you wanna know whats wrong - the VM is erroneous while
doing floating point calculations with Java's Double.MIN_VALUE
(4.9E-324) while calculating a cube root of that. I know cube root
goes thru JNI and I've written two test apps - one in C and one in
Java to test the expected value. The one in C returned correct value -
1.7somethingE-108 while Java consistently returns 9.somethingE-108. So
analyzing bytecode will give me an insight if the VM is calculating it
wrong or if there's some problems with JNI communication with native
cbrt and ieee_cbrt functions (which work fine in the C test app -
thats how i crossed off 'hardware error' as the root cause and figured
the issue is java only)