LFS support check failed for standard file support - xymon 3.0 🔗 link

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?

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.

On Mon, Mar 14, 2011 at 2:55 AM, Henrik Størner <user-ce4a2c883f75@xymon.invalid> 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.

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 ?

-- 
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?

On Mon, Mar 14, 2011 at 2:55 AM, Henrik Størner
<user-ce4a2c883f75@xymon.invalid> 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

--
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<user-ce4a2c883f75@xymon.invalid>  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

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

On Mon, Mar 14, 2011 at 11:16 AM, Henrik Størner <user-ce4a2c883f75@xymon.invalid> wrote:

Den 14-03-2011 15:21, Asif Iqbal skrev:

On Mon, Mar 14, 2011 at 2:55 AM, Henrik Størner<user-ce4a2c883f75@xymon.invalid>  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.

 MAKE="gmake" sh -x ./build/lfs.sh
+ echo Checking for Large File Support ...
Checking for Large File Support ...
+ cd build

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?

On Mon, Mar 14, 2011 at 10:32 AM, Root, Paul <user-c80045f511e8@xymon.invalid> wrote:

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
<user-ce4a2c883f75@xymon.invalid> 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

--
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?

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?

  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

On Mon, Mar 14, 2011 at 11:55 AM, Henrik Størner <user-ce4a2c883f75@xymon.invalid> wrote:

 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

This is bizarre.

What this does is that it builds a tiny test program using standard
compiler-flags first, and then the flags that you would normally use when
compiling for large file support (LFS).

When compiled without LFS, I expect the normal file offset "off_t" variable
to be 32 bits (4 bytes); with LFS, I would expect it to be 64-bits (8
bytes). To test that, the program prints out

1) The value of "sizeof(off_t)"
2) A boolean (0/1) value to see if sizeof(off_t) is what I expect
3) The value of an off_t variable that has been cleared to zero using
memset() - we need to print these values occasionally (e.g. for keeping
track of how long into a logfile we have already scanned).

1) and 2) look OK, but the value prints as "-7819...." There is no way I can
see how that can happen - that variable has been cleared to 0 just a few
lines above the print-statement.

Just to see if I'm completely wrong, could you try running this for me:

 cd build
 rm test-lfs-std test-lfs-lfs
 OS=SunOS gmake -f Makefile.test-lfs
 ./test-lfs-std 4
 ./test-lfs-lfs 8

The output from the last line would be interesting.

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?

On Mon, Mar 14, 2011 at 11:16 AM, Henrik Størner <user-ce4a2c883f75@xymon.invalid> wrote:

Den 14-03-2011 15:21, Asif Iqbal skrev:

On Mon, Mar 14, 2011 at 2:55 AM, Henrik Størner<user-ce4a2c883f75@xymon.invalid>  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

--
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?

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.

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.

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?