Hello,
while analyzing warnings on HP-UX 10.20 I found troubles with symbols
inside system headers (just warnings.. on stuff like __xxxx64()).
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
[email protected]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
