On Mon, Mar 14, 2011 at 1:10 PM, Henrik Størner <henrik at hswn.dk> 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
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-- 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?