LFS support check failed for standard file support - xymon 3.0
uname -a
SunOS solaris 5.10 Generic_142910-17 i86pc i386 i86pc
MAKE=gmake ./configure.client
[..]
Checking for clock_gettime() requiring librt ... clock_gettime() requires librt
Is this means librt is missing?
Checking for Large File Support ... ERROR: LFS support check failed for standard file support
I am pretty sure solaris 10 x86 supports large file system.
-- 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?
Den 14-03-2011 02:11, Asif Iqbal skrev:
uname -a
SunOS solaris 5.10 Generic_142910-17 i86pc i386 i86pc
MAKE=gmake ./configure.client
[..]
Checking for clock_gettime() requiring librt ... clock_gettime() requires librt
Is this means librt is missing?
No, it means we need to compile with "lrt" to get the CLOCK_MONOTONIC definitions.
Checking for Large File Support ... ERROR: LFS support check failed for standard file support
I am pretty sure solaris 10 x86 supports large file system.
Could you try running this command for me:
MAKE="gmake" sh -x ./build/lfs.sh
and post the output ?
Regards, Henrik
On Mon, Mar 14, 2011 at 2:55 AM, Henrik Størner <henrik at hswn.dk> wrote:
Den 14-03-2011 02:11, Asif Iqbal skrev:
uname -a
SunOS solaris 5.10 Generic_142910-17 i86pc i386 i86pc
MAKE=gmake ./configure.client
[..]
Checking for clock_gettime() requiring librt ... clock_gettime() requires librt
Is this means librt is missing?
No, it means we need to compile with "lrt" to get the CLOCK_MONOTONIC definitions.
I already added LIBRTDEF="-lrt" to the build/Makefile.rules so why would it still give that message?
It seems to me that I need to recompile with librt, which I am already doing
Checking for Large File Support ... ERROR: LFS support check failed for standard file support
I am pretty sure solaris 10 x86 supports large file system.
Could you try running this command for me:
MAKE="gmake" sh -x ./build/lfs.sh
and post the output ?
Make="gmake" sh -x ./build/lfs.sh
- echo Checking for Large File Support ... Checking for Large File Support ...
- cd build
- -f Makefile.test-lfs clean ./build/lfs.sh: -f: not found
- -f Makefile.test-lfs ./build/lfs.sh: -f: not found
- [ 1 -ne 0 ]
- echo ERROR: Compiler doesnt recognize the off_t C type. ERROR: Compiler doesnt recognize the off_t C type.
- exit 1
I am using this gmake
gmake -v
GNU Make 3.82 Built for x86_64-pc-solaris2.10 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
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?
Look like you have an old complier.
Paul Root Lead Internet Systems Eng Qwest Network Services
-----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Asif Iqbal Sent: Monday, March 14, 2011 9:21 AM To: Henrik Størner Cc: xymon at xymon.com Subject: Re: [Xymon] LFS support check failed for standard file support - xymon 3.0
On Mon, Mar 14, 2011 at 2:55 AM, Henrik Størner <henrik at hswn.dk> wrote:
Den 14-03-2011 02:11, Asif Iqbal skrev:
uname -a
SunOS solaris 5.10 Generic_142910-17 i86pc i386 i86pc
MAKE=gmake ./configure.client
[..]
Checking for clock_gettime() requiring librt ... clock_gettime() requires librt
Is this means librt is missing?
No, it means we need to compile with "lrt" to get the CLOCK_MONOTONIC definitions.
I already added LIBRTDEF="-lrt" to the build/Makefile.rules so why would it still give that message?
It seems to me that I need to recompile with librt, which I am already doing
Checking for Large File Support ... ERROR: LFS support check failed for standard file support
I am pretty sure solaris 10 x86 supports large file system.
Could you try running this command for me:
MAKE="gmake" sh -x ./build/lfs.sh
and post the output ?
Make="gmake" sh -x ./build/lfs.sh
- echo Checking for Large File Support ... Checking for Large File Support ...
- cd build
- -f Makefile.test-lfs clean ./build/lfs.sh: -f: not found
- -f Makefile.test-lfs ./build/lfs.sh: -f: not found
- [ 1 -ne 0 ]
- echo ERROR: Compiler doesnt recognize the off_t C type. ERROR: Compiler doesnt recognize the off_t C type.
- exit 1
I am using this gmake
gmake -v
GNU Make 3.82 Built for x86_64-pc-solaris2.10 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
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?
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
On Mon, Mar 14, 2011 at 10:32 AM, Root, Paul <Paul.Root at qwest.com> wrote:
Look like you have an old complier.
I am using gcc version 4.5.1
Paul Root Lead Internet Systems Eng Qwest Network Services
-----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Asif Iqbal Sent: Monday, March 14, 2011 9:21 AM To: Henrik Størner Cc: xymon at xymon.com Subject: Re: [Xymon] LFS support check failed for standard file support - xymon 3.0
On Mon, Mar 14, 2011 at 2:55 AM, Henrik Størner <henrik at hswn.dk> wrote:
Den 14-03-2011 02:11, Asif Iqbal skrev:
uname -a
SunOS solaris 5.10 Generic_142910-17 i86pc i386 i86pc
MAKE=gmake ./configure.client
[..]
Checking for clock_gettime() requiring librt ... clock_gettime() requires librt
Is this means librt is missing?
No, it means we need to compile with "lrt" to get the CLOCK_MONOTONIC definitions.
I already added LIBRTDEF="-lrt" to the build/Makefile.rules so why would it still give that message?
It seems to me that I need to recompile with librt, which I am already doing
Checking for Large File Support ... ERROR: LFS support check failed for standard file support
I am pretty sure solaris 10 x86 supports large file system.
Could you try running this command for me:
MAKE="gmake" sh -x ./build/lfs.sh
and post the output ?
Make="gmake" sh -x ./build/lfs.sh
- echo Checking for Large File Support ... Checking for Large File Support ...
- cd build
- -f Makefile.test-lfs clean ./build/lfs.sh: -f: not found
- -f Makefile.test-lfs ./build/lfs.sh: -f: not found
- [ 1 -ne 0 ]
- echo ERROR: Compiler doesnt recognize the off_t C type. ERROR: Compiler doesnt recognize the off_t C type.
- exit 1
I am using this gmake
gmake -v
GNU Make 3.82 Built for x86_64-pc-solaris2.10 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
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?
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
-- 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?
Den 14-03-2011 15:21, Asif Iqbal skrev:
On Mon, Mar 14, 2011 at 2:55 AM, Henrik Størner<henrik at hswn.dk> wrote:
Den 14-03-2011 02:11, Asif Iqbal skrev:
uname -a
SunOS solaris 5.10 Generic_142910-17 i86pc i386 i86pc
MAKE=gmake ./configure.client
[..]
Checking for clock_gettime() requiring librt ... clock_gettime() requires librt
Is this means librt is missing?
No, it means we need to compile with "lrt" to get the CLOCK_MONOTONIC definitions.
I already added LIBRTDEF="-lrt" to the build/Makefile.rules so why would it still give that message?
It seems to me that I need to recompile with librt, which I am already doing
It's a diagnostic, just telling you that we need librt when building binaries. It is NOT an error message.
Could you try running this command for me:
MAKE="gmake" sh -x ./build/lfs.sh
and post the output ?
Make="gmake" sh -x ./build/lfs.sh
Fail! Must be MAKE="gmake" in capital letters.
Regards, Henrik
On Mon, Mar 14, 2011 at 11:16 AM, Henrik Størner <henrik at hswn.dk> wrote:
Den 14-03-2011 15:21, Asif Iqbal skrev:
On Mon, Mar 14, 2011 at 2:55 AM, Henrik Størner<henrik at hswn.dk> wrote:
Den 14-03-2011 02:11, Asif Iqbal skrev:
uname -a
SunOS solaris 5.10 Generic_142910-17 i86pc i386 i86pc
MAKE=gmake ./configure.client
[..]
Checking for clock_gettime() requiring librt ... clock_gettime() requires librt
Is this means librt is missing?
No, it means we need to compile with "lrt" to get the CLOCK_MONOTONIC definitions.
I already added LIBRTDEF="-lrt" to the build/Makefile.rules so why would it still give that message?
It seems to me that I need to recompile with librt, which I am already doing
It's a diagnostic, just telling you that we need librt when building binaries. It is NOT an error message.
Could you try running this command for me:
MAKE="gmake" sh -x ./build/lfs.sh
and post the output ?
Make="gmake" sh -x ./build/lfs.sh
Fail! Must be MAKE="gmake" in capital letters.
oops!
MAKE="gmake" sh -x ./build/lfs.sh
- echo Checking for Large File Support ... Checking for Large File Support ...
- cd build
- gmake -f Makefile.test-lfs clean
- uname -s
- tr [/] [_] OS=SunOS gmake: *** [clean] Error 2
- gmake -f Makefile.test-lfs gmake: Nothing to be done for `all'.
- [ 0 -ne 0 ]
- ./test-lfs-std 4 STDRES=4:1:-78191077919555584
- test 4:1:-78191077919555584 != 4:1:0 -a 4:1:-78191077919555584 != 8:1:0
- echo ERROR: LFS support check failed for standard file support ERROR: LFS support check failed for standard file support
- exit 1
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?
Hi all; 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.
PD: Sorry the double posting.!
-----Mensaje original----- De: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] En nombre de Asif Iqbal Enviado el: Lunes, 14 de Marzo de 2011 09:30 Para: Henrik Størner CC: xymon at xymon.com Asunto: Re: [Xymon] LFS support check failed for standard file support - xymon 3.0
On Mon, Mar 14, 2011 at 11:16 AM, Henrik Størner <henrik at hswn.dk> wrote:
Den 14-03-2011 15:21, Asif Iqbal skrev:
On Mon, Mar 14, 2011 at 2:55 AM, Henrik Størner<henrik at hswn.dk> wrote:
Den 14-03-2011 02:11, Asif Iqbal skrev:
uname -a
SunOS solaris 5.10 Generic_142910-17 i86pc i386 i86pc
MAKE=gmake ./configure.client
[..]
Checking for clock_gettime() requiring librt ... clock_gettime() requires librt
Is this means librt is missing?
No, it means we need to compile with "lrt" to get the CLOCK_MONOTONIC definitions.
I already added LIBRTDEF="-lrt" to the build/Makefile.rules so why would it still give that message?
It seems to me that I need to recompile with librt, which I am already doing
It's a diagnostic, just telling you that we need librt when building binaries. It is NOT an error message.
Could you try running this command for me:
MAKE="gmake" sh -x ./build/lfs.sh
and post the output ?
Make="gmake" sh -x ./build/lfs.sh
Fail! Must be MAKE="gmake" in capital letters.
oops!
MAKE="gmake" sh -x ./build/lfs.sh
- echo Checking for Large File Support ... Checking for Large File Support ...
- cd build
- gmake -f Makefile.test-lfs clean
- uname -s
- tr [/] [_] OS=SunOS gmake: *** [clean] Error 2
- gmake -f Makefile.test-lfs gmake: Nothing to be done for `all'.
- [ 0 -ne 0 ]
- ./test-lfs-std 4 STDRES=4:1:-78191077919555584
- test 4:1:-78191077919555584 != 4:1:0 -a 4:1:-78191077919555584 != 8:1:0
- echo ERROR: LFS support check failed for standard file support ERROR: LFS support check failed for standard file support
- exit 1
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?
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Este mensaje de correo electrónico, incluidos los archivos adjuntos, es para el uso exclusivo de la persona a la que se ha enviado, y puede contener información que sea confidencial o protegida legalmente. Si usted no es el destinatario, o ha recibido este mensaje por error, no está autorizado a copiar, distribuir, o utilizar de alguna manera este mensaje. Por favor notifique inmediatamente al remitente por correo electrónico y suprimir permanentemente este mensaje y los archivos adjuntos. No se otorga ninguna garantía de que este e-mail esté libre de errores o virus. INSTITUTO COSTARRICENSE DE ELECTRICIDAD
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.
Regards, Henrik
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?
participants (4)
-
henrik＠hswn.dk
-
Paul.Root＠qwest.com
-
soopal＠ice.go.cr
-
vadud3＠gmail.com