Обсуждение: Problems Compiling eRserver
I'm trying to build erserver_v1.2 on a SuSE 8.2 server.
I've got Sun's j2sdk1.4.2_02 and the following env variables set:
LESSKEY=/etc/lesskey.bin
INFODIR=/usr/local/info:/usr/share/info:/usr/info
MANPATH=/usr/share/man:/usr/local/man:/usr/X11R6/man:/opt/gnome2/man:/opt/gnome/man
HOSTNAME=linux
XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB
HOST=linux
SHELL=/bin/bash
TERM=xterm
PROFILEREAD=true
HISTSIZE=1000
OLDPWD=/root
JRE_HOME=/usr/java/j2sdk1.4.2_02/jre
USER=root
LS_COLORS=no=00:fi=00:di=01;34:ln=00;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31:ex=00;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*
.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.deb=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z
oo=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tb2=00;31:*.tz2=00;31:*.tbz2=00;31:*.avi=01;35:*.bmp=01;35:*.fli=01;35:*.gif=01;35:*.jpg=01;
35:*.jpeg=01;35:*.mng=01;35:*.mov=01;35:*.mpg=01;35:*.pcx=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.ppm=01;35:*.tga=01;35:*.tif=01;35:*.xbm=01;3
5:*.xpm=01;35:*.dl=01;35:*.gl=01;35:*.aiff=00;32:*.au=00;32:*.mid=00;32:*.mp3=00;32:*.ogg=00;32:*.voc=00;32:*.wav=00;32:
POSTGRES_INCLUDE=/usr/include/pgsql/
XNLSPATH=/usr/X11R6/lib/X11/nls
HOSTTYPE=i386
PAGER=less
MINICOM=-c on
PATH=/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome2/bin:/opt/gnome/bin:/opt/kde3/bin
:/usr/java/j2sdk1.4.2_02/bin/
CPU=i686
JAVA_BINDIR=/usr/java/j2sdk1.4.2_02/bin/
INPUTRC=/etc/inputrc
PWD=/root/erserver_v1.2
JAVA_HOME=/usr/java/j2sdk1.4.2_02
TEXINPUTS=:/root/.TeX:/usr/share/doc/.TeX:/usr/doc/.TeX
SHLVL=1
HOME=/root
LESS_ADVANCED_PREPROCESSOR=no
OSTYPE=linux
no_proxy=localhost
RC_LC_COLLATE=POSIX
LESS=-M -I
MACHTYPE=i686-suse-linux
LOGNAME=root
RC_LANG=en_US
LC_CTYPE=en_US
LESSOPEN=lessopen.sh %s
INFOPATH=/usr/local/info:/usr/share/info:/usr/info
POSTGRES_LIB=/usr/lib/
LESSCLOSE=lessclose.sh %s %s
JAVA_ROOT=/usr/java/j2sdk1.4.2_02
COLORTERM=1
I have the following postgresql RPM packages installed:
postgresql-jdbc-7.3-20
postgresql-libs-7.3.2-24
postgresql-python-7.3.2-24
postgresql-server-7.3.2-24
postgresql-7.3.2-24
postgresql-docs-7.3.2-24
postgresql-devel-7.3.2-24
postgresql-test-7.3.2-24
My configure line is:
./configure --with-pgincludes=/usr/include/pgsql/ # (this location is
provided by the postgresql-devel RPM)
Here's the 'make' results. (trimmed down a bit to get just the pertinent
stuff.
# make
cd java; /bin/sh ./build.sh create; cd ..
WhoisJ Build System
-------------------
REPLIC_HOME is .
Saving CLASSPATH:
New CLASSPATH is:
lib/jdbc7.0-1.2.jar:lib/log4j.jar:lib/xerces.jar
New ANT_HOME is ./tools
Ant version 1.3alpha compiled on December 30 2000
Buildfile: build.xml
Detected Java Version: 1.3
Detected OS: Linux
Project base dir set to: /root/erserver_v1.2/java
Build sequence for target `create' is [setup-properties, prepare,
prepare-lib, compile, jars, create]
Complete build sequence is [setup-properties, prepare, prepare-lib,
compile, jars, create, usage, help, clean-car, clean, car]
setup-properties:
[property] Override ignored for dist.dir
prepare:
prepare-lib:
compile:
[javac] com/postgres/util/cmd/ArgCmd.java added as
/root/erserver_v1.2/java/build/classes/com/postgres/util/cmd/ArgCmd.class doesn't exist.
[javac] com/postgres/util/cmd/GenericCmd.java added as
/root/erserver_v1.2/java/build/classes/com/postgres/util/cmd/GenericCmd.class doesn't exist. [javac]
com/postgres/util/cmd/CmdLine.javaadded as /root/erserver_v1.2/java/build/classes/com/postgres/util/cmd/CmdLine.class
doesn'texist.
.
.
.
[javac] Compiling 61 source files to
/root/erserver_v1.2/java/build/classes
[javac] Using modern compiler
[javac] Compilation args: -d /root/erserver_v1.2/java/build/classes
-classpath
/root/erserver_v1.2/java/build/classes:/root/erserver_v1.2/java/tools/lib/ant.jar:/root/erserver_v1.2/java/tools/lib/optional.jar:/root/erserver_v1.2/java/tools/lib/stylebook-1.0-b2.jar:/root/erserver_v1.2/java/tools/lib/xalan_1_2_D02.jar:/root/erserver_v1.2/java/lib/jdbc7.0-1.2.jar:/root/erserver_v1.2/java/lib/log4j.jar:/root/erserver_v1.2/java/lib/xerces.jar:/usr/java/j2sdk1.4.2_02/lib/tools.jar:/root/erserver_v1.2/java/src:/root/erserver_v1.2/java/build/lib/jdbc7.0-1.2.jar:/root/erserver_v1.2/java/build/lib/log4j.jar
-sourcepath/root/erserver_v1.2/java/src -g
[javac] Files to be compiled:
/root/erserver_v1.2/java/src/com/postgres/util/cmd/ArgCmd.java
/root/erserver_v1.2/java/src/com/postgres/util/cmd/GenericCmd.java
/root/erserver_v1.2/java/src/com/postgres/util/cmd/CmdLine.java
.
.
.
[javac] An exception has occurred in the compiler (1.4.2_02). Please
file a bug at the Java Developer Connection
(http://java.sun.com/cgi-bin/bugreport.cgi) after checking the Bug
Parade for duplicates. Include your program and the following diagnostic
in your report. Thank you.
[javac] java.lang.InternalError: jzentry == 0,
[javac] jzfile = 135350096,
[javac] total = 556,
[javac] name = /root/erserver_v1.2/java/lib/xerces.jar,
[javac] i = 1,
[javac] message = invalid LOC header (bad signature)
[javac] at java.util.zip.ZipFile$2.nextElement(ZipFile.java:321)
[javac] at
com.sun.tools.javac.v8.code.ClassReader.openArchive(ClassReader.java:975)
[javac] at
com.sun.tools.javac.v8.code.ClassReader.list(ClassReader.java:1218)
[javac] at
com.sun.tools.javac.v8.code.ClassReader.listAll(ClassReader.java:1339)
[javac] at
com.sun.tools.javac.v8.code.ClassReader.fillIn(ClassReader.java:1361)
[javac] at
com.sun.tools.javac.v8.code.ClassReader.complete(ClassReader.java:1052)
[javac] at
com.sun.tools.javac.v8.code.Symbol.complete(Symbol.java:372)
[javac] at
com.sun.tools.javac.v8.comp.Enter.visitTopLevel(Enter.java:467)
[javac] at
com.sun.tools.javac.v8.tree.Tree$TopLevel.accept(Tree.java:390)
[javac] at
com.sun.tools.javac.v8.comp.Enter.classEnter(Enter.java:442)
[javac] at
com.sun.tools.javac.v8.comp.Enter.classEnter(Enter.java:456)
[javac] at
com.sun.tools.javac.v8.comp.Enter.complete(Enter.java:596)
[javac] at
com.sun.tools.javac.v8.comp.Enter.main(Enter.java:582)
[javac] at
com.sun.tools.javac.v8.JavaCompiler.compile(JavaCompiler.java:331)
[javac] at com.sun.tools.javac.v8.Main.compile(Main.java:569)
[javac] at com.sun.tools.javac.Main.compile(Main.java:36)
[javac] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[javac] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[javac] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[javac] at java.lang.reflect.Method.invoke(Method.java:324)
[javac] at
org.apache.tools.ant.taskdefs.Javac.doModernCompile(Javac.java)
[javac] at
org.apache.tools.ant.taskdefs.Javac.execute(Javac.java)
[javac] at org.apache.tools.ant.Target.execute(Target.java)
[javac] at org.apache.tools.ant.Project.runTarget(Project.java)
[javac] at
org.apache.tools.ant.Project.executeTarget(Project.java)
[javac] at
org.apache.tools.ant.Project.executeTargets(Project.java)
[javac] at org.apache.tools.ant.Main.runBuild(Main.java)
[javac] at org.apache.tools.ant.Main.main(Main.java)
BUILD FAILED
/root/erserver_v1.2/java/build.xml:146: Compile failed, messages should
have been provided.
.
.
.
Am I missing something?
I believe I have all the pre-reqs fulfilled per the docs.
Any help is appreciated
Thank You,
Matthew Montgomery
On Fri, Nov 07, 2003 at 02:44:54PM -0600, Matthew Montgomery wrote:
> My configure line is:
>
> ./configure --with-pgincludes=/usr/include/pgsql/ # (this location is
> provided by the postgresql-devel RPM)
Are you sure that's the right one? You actually need to be pointing
to spi.h, IIRC. But that's not your problem.
> [javac] jzfile = 135350096,
> [javac] total = 556,
> [javac] name = /root/erserver_v1.2/java/lib/xerces.jar,
The problem is you have a corrupt xerces.jar file. Check the current
CVS head out instead of using the one you have.
BTW, there's a list just for erserver. You'll probably get better
help there. I suggest noodling around the erserver site, because the
archive has an explanation of this.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
I would like to hear about any issues related to erserver. I was a little concerned about its use of Java. Java is a great tool for creating application frameworks for the payroll department, but using it for back-end system-level application programming is a bit unnerving. Java is generally slow, memory and CPU intensive and doesn't provide for tight integration like C/C++ applications. Thanks
...and on Fri, Nov 28, 2003 at 03:27:56PM -0500, Renney Thomas used the keyboard:
>
> I would like to hear about any issues related to erserver. I was a
> little concerned about its use of Java. Java is a great tool for
> creating application frameworks for the payroll department, but using it
> for back-end system-level application programming is a bit unnerving.
> Java is generally slow, memory and CPU intensive and doesn't provide for
> tight integration like C/C++ applications.
>
> Thanks
Just a comment on Java, not quite related to your post, Renney. It is by
no means intended as a flamebait, I would just like to remind you all that
the times when Java was a memory and cpu hog are generally almost over.
I see this kind of attitude on a daily basis, and it almost kind of makes
me sad, because the illusion that people accepting such a stance regarding
ANY tool have put upon themselves is really hurting themselves in the end,
as it's usually related to anecdotal and outdated evidence, but most of all,
heresy and lack of real proof (not of slowness in this case, hehe, ANYONE
can write a bad program :)).
The fact you need a 20-30% faster cpu to have Java apps working as smoothly
as they would if one used a C application (and i won't even _attempt_ to
mention C++ here, because it is, in my not-so-humble opinion, far worse than
Java), is contrasted by the massive cut in development time, manpower needed
to do the job and the number of bugs produced during the development period.
Double free() crash due to a missing #ifdef? Eeew. Sorry for you, lad.
As with all development tools, this is mainly a "the right tool for the
right job" issue, no doubt, and I sure as hell wouldn't want to write a
realtime application in Java, but the man doing it has no less to do with
it than the job itself. A good programmer can compensate for the loss in
execution time in far less than the time they'd have used for debugging a
tool developed in C.
There are many performance and optimization documents and books for Java,
but it is not a "tweak" that will make your Java program work fast. You need
to be capable of performing a bit more profound "pirouette" in your mind.
Java programming is quite unlike any C/C++ programming. Sure, you can write
Java programs the way you'd do it in C, but that's never going to get you
far, performance-wise. A Java Virtual Machine is such an advanced beast
that you really need to get to know it better before you can talk about its
"general slowness", and write it off for its "memory and CPU intensiveness"
alone.
There are many design-pattern-level books that make it possible for one to
realize where the true power of both the Java VM and Java as a programming
language is though, and develop fast, scalable and reliable applications in
Java as well. One amongst those definitely worth mentioning would surely be
Doug Lea's "Concurrent programming in Java - Design principles and patterns",
and it coming from the insiders themselves, I can assure you that it really
is worth a look.
One has to decide one's interested and truely wants to find something useful
in a tool though, before one can see its true value.
Hope this helped.
--
Grega Bremec
System Administration & Development Support
grega.bremec-at-noviforum.si
http://najdi.si/
http://www.noviforum.si/
Вложения
I can't comment on exactly how eRserver benchmarks. But your comments on Java are sadly misplaced, maybe '95 esque. You'll find that allot of the misconceptions around java as a language stem from crtique with in roots from the frist widely accessible virtual machine 1.0.2. Many of the so called performance issues have long since been resolved which is quite miraculous for a language a little over 8 years old. You'll also be pleased to find that many different virtual machine perform very differently to the free sun hotspot virtual machine, some such as TowerJ allow for enhanced compile to platform capabitilities though of course you loose platform independence. But thats not an issue for everyone. I could list the urban myths perpetuated about Java's performance, but as this is not a Java developers list I think its out of place. As for using eRserver, we decided against it and for clients that require clustered highly available datagroups, we recommend oracle. I would not say it was its performance or reliability per se, but rather support, tools that lacked for someone who had different needs to our regular uses who are quite happy with Postgre. Renney Thomas wrote: > I would like to hear about any issues related to erserver. I was a > little concerned about its use of Java. Java is a great tool for > creating application frameworks for the payroll department, but using > it for back-end system-level application programming is a bit > unnerving. Java is generally slow, memory and CPU intensive and > doesn't provide for tight integration like C/C++ applications. > Thanks > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- James Cooper Software Engineer, Wificom Technologies Ltd Uudenmaankatu 23 A Tel. +358 9 5627 4600 00120 Helsinki, Finland Fax. +358 9 5627 4601
renneyt@yahoo.com (Renney Thomas) writes: > I would like to hear about any issues related to erserver. I was a > little concerned about its use of Java. Java is a great tool for > creating application frameworks for the payroll department, but using > it for back-end system-level application programming is a bit > unnerving. Java is generally slow, memory and CPU intensive and > doesn't provide for tight integration like C/C++ applications. There are things about Java that cause me concern, but I would dispute this being the total story. The thing about database-based applications is that they wind up hitting the _database_ pretty hard. And when the bulk of the work is database queries, where it's _PostgreSQL_ doing the work, it's not Java that is likely to be the bottleneck. Replication is certainly no exception to this. The bulk of replication work takes place in the database. In extreme cases, there _may_ be Java-based bottlenecks to be found, but that doesn't seem to be the typical case. In addition, I think you're looking at Java as how it was 4 years ago. Sun has relearned some of the things about garbage collection learned 15 years earlier in the Lisp community. They have built larger sets of compiled-to-machine-language libraries akin to LIBC, so that increasing portions of "system calls" are run as plenty fast compiled code. And JIT means that raw Java isn't as slow as it used to be. -- let name="cbbrowne" and tld="libertyrms.info" in String.concat "@" [name;tld];; <http://dev6.int.libertyrms.com/> Christopher Browne (416) 646 3304 x124 (land)
On Dec 1, 2003, at 2:34 PM, Christopher Browne wrote: > renneyt@yahoo.com (Renney Thomas) writes: >> I would like to hear about any issues related to erserver. I was a >> little concerned about its use of Java. Java is a great tool for >> creating application frameworks for the payroll department, but using >> it for back-end system-level application programming is a bit >> unnerving. Java is generally slow, memory and CPU intensive and >> doesn't provide for tight integration like C/C++ applications. > > There are things about Java that cause me concern, but I would dispute > this being the total story. > > The thing about database-based applications is that they wind up > hitting the _database_ pretty hard. And when the bulk of the work is > database queries, where it's _PostgreSQL_ doing the work, it's not > Java that is likely to be the bottleneck. > > Replication is certainly no exception to this. The bulk of > replication work takes place in the database. In extreme cases, there > _may_ be Java-based bottlenecks to be found, but that doesn't seem to > be the typical case. > There are some design problems in the erserver code that do cause some bottlenecks - see Andrew Sullivan's description of show-stoppers from a month or two ago. This is more of a design issue than a java-centric issue, however. > In addition, I think you're looking at Java as how it was 4 years ago. > Sun has relearned some of the things about garbage collection learned > 15 years earlier in the Lisp community. They have built larger sets > of compiled-to-machine-language libraries akin to LIBC, so that > increasing portions of "system calls" are run as plenty fast compiled > code. And JIT means that raw Java isn't as slow as it used to be. By no means. I find it amusing the number of people who, because java didn't live up to their interpretation of the original hype (nothing could, really), don't realize how popular and entrenched it is in certain areas. No, there aren't web-enabled word processors and whatnot everywhere like Sun tried to make everyone believe, but its huge in the server/DB/web delivery world. There are tradeoffs, of course. But such is the story of life. As for java being a "great tool for creating application frameworks for the payroll department", well, my version of an "application framework for a payroll department" manages about $90 billion in assets, so it must be a little bit up to the task :). > -- > let name="cbbrowne" and tld="libertyrms.info" in String.concat "@" > [name;tld];; > <http://dev6.int.libertyrms.com/> > Christopher Browne > (416) 646 3304 x124 (land) > > ---------------------------(end of > broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > -------------------- Andrew Rawnsley President The Ravensfield Digital Resource Group, Ltd. (740) 587-0114 www.ravensfield.com