Обсуждение: gcj has a lot of complaints about 8.1-405 release
So I tried to build the current release using latest gcj, and it blew up real good: 27 hard errors and 60 warnings. My java-fu is not that strong, but a lot of these look like problems to me. Comments? regards, tom lane
Вложения
On Mon, 27 Mar 2006, Tom Lane wrote: > So I tried to build the current release using latest gcj, and it blew up > real good: 27 hard errors and 60 warnings. My java-fu is not that > strong, but a lot of these look like problems to me. Comments? > The source of the problem is that ant is being run in a 1.5 JVM, but the java compiler is defaulting to 1.4 source code and fails to recognize the 1.5 syntax. Currently ant must be run in the same JVM version as the compiler expects. A workaround for you would be to add source="1.5" to the javac tag in build.xml. Kris Jurka
Looks like the real errors is that it is trying to compile java 1.5 code and doesn't have the ability. What level of java does gjc support ? Dave On 27-Mar-06, at 4:58 PM, Tom Lane wrote: > <mime-attachment.gz>
Tom, Can you give me the output of ant -verbose on that platform ? Dave On 27-Mar-06, at 4:58 PM, Tom Lane wrote: > <mime-attachment.gz>
Dave Cramer <pg@fastcrypt.com> writes: > Can you give me the output of ant -verbose on that platform ? I sent Dave the full output off-list, but the critical part seems to be right at the start: Apache Ant version 1.6.5 compiled on March 6 2006 Buildfile: build.xml Detected Java version: 1.5 in: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre Detected OS: Linux If the java package version means what I think it means, then this is misdetecting the version. Is this our fault, or is something screwy in Red Hat's build environment? regards, tom lane
Tom, Yeah, you read it right.... one more thing please output of java -version Dave On 27-Mar-06, at 5:34 PM, Tom Lane wrote: > Dave Cramer <pg@fastcrypt.com> writes: >> Can you give me the output of ant -verbose on that platform ? > > I sent Dave the full output off-list, but the critical part seems > to be > right at the start: > > Apache Ant version 1.6.5 compiled on March 6 2006 > Buildfile: build.xml > Detected Java version: 1.5 in: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre > Detected OS: Linux > > If the java package version means what I think it means, then this is > misdetecting the version. Is this our fault, or is something screwy > in Red Hat's build environment? > > regards, tom lane > > ---------------------------(end of > broadcast)--------------------------- > TIP 6: explain analyze is your friend >
Dave Cramer <pg@fastcrypt.com> writes: > Yeah, you read it right.... one more thing please > output of java -version java version "1.4.2" gij (GNU libgcj) version 4.1.0 20060304 (Red Hat 4.1.0-3) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. regards, tom lane
On Mon, 27 Mar 2006, Tom Lane wrote: > Apache Ant version 1.6.5 compiled on March 6 2006 > Detected Java version: 1.5 in: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre > > If the java package version means what I think it means, then this is > misdetecting the version. Is this our fault, or is something screwy > in Red Hat's build environment? > Your version of ant determines it is a 1.5 JVM by being able to load the java.lang.Readable interface which shouldn't exist in a 1.4 JVM. Newer versions of ant (2 days old) check for java.net.Proxy instead. http://issues.apache.org/bugzilla/show_bug.cgi?id=39027 Kris Jurka
Hmmm.... wierd.... you'd think that should be enough information to figure out that it's version 1.4.2 Other than Kris's suggestion, I'm not sure how to help, unless I could get access to a similiarly configured box. I'm thinking the java config files must be setup to tell it that it's java 1.5 somewhere Dave On 27-Mar-06, at 6:18 PM, Tom Lane wrote: > Dave Cramer <pg@fastcrypt.com> writes: >> Yeah, you read it right.... one more thing please >> output of java -version > > java version "1.4.2" > gij (GNU libgcj) version 4.1.0 20060304 (Red Hat 4.1.0-3) > > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > > regards, tom lane > > ---------------------------(end of > broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match >
Kris Jurka <books@ejurka.com> writes: > http://issues.apache.org/bugzilla/show_bug.cgi?id=39027 Ah-hah. I'll twist some arms to get this into Red Hat's build system ASAP. Many thanks for the clue! regards, tom lane
BTW, one Red Hatter had this to say: > Yeah, AFAIAC this is a bug in ant. Really, the build file should be using > ${java.version} instead of ${ant.java.version} to avoid this problem, IMHO. > I ran into a similar issue with the Eclipse SDK. Comments? regards, tom lane
Certainly from Kris's post this is a bug in Ant which has been corrected in the latest versions. Dave On 27-Mar-06, at 10:09 PM, Tom Lane wrote: > BTW, one Red Hatter had this to say: > >> Yeah, AFAIAC this is a bug in ant. Really, the build file should >> be using >> ${java.version} instead of ${ant.java.version} to avoid this >> problem, IMHO. >> I ran into a similar issue with the Eclipse SDK. > > Comments? > > regards, tom lane >
On Mon, 27 Mar 2006, Tom Lane wrote: > BTW, one Red Hatter had this to say: > >> Yeah, AFAIAC this is a bug in ant. Really, the build file should be using >> ${java.version} instead of ${ant.java.version} to avoid this problem, IMHO. >> I ran into a similar issue with the Eclipse SDK. > The difference is that java.version will return things like 1.4.2_08 instead of just 1.4, so they are not equivalent. ant doesn't offer a lot of tools to parse such a string, the best you could do would be a global substring match. Trying to find 1.4 would match 1.1.4 as well as 1.4.2 though. Since we don't support 1.1 builds we could do this, but it seems a little fragile with perhaps other vendors using different format strings. The best solution for older ant users might be to duplicate the checks ant makes for ant.java.version in our own build file. That way we can put in the latest updates and not require an upgrade. Kris Jurka
On Tue, 28 Mar 2006, Kris Jurka wrote: > > > On Mon, 27 Mar 2006, Tom Lane wrote: > >> BTW, one Red Hatter had this to say: >> >>> Yeah, AFAIAC this is a bug in ant. Really, the build file should be using >>> ${java.version} instead of ${ant.java.version} to avoid this problem, >>> IMHO. >>> I ran into a similar issue with the Eclipse SDK. >> > > The difference is that java.version will return things like 1.4.2_08 instead > of just 1.4, so they are not equivalent. ant doesn't offer a lot of tools to > parse such a string, the best you could do would be a global substring match. > Trying to find 1.4 would match 1.1.4 as well as 1.4.2 though. Since we don't > support 1.1 builds we could do this, but it seems a little fragile with > perhaps other vendors using different format strings. The best solution for > older ant users might be to duplicate the checks ant makes for > ant.java.version in our own build file. That way we can put in the latest > updates and not require an upgrade. How about java.specification.version? AFAIK, it should do just what we need. - Heikki
On Thu, 30 Mar 2006, Heikki Linnakangas wrote: > How about java.specification.version? AFAIK, it should do just what we > need. > Indeed it does, I've put this into our build.xml along with an explicit failure message when someone tries a JDK1.6 compile. Kris Jurka
I am also really excited about GCJ/Classpath support, since this would allow users to use postgres from java applications without relying on proprietary software. Just because of interrest, has anybody successfully used the jdbc driver with gnu-classpath based JVMs? Thanks, lg Clemens 2006/4/29, Kris Jurka <books@ejurka.com>: > > > On Thu, 30 Mar 2006, Heikki Linnakangas wrote: > > > How about java.specification.version? AFAIK, it should do just what we > > need. > > > > Indeed it does, I've put this into our build.xml along with an explicit > failure message when someone tries a JDK1.6 compile. > > Kris Jurka > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org >