ecj classpath
by David Walluck
When trying to compile with ecj, I am getting the following error:
The type java.lang.Object cannot be resolved
I am confused as to how ecj finds rt.jar since I don't see it being added to the
classpath or bootclasspath. I have even tried adding it explicitly to either of
these and it doesn't seem to help.
--
Sincerely,
David Walluck
<david(a)zarb.org>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
18 years, 8 months
Try again - photran 3.0
by Orion Poplawski
Okay, starting up again trying to work on photran 3.0, and looking for
lots of help....
Here is the description from the photran group of how to build. Now,
this is all done in Eclipse. I can easily enough use cvs directly to
check out all the source and patch them together. But I'm not sure how
I should then go about building the package. Any help appreciated...
Unlike Photran 2.1 and its predecessor(s), Photran 3.0 is built *on top of*
the CDT. However, there are still a few minor changes that have to be made
to the CDT to get it to support additional languages. We are hoping the CDT
folks will commit those changes to the CDT proper, but until they do, things
are a bit more complicated for us.
PART I. Check out the CDT sources from CVS.
1. In Eclipse, switch to the CVS Repository Exploring perspective.
2. Right-click the CVS Repositories view; choose New > Repository Location
3. Enter the following information, then click Finish:
Host name: dev.eclipse.org
Repository path: /home/tools
Connection type: pserver
Username: anonymous
Password: (no password)
4. Right-click on :pserver:anonymous at dev.eclipse.org:/home/tools, and
choose
Refresh Branches...
5. Select the following, and click OK:
org.eclipse.cdt-build
org.eclipse.cdt-core
org.eclipse.cdt-doc
org.eclipse.cdt-debug
org.eclipse.cdt-launch
When prompted, tell it to Search Deeply.
6. Expand :pserver:anonymous at dev.eclipse.org:/home/tools,
and then expand Versions (in the CVS Repositories view)
7. Under org.eclipse.cdt-build, expand org.eclipse.cdt-build CDT_3_0_RC2
8. Right click and check out all of the org.eclipse.cdt.* packages
EXCEPT for the ones ending in "tests" (why bother testing?)
9. Do the same with org.eclipse.cdt-core, org.eclipse.cdt-debug,
org.eclipse.cdt-doc, and org.eclipse.cdt-launch
10. You now have the CDT source code. Make sure it compiles successfully
(lots of warnings, but no errors).
PART II. Check out the Photran source and the CDT patches.
11. In Eclipse, switch to the CVS Repository Exploring perspective.
12. Right-click the CVS Repositories view; choose New > Repository Location
13. Enter the following information, then click Finish:
Host name: www.photran.org
>>>>>> Repository path: /usr/local/photran30 <<<<<< THIS HAS
CHANGED!!!
Connection type: extssh
Username/passwd: (we gave you this)
14. Expand extssh:username at www.photran.org:/usr/local/photran30,
then expand HEAD (in the CVS Repositories view)
15. Right-click and check out all of the org.eclipse.fdt projects as well
as org.eclipse.photran. DO NOT check out org.eclipse.photran.parser.
You only need this project if you will be regenerating the parser
from the
grammar. (The parser is included in the org.eclipse.fdt.core plugin
as a JAR file. This way, the parser does not have to be recompiled
every time you rebuild Photran.)
The sources will NOT compile at this point; you must complete the
following...
PART III. Patch the CDT sources
16. Go to a bash prompt. Change to your Eclipse workspace directory
(the one containing all of the org.eclipse.cdt, org.eclipse.fdt, and
org.eclipse.photran projects).
17. Change to the org.eclipse.photran directory.
18. Run ./install
19. Go back into eclipse. Refresh all of the org.eclipse.cdt packages.
(Click the first, shift-click the last, right-click, choose Refresh.)
The sources should all compile (albeit with about 640 warnings).
--
Orion Poplawski
System Administrator 303-415-9701 x222
Colorado Research Associates/NWRA FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com
18 years, 8 months
Is tomcat-connectors-4.0.6 buildable on FC4
by crisppy fernandes
Hi All
can anybody give me some pointer or info related to my problem..
I am facing many issues related to building tomcat-connectors-4.0.6 on FC4 .
After solving few problems i have reached a point where its searching
for one struct i.e.
JDK1_1InitArgs. and after searching more i have come to know that
definition of this struct is now removed from source i.e jni.h file
So do we have fix for this. or i am missing something.
some or any help welcome.
Crisppy f.
--
Crisppy Fernandes
18 years, 8 months
Where to configure CLASSPATH and other stuff on my FC4 box
by C.F. Scheidecker Antunes
Hello all,
Before using JPackage I was used to install Java manually. Now I've
built the rpm packages using JPackage and had them installed.
It is flawless and works great. However I have a question that I was
hoping you could help me with.
Back in the good ol'days I used to update either the /etc/profile or
.bashrc of a specific user to have the classpath and other stuff set.
So, this is a part of an old /etc/profile of mine:
CLASSPATH=$CLASSPATH:/opt/jaf-1.0.2/activation.jar
CLASSPATH=$CLASSPATH:/opt/jakarta-regexp-1.3/jakarta-regexp-1.3.jar
CLASSPATH=$CLASSPATH:/opt/javamail-1.3.1/mail.jar:.
JAVA_HOME=/opt/java
#CATALINA_HOME=/opt/tomcat
export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC CLASSPATH JAVA_HOME
Now, I've noticed that Jpackage has an /etc/java/java.conf file which
makes me wonder the place where java config stuff such as classpath,
catalina_home and java_home are supposed to be.
Is there any documentation regarding this issue? Are there any standards
for them? Any ideas or suggestions?
By the way, how can I get some documentation on Jpackage? The homepage
is somewhat confusing.
Thanks in advance,
C.F.
18 years, 8 months
RE: [fedora-java] rssowl: libgcj bugs that need fixing for it torun
by Boehm, Hans
There is some code in earlier versions of the
GC to do thread registration, but it's very platform specific
and thus ugly. I think there wasn't a real facility for Linux.
The tricky part of doing this in general is that the GC needs
to know the stack bounds for the newly registered thread. It
can find the hot end, but the cold end is often hard. GC7
addresses this by providing two ways to get the cold stack
end:
1) A generic mechanism that just takes the address of a local.
The collector knows how to implement that everywhere. We just
provide a function that calls back one of your functions f with
a stack address that's guaranteed to be "below" f. Since this
is not the actual base of the stack, the GC ends up tracing
pointers only in "new" frames.
2) A separate routine that tries to discover the stack base
in a platform dependent way. It may fail. (And currently
usually does.) I think that for Linux, pthread_getattr_np
works for most threads, though perhaps not the main one.
(The thread pointer also probably works in many cases.)
I'm not sure the JNI primitives can be implemented in terms
of (1). Certainly if you use CNI that has different semantics,
in that the GC doesn't see pointers "below" you on the stack.
We may need (2) to work for gcj.
Hans
> -----Original Message-----
> From: Robin Green [mailto:greenrd@greenrd.org]
> Sent: Thursday, July 28, 2005 1:51 PM
> To: Anthony Green; Boehm, Hans
> Cc: tromey(a)redhat.com; Discussion list for java related
> Fedora development
> Subject: RE: [fedora-java] rssowl: libgcj bugs that need
> fixing for it torun
>
>
> > On Thu, 2005-07-28 at 11:34 -0700, Boehm, Hans wrote:
> > > [I missed the beginning of this thread initially.]
> > >
> > > I'm actually trying to work on some of these issues. Some status:
> >
> > Cool.
> >
> > Robin - is there a local hack/patch we can apply to swt
> and/or rssowl
> > to work around this problem until a real fix from Hans
> migrates into
> > GCC?
>
> I'm a bit out of my depth here.
>
> Hans wrote: "Gc7 (even the released, but very experimental
> alpha3 version) has a thread registration interface." This
> implies that the version in gcc _doesn't_ have a thread
> registration interface, or anything that could be hacked
> together into one. Is that surmise correct?
>
> If so, the only other thing I can think of is to spawn a new
> registered thread instead of calling AttachCurrentThread, and
> somehow translate all C->Java invocations on the unregistered
> thread into inter-thread calls onto the new registered
> thread. In other words, keep all Java code on a separate thread. Yuck.
>
> --
> Robin
>
18 years, 9 months
where are the fedora-specific tomcat5 docs? other docs?
by John M. Gabriele
Someone on this list mentioned to me how to start and stop
tomcat ("service tomcat5 start" and "service tomcat5 stop").
That got me thinking: I hadn't yet looked in the fedora-
specific tomcat docs. Where in the docs does it say that's
how to start and start tomcat?
Lesse:
[john@localhost ~]$ man tomcat
No manual entry for tomcat
[john@localhost ~]$ man tomcat5
No manual entry for tomcat5
[john@localhost ~]$ apropos tomcat
tomcat: nothing appropriate
Hmm... weird. Let's see if I've got a tomcat5-docs
package installed, or any docs at all on tomcat:
[john@localhost ~]$ rpm -qa | grep tomcat
tomcat5-5.0.30-5jpp_6fc
tomcat5-webapps-5.0.30-5jpp_6fc
tomcat5-servlet-2.4-api-5.0.30-5jpp_6fc
tomcat5-admin-webapps-5.0.30-5jpp_6fc
tomcat5-jasper-5.0.30-5jpp_6fc
No docs rpm. Let's see about some docs in
the tomcat5 rpm:
[john@localhost ~]$ rpm -ql tomcat5 | grep doc
/usr/share/doc/tomcat5-5.0.30
/usr/share/doc/tomcat5-5.0.30/BENCHMARKS.txt
/usr/share/doc/tomcat5-5.0.30/LICENSE
/usr/share/doc/tomcat5-5.0.30/RELEASE-NOTES
/usr/share/doc/tomcat5-5.0.30/RELEASE-PLAN-5.0.txt
/usr/share/doc/tomcat5-5.0.30/RUNNING.txt
/usr/share/doc/tomcat5-5.0.30/TOMCAT4.README.RPM
Ah, here we are:
[john@localhost ~]$ less /usr/share/doc/tomcat5-5.0.30/RUNNING.txt
Uh oh. Generic docs (nothing dealing with running on GNU/Linux).
Hmm... maybe there's a tomcat-docs rpm that I need to install:
[john@localhost ~]$ yum search tomcat | grep i386
tomcat5.i386 5.0.30-5jpp_6fc base
tomcat5-servlet-2.4-api.i386 5.0.30-5jpp_6fc base
tomcat5-servlet-2.4-api-javadoc.i386 5.0.30-5jpp_6fc base
tomcat5-jasper.i386 5.0.30-5jpp_6fc base
tomcat5-jasper-javadoc.i386 5.0.30-5jpp_6fc base
tomcat5-webapps.i386 5.0.30-5jpp_6fc base
tomcat5-admin-webapps.i386 5.0.30-5jpp_6fc base
mod_jk.i386 1.2.6-3jpp_4fc base
mod_jk-manual.i386 1.2.6-3jpp_4fc base
tomcat5.i386 5.0.30-5jpp_6fc installed
tomcat5-webapps.i386 5.0.30-5jpp_6fc installed
tomcat5-servlet-2.4-api.i386 5.0.30-5jpp_6fc installed
tomcat5-admin-webapps.i386 5.0.30-5jpp_6fc installed
tomcat5-jasper.i386 5.0.30-5jpp_6fc installed
Uh oh. No dice. [starting to get that icy feeling down my back]
Well, last ditch effort: maybe there's something in here:
[john@localhost ~]$ rpm -qi tomcat5
[snip]
Summary : Apache Servlet/JSP Engine, RI for Servlet 2.4/JSP 2.0 API
Description :
Server that conforms to the Servlet 2.4 and JSP 2.0
specifications from Java Software.
Develop Web applications in Java.
:(
Hmm... Why didn't the rpm packager create at least a simple
readme saying how to stop and start this software?
Maybe I'm missing something basic: does Fedora *have* doc rpms?
Is it that maybe Red Hat doesn't worry too much about the docs
since they sell support for RHEL, and it really doesn't pay
for them to supply docs? Is this a recurring theme for many other
Fedora Core packages that are packaged by Red Hat?
BTW, that isn't a dig at Red Hat. I understand they do an
enormous amount of work just to give us FC, and that they rigidly
adhere to free software standards for the good of the community,
and that they have to stay in business so they can continue to
pay developers to work on free software. :) Heck, I've got a RH
sticker on my car. :) I like RH. But it *is* possible
that they reckon that it doesn't pay to *also* create docs for
software that they plan to sell support for.
Thanks,
---J
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
18 years, 9 months
