On Tue, Jun 28, 2016 at 10:41:24AM +0100, Ferruh Yigit wrote:

On 6/26/2016 2:49 PM, Jianfeng Tan wrote:

quoted

On some older systems, such as SUSE 11, the compiling error shows
as:
   .../dpdk/drivers/net/virtio/virtio_user/virtio_user_dev.c:67:22:
         error: ‘O_CLOEXEC’ undeclared (first use in this function)

The fix is to declare _GNU_SOURCE macro before include fcntl.h.

Fixes: 37a7eb2ae816 ("net/virtio-user: add device emulation layer")

Signed-off-by: Jianfeng Tan <redacted>
---
 drivers/net/virtio/virtio_user/virtio_user_dev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index 3d12a32..180f824 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c

@@ -31,6 +31,7 @@
  *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+#define _GNU_SOURCE

This flag enables glibc extensions, and kind of problem on code
portability. How big problem is it?

Honestly, I don't know. But I was also thinking that define _GNU_SOURCE
here is an overkill to me. For this issue, we may simply fix it by
reference the O_CLOEXEC flag only when it's defined.

Is there any platform that DPDK runs on which uses a libc that isn't
compatible with what this flag provides?

And it seems this flag already used in DPDK, including libraries.

Yes, "git grep _GNU_SOURCE" shows a lot of such usage.

	--yliu

If we
are agree on using glibc extensions, does it make sense to move this
flag into a single common location (like mk/exec-env/) ?

quoted

 #include <stdint.h>
 #include <stdio.h>
 #include <fcntl.h>