[LU-6073] lustre/tests/*.c should use sys/xattr.h rather than attr/xattr.h Created: 29/Dec/14  Updated: 16/Mar/16  Resolved: 20/Feb/15

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.7.0
Fix Version/s: Lustre 2.7.0, Lustre 2.8.0

Type: Bug Priority: Minor
Reporter: John Hammond Assignee: John Hammond
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Related
is related to LU-6027 Issues with EAs of orphan files and E... Resolved
Severity: 3
Rank (Obsolete): 16899

 Description   

In lustre/tests/

{multiop,orphan_linkea_check}

.c we should include sys/xattr.h (provided by glibc-headers) rather than attr/xattr.h (provided by libattr-devel) since the former is more likely to be installed and has all of the needed declarations.



 Comments   
Comment by James A Simmons [ 29/Dec/14 ]

Just ran into this issue.

Comment by Bob Glossman (Inactive) [ 29/Dec/14 ]

Just as a data point I had builds fail on several of my long time builder VMs due to this issue. I had not installed the libattr-devel rpms everywhere which contains the /usr/include/attr files. They were never needed before the mod using <attr/xattr.h> landed in master. While the problem went away as soon as I did install the additional rpm I agree that it would be preferable to use the more commonly available <sys/xattr.h> instead.

Comment by Gerrit Updater [ 29/Dec/14 ]

John L. Hammond (john.hammond@intel.com) uploaded a new patch: http://review.whamcloud.com/13197
Subject: LU-6073 tests: use sys/xattr.h in tests/*.c
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 2c3b572d3e2d2499189fdf17bb9c51d519193b28

Comment by Gerrit Updater [ 04/Jan/15 ]

Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/13197/
Subject: LU-6073 tests: use sys/xattr.h in tests/*.c
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 9c2e4c1075a66e8576d2fa9bed2c771a1c206fde

Comment by John Hammond [ 05/Jan/15 ]

Patch landed to master.

Comment by Jodi Levi (Inactive) [ 20/Feb/15 ]

Reopening to add fix version

Comment by Gerrit Updater [ 25/Jun/15 ]

John L. Hammond (john.hammond@intel.com) uploaded a new patch: http://review.whamcloud.com/15391
Subject: LU-6073 tests: use sys/xattr.h in tests/mpi/*.c
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: dd687d03f0ded47fc1e715d047a48898ea0a90c6

Comment by Gerrit Updater [ 25/Jun/15 ]

John L. Hammond (john.hammond@intel.com) uploaded a new patch: http://review.whamcloud.com/15392
Subject: LU-6073 build: add -Wall to CFLAGS for test/ and utils/
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: e6c9e5d829ede1a8a114da73f945cf3bdf10b7b1

Comment by Gerrit Updater [ 08/Jul/15 ]

Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/15391/
Subject: LU-6073 tests: use sys/xattr.h in tests/mpi/*.c
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 1178a9f7dc53b8ecfc5b76c494c8156bc039f4be

Comment by Chris Horn [ 10/Jul/15 ]

The patch at http://review.whamcloud.com/15392 resolves the issue reported in LU-6835, as well as another issue which I did not have time to create a ticket for. Repeating some information here so it can be found via search. Some implicit declarations were introduced by http://review.whamcloud.com/15217 (a801262) in libiam.c and lfs.c

[  280s] cc1: warnings being treated as errors
[  280s] lfs.c: In function 'migrate_copy_timestamps':
[  280s] lfs.c:481: error: implicit declaration of function 'futimes'

and

[  175s] cc1: warnings being treated as errors
[  175s] libiam.c: In function 'lfix_root':
[  175s] libiam.c:155: error: implicit declaration of function 'cpu_to_le64'
[  175s] libiam.c:156: error: implicit declaration of function 'cpu_to_le16'
[  175s] libiam.c:187: error: implicit declaration of function 'cpu_to_le32'
Comment by Chris Horn [ 10/Jul/15 ]

As an aside, it seems like bad practice to re-use a ticket like this, as well as piggy back the "#include" changes on http://review.whamcloud.com/15392

Generated at Sat Feb 10 01:56:58 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.