Re: [kaffe] config/i386/freebsd2/md.c
Ito Kazumitsu wrote: Hi, Today's make on FreeBSD 5.4-RELEASE faild while compiling config/i386/freebsd2/md.c. In file included from ../../config/i386/freebsd2/md.c:17, from md.c:1: /usr/include/sys/sysctl.h:637: error: syntax error before u_int gmake[2]: *** [libkaffevm_la-md.lo] Error 1 Thanks for the bug report,Ito, I've checked in a patch. Riccardo moved a few headers out of config-std.h to more easily be able to track down build failures on HP-UX, and that may cause some missing header implicit declaration inconveniences on other platforms. If you encounter implicit declaration warnings during your build, please add the necessary headers to the files needing them and check such a patch in. Riccardo and me have since added the relevant headers back into files that depend on them on various platforms, but there will probably be a few to go. cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] CVS kaffe (robilad): Added missing include for x86-freebsd
PatchSet 6867
Date: 2005/08/22 12:38:34
Author: robilad
Branch: HEAD
Tag: (none)
Log:
Added missing include for x86-freebsd
2005-08-22 Dalibor Topic [EMAIL PROTECTED]
* config/i386/freebsd2/md.c: Include sys/types.h
Reported by: Ito Kazumitsu [EMAIL PROTECTED]
Members:
ChangeLog:1.4388-1.4389
config/i386/freebsd2/md.c:INITIAL-1.5
Index: kaffe/ChangeLog
diff -u kaffe/ChangeLog:1.4388 kaffe/ChangeLog:1.4389
--- kaffe/ChangeLog:1.4388 Sun Aug 21 19:54:46 2005
+++ kaffe/ChangeLog Mon Aug 22 12:38:34 2005
@@ -1,3 +1,9 @@
+2005-08-22 Dalibor Topic [EMAIL PROTECTED]
+
+ * config/i386/freebsd2/md.c: Include sys/types.h
+
+ Reported by: Ito Kazumitsu [EMAIL PROTECTED]
+
2005-08-21 Dalibor Topic [EMAIL PROTECTED]
Resynced with GNU Classpath.
===
Checking out kaffe/config/i386/freebsd2/md.c
RCS: /home/cvs/kaffe/kaffe/config/i386/freebsd2/md.c,v
VERS: 1.5
***
--- /dev/null Sun Aug 4 19:57:58 2002
+++ kaffe/config/i386/freebsd2/md.c Mon Aug 22 12:43:50 2005
@@ -0,0 +1,40 @@
+/*
+ * i386/freebsd2/md.c
+ * FreeBSD i386 specific functions.
+ *
+ * Copyright(c) 2004 The Kaffe.org's developers.
+ *
+ * Some parts are imported from the boehm-gc.
+ *
+ * See the file license.terms for information on usage and redistribution
+ * of this file.
+ */
+
+#include config.h
+#include config-std.h
+
+#if defined(HAVE_SYS_TYPES_H)
+#include sys/types.h
+#endif
+
+#if defined(HAVE_SYS_SYSCTL_H)
+#include sys/sysctl.h
+
+void *mdGetStackEnd(void)
+{
+int control_name[2] =
+ { CTL_KERN, KERN_USRSTACK};
+void *stackbase;
+size_t len = sizeof(void *);
+
+if (sysctl(control_name, 2, stackbase, len, NULL, 0))
+ {
+ fprintf(stderr,
+ Kaffe VM has not been able to retrieve the pointer to the
stack base\n
+ Aborting...\n);
+ exit(1);
+ }
+ return stackbase;
+}
+
+#endif
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] concerns about large files and HP-UX in kaffe
Hello,
while analyzing warnings on HP-UX 10.20 I found troubles with symbols
inside system headers (just warnings.. on stuff like __64()).
Further analysis shows that this happens when _FILE_OFFSET_BITS is set
to 64 (without ay further options flags or system includes).
now together with _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE they are
posix flags to regulate the usage of the functions, either by defining
that the old function name xx() works as 64bit or by defining a xx64()
version.
read here:
http://www.pimpworks.org/hp/relnotes/lg_files.txt
now I don't understand why on my hp-ux 10.20 box I get these warnings.
(it might be interesting to check other hp-ux 10.20 boxes...).
interesting is that my os should support large files (read
http://hpwww.epfl.ch/HPUX/10.20RelNotes for further notes, esp. the
section
Large Files
@
For 10.20, HP-UX now supports files up to 128GB in size. The prior
limit was
2GB.)
but the first document says
6.1.4 Determining if large-files are supported
For developers that want to write code that is portable between
systems that support large files and sys- tems that do not support
large files, two announcement macros are available. These announcement
mac- ros are _LFS_LARGEFILE and _LFS64_LARGEFILE.
apparently on my computer, when using a test file and gcc 2.95,
_LFS_LARGEFILE is not 1. SO I am confused. Maybe this causes the many
warnings. Also these warnings could cause malfunction...
Maybe it is that 10.20 headers have torubles, but I doubt this, it is
something too evident... Even hello world causes warnings if 64bit is
on and a system header file is included.
any help welcome, especially by people with access to 10.20 systems
(and possibly verifying 11.x systems...)
in any case, I don't know what we are doing, but posix says
1. Make the program aware of large files without actually supporting
them. Look for the new open() and stat() errors and, if
encountered,
take appropriate actions. For example, if your application is a
browser that currently exits when stat fails, it can instead be
changed to display an appropriate message and then continue.
2. Use standard types and calls, but compile the program in the
environment that uses 64 bits for the relevant types. Note that
other source changes will most likely be necessary to correctly
support the larger data types.
3. Use the new *64() calls in the 32-bit compile environment. This
involves explicitly coding the *64() names into the source code.
This should only be done when a specific portion of the application
needs to be large file aware, while other parts do not. This
approach
is not recommended if the alternative described above can be used.
the current behavior is that the following kind of definition is
activated in the system headers
static xxx() { return __xxx64() }
which would mean that we use standard names and want then to be 64bit.
all __xxx64() definition in these files result undefined (interestingly
this is for C.. if it was c++ the symbols would have been defined as
extern)
so maybe it is really some header imprecision ? or did we find some
corner case ? I wonder... also the fact that the 64bit macro that
should return 1 returns 0 here...
Cheers,
Riccardo
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] xargs -i
Hi,
The following line Makefile.am causes error on FreeBSD.
echo
KAFFELIBRARYPATH=\$${KAFFELIBRARYPATH+\\$$KAFFELIBRARYPATH\\''$(PATHSEP)'\'}`for
f in $(JAVA_LIBS); do echo $$f | sed 's%/[^/]*$$%%' | xargs -n 1 -iXXX echo
XXX/.libs; done | (tr '\012' ' '; echo) | sed -e 's/ $$//' -e s/
/\'$(PATHSEP)\'/g`\; export KAFFELIBRARYPATH BUILD_ENVIRONMENT.new; \
xargs -i is specific to GNU version of xargs, and FreeBSD's xargs
does not accept that option. I had to install GNU's findutils-4.2.23
to make all the tests pass.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] xargs -i
Ito Kazumitsu wrote:
Hi,
The following line Makefile.am causes error on FreeBSD.
echo
KAFFELIBRARYPATH=\$${KAFFELIBRARYPATH+\\$$KAFFELIBRARYPATH\\''$(PATHSEP)'\'}`for
f in $(JAVA_LIBS); do echo $$f | sed 's%/[^/]*$$%%' | xargs -n 1 -iXXX
echo XXX/.libs; done | (tr '\012' ' '; echo) | sed -e 's/ $$//' -e s/
/\'$(PATHSEP)\'/g`\; export KAFFELIBRARYPATH BUILD_ENVIRONMENT.new; \
xargs -i is specific to GNU version of xargs, and FreeBSD's xargs
does not accept that option. I had to install GNU's findutils-4.2.23
to make all the tests pass.
I am sorry about that, I already received a patch to fix that using the
apparently more standard -I option.
I've thought about avoiding such bugs in the future, and I think instead
of using a scriptlet, maybe manually listing all the native libraries
necessary to run the test suite in the KAFFELIBRARYPATH variable is a
better choice. I'll try that and check it in if it works for me.
cheers,
dalibor topic
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
