On Mon, Mar 14, 2011 at 1:10 PM, Henrik Størner <user-ce4a2c883f75@xymon.invalid> wrote:
Hi,
I have comment this behavior before to Henrik. (Yes the problem arises for
sdt and large fs support).
The script expects some different numbers that the program output.
For example on Solaris 10 32bits the last number that program returns is
the maximum value for an int so is 32,767 and the negative sign; as I talked
to Henrik looks to me an endiannes issue about that calculation (I guess).
Since the value on Solaris Sparc (64bits) is really different.
---
Since I modify the lfs.sh script to let the installation continue I have
no invest time to really diagnose/correct the issue.
what worries me somewhat is that the behaviour on this platform (Solaris 10
x86) violates the specs for large file support that were published by Sun!
http://www.sun.com/software/whitepapers/wp-largefiles/largefiles.pdf
It quite clearly states in section 2.6.3 that
"In this environment, all xxx() source interfaces will map to xxx64() calls
in the resulting binary. This facility also ensures that POSIX data types
will be defined to be the correct size (i.e. off_t will be typedef’d to be a
long long 64-bit entity). A program compiled in this environment will be
able to use the xxx() source interfaces to access large files rather than
having to explicitly utilize the transitional xxx64() interface calls. In
this environment, a program can only use xxx() which manipulates both small
and large files.
Setting _FILE_OFFSET_BITS to 64 before including any system headers
enables 64-bit interfaces."
So when you compile a program with -D_FILE_OFFSET_BITS=64, it should provide
a 64-bit off_t variable, and the test program should work.
But it gives me a 32-bit off_t variable, and prints out rubbish when trying
to print the off_t value (something that is quite OK, and is in fact
described by the same document: The correct formatting string for a 64-bit
off_t if "%lld", which is what the test program uses when compiled in LFS
mode).
So I cannot conclude anything other than that the compilation environment
doesn't provide working support for large files.
I am guessing because this sol 10 x86 is running as a guest OS on
virtualbox 4.0.4 running on ubuntu maverick
I were able to compile xymon 4.3.0 on another solaris 10 x86, physical
host, with older gcc. (gcc version 3.4.3) just fine
Thanks for all your help
Regards,
Henrik
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?