Build failure with Lustre

[jsquyres]

HLRS's MTT runs are running into a build failure on master at dev-2223-g731cfe3 (see http://mtt.open-mpi.org/index.php?do_redir=2248):

fs_lustre_file_open.c: In function 'alloc_lum':
fs_lustre_file_open.c:48:5: error: 'LOV_MAX_STRIPE_COUNT' undeclared (first use in this function)
     LOV_MAX_STRIPE_COUNT * sizeof(struct lov_user_ost_data_v1);
     ^
fs_lustre_file_open.c:48:5: note: each undeclared identifier is reported only once for each function
it appears in

@ggouaillardet @hppritcha @cniethammer @roblatham00 Is this something we need to patch in OMPI's copy of ROMIO?

[edgargabriel]

No, this is in OMPIO, not in ROMIO. And it is weird, since I developed and tested the patch on the Stuttgart Cray.

[roblatham00]

The identifier in ROMIO is MAX_LOV_UUID_COUNT. It's not a lustre
identifier: the Lustre folks just defined that to 1000 in ad_lustre_open.c
itself. I don't know what happens in the distant future (of 2017?) when
lustre can finally write to more than 160 OSTs at once.

On Mon, Aug 10, 2015 at 1:43 PM, Jeff Squyres notifications@github.com
wrote:

HLRS's MTT runs are running into a build failure on master at
dev-2223-g731cfe3 (see http://mtt.open-mpi.org/index.php?do_redir=2248):

fs_lustre_file_open.c: In function 'alloc_lum':
fs_lustre_file_open.c:48:5: error: 'LOV_MAX_STRIPE_COUNT' undeclared (first use in this function)
LOV_MAX_STRIPE_COUNT * sizeof(struct lov_user_ost_data_v1);
^
fs_lustre_file_open.c:48:5: note: each undeclared identifier is reported only once for each function
it appears in

@ggouaillardet https://github.com/ggouaillardet @hppritcha
https://github.com/hppritcha @cniethammer
https://github.com/cniethammer @roblatham00
https://github.com/roblatham00 Is this something we need to patch in
OMPI's copy of ROMIO?

—
Reply to this email directly or view it on GitHub
#792.

[edgargabriel]

The only reason that I can see why the compilation fails is if the system used for MTT has a different Lustre version which does not define that string. @cniethammer could you check the Lustre version on that machine? Once again, it compiles without issues on hornet.

[roblatham00]

LOV_MAX_STRIPE_COUNT has been in lustre_user.h since July 2012 (commit
8a06a00535b92).

It was in lustre_idl.h before that, added in commit 01138321c7ce3 of
december 2011.

It might be time to either upgrade your lustre libraries or
configure-time check for that macro (160 would be a perfectly fine
default value, as before that macro was added that was the max)

==rob

On Mon, Aug 10, 2015 at 2:32 PM, Edgar Gabriel notifications@github.com
wrote:

The only reason that I can see why the compilation fails is if the system
used for MTT has a different Lustre version which does not define that
string. @cniethammer https://github.com/cniethammer could you check the
Lustre version on that machine? Once again, it compiles without issues on
hornet.

—
Reply to this email directly or view it on GitHub
#792 (comment).

[edgargabriel]

ok, thanks Rob for the info, will add something to catch that!

[edgargabriel]

well, adding probably something as simple as

#ifndef LOV_MAX_STRIPE_COUNT
#define LOV_MAX_STRIPE_COUNT 160
#endif

into the header file of that component would do, isn't it?

[edgargabriel]

fixed with commits 55f0e1a and 9f369ba