[mono] Fix typo in detecting sys/auxv.h

[akoeplinger]

We were checking sts/auxv.h instead of sys/auxv.h so we were never defining HAVE_SYS_AUXV_H.

Instead of fixing the typo let's switch to checking for HAVE_GETAUXVAL which is what coreclr/libs.native are using.

[am11]

#if HAVE_GETAUXVAL since it is using cmakedefine01 instead of cmakedefine.

[akoeplinger]

ah thanks, I've changed it to cmakedefine since that is what we mostly use in mono.

[am11]

Then it will break src/native/minipal case. Please use cmakedefine01 since this is a shared code.

[akoeplinger]

Mono has its own config.h.in where we set this, there should be no effect to the minipal.

[akoeplinger]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

runtime/src/native/libs/System.Native/pal_io.c

Line 214 in fa1f283

#if defined(HAVE_STAT_FLAGS) && defined(UF_HIDDEN)

runtime/src/native/libs/Common/pal_config.h.in

Line 25 in fa1f283

#cmakedefine01 HAVE_STAT_FLAGS

[am11]

Since I added that cmakedefine01 c88c88a, naturally I know what mono is using. :)

Your change is wrong and will suffer from same thing what I have fixed yesterday #66874.

[am11]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

Yes, we should fix that too.

[akoeplinger]

I can't see why this wouldn't work, would you mind explaining why you think it'd break (on my phone right now so can't play with it)?

[am11]

minipal/getexepath is used by all: coreclr, mono, libs and corehost partitions. When HAVE_GETAUXVAL is detected on a system (which is a case with most modern linux systems), we wanted to use getauxval to get the exe path (and avoid the fallback, procfs, path since procfs is usually not reliable).

So there are three ways we can define a macro in cmake's config file (.in):

// 1. if detected, defines HAVE_GETAUXVAL, else skips the definition
#cmakedefine HAVE_GETAUXVAL
// 2. if detected, defines HAVE_GETAUXVAL as 1, else defines HAVE_GETAUXVAL as 0
#cmakedefine01 HAVE_GETAUXVAL
// 3. if detected defines HAVE_GETAUXVAL as 1, else skips the definition
#define HAVE_GETAUXVAL 1 // or #cmakedefine HAVE_GETAUXVAL 1

Since minipal (and almost everything under src/native) is shared code, we should use the same semantics everywhere. Otherwise, we get Wundef with 3. from minipal that is using #elif HAVE_GETAUXVAL.

[akoeplinger]

Ok so it's more a consistency thing rather than something that wouldn't work, got it. I'll change it.

[akoeplinger]

We were checking sts/auxv.h instead of sys/auxv.h so we were never defining HAVE_SYS_AUXV_H.

Instead of fixing the typo let's switch to checking for HAVE_GETAUXVAL which is what coreclr/libs.native are using.

[am11]

#if HAVE_GETAUXVAL since it is using cmakedefine01 instead of cmakedefine.

[akoeplinger]

ah thanks, I've changed it to cmakedefine since that is what we mostly use in mono.

[am11]

Then it will break src/native/minipal case. Please use cmakedefine01 since this is a shared code.

[akoeplinger]

Mono has its own config.h.in where we set this, there should be no effect to the minipal.

[akoeplinger]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

runtime/src/native/libs/System.Native/pal_io.c

Line 214 in fa1f283

#if defined(HAVE_STAT_FLAGS) && defined(UF_HIDDEN)

runtime/src/native/libs/Common/pal_config.h.in

Line 25 in fa1f283

#cmakedefine01 HAVE_STAT_FLAGS

[am11]

Since I added that cmakedefine01 c88c88a, naturally I know what mono is using. :)

Your change is wrong and will suffer from same thing what I have fixed yesterday #66874.

[am11]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

Yes, we should fix that too.

[akoeplinger]

I can't see why this wouldn't work, would you mind explaining why you think it'd break (on my phone right now so can't play with it)?

[am11]

minipal/getexepath is used by all: coreclr, mono, libs and corehost partitions. When HAVE_GETAUXVAL is detected on a system (which is a case with most modern linux systems), we wanted to use getauxval to get the exe path (and avoid the fallback, procfs, path since procfs is usually not reliable).

So there are three ways we can define a macro in cmake's config file (.in):

// 1. if detected, defines HAVE_GETAUXVAL, else skips the definition
#cmakedefine HAVE_GETAUXVAL
// 2. if detected, defines HAVE_GETAUXVAL as 1, else defines HAVE_GETAUXVAL as 0
#cmakedefine01 HAVE_GETAUXVAL
// 3. if detected defines HAVE_GETAUXVAL as 1, else skips the definition
#define HAVE_GETAUXVAL 1 // or #cmakedefine HAVE_GETAUXVAL 1

Since minipal (and almost everything under src/native) is shared code, we should use the same semantics everywhere. Otherwise, we get Wundef with 3. from minipal that is using #elif HAVE_GETAUXVAL.

[akoeplinger]

Ok so it's more a consistency thing rather than something that wouldn't work, got it. I'll change it.

[akoeplinger]

We were checking sts/auxv.h instead of sys/auxv.h so we were never defining HAVE_SYS_AUXV_H.

Instead of fixing the typo let's switch to checking for HAVE_GETAUXVAL which is what coreclr/libs.native are using.

[am11]

#if HAVE_GETAUXVAL since it is using cmakedefine01 instead of cmakedefine.

[akoeplinger]

ah thanks, I've changed it to cmakedefine since that is what we mostly use in mono.

[am11]

Then it will break src/native/minipal case. Please use cmakedefine01 since this is a shared code.

[akoeplinger]

Mono has its own config.h.in where we set this, there should be no effect to the minipal.

[akoeplinger]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

runtime/src/native/libs/System.Native/pal_io.c

Line 214 in fa1f283

#if defined(HAVE_STAT_FLAGS) && defined(UF_HIDDEN)

runtime/src/native/libs/Common/pal_config.h.in

Line 25 in fa1f283

#cmakedefine01 HAVE_STAT_FLAGS

[am11]

Since I added that cmakedefine01 c88c88a, naturally I know what mono is using. :)

Your change is wrong and will suffer from same thing what I have fixed yesterday #66874.

[am11]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

Yes, we should fix that too.

[akoeplinger]

I can't see why this wouldn't work, would you mind explaining why you think it'd break (on my phone right now so can't play with it)?

[am11]

minipal/getexepath is used by all: coreclr, mono, libs and corehost partitions. When HAVE_GETAUXVAL is detected on a system (which is a case with most modern linux systems), we wanted to use getauxval to get the exe path (and avoid the fallback, procfs, path since procfs is usually not reliable).

So there are three ways we can define a macro in cmake's config file (.in):

// 1. if detected, defines HAVE_GETAUXVAL, else skips the definition
#cmakedefine HAVE_GETAUXVAL
// 2. if detected, defines HAVE_GETAUXVAL as 1, else defines HAVE_GETAUXVAL as 0
#cmakedefine01 HAVE_GETAUXVAL
// 3. if detected defines HAVE_GETAUXVAL as 1, else skips the definition
#define HAVE_GETAUXVAL 1 // or #cmakedefine HAVE_GETAUXVAL 1

Since minipal (and almost everything under src/native) is shared code, we should use the same semantics everywhere. Otherwise, we get Wundef with 3. from minipal that is using #elif HAVE_GETAUXVAL.

[akoeplinger]

Ok so it's more a consistency thing rather than something that wouldn't work, got it. I'll change it.

[akoeplinger]

We were checking sts/auxv.h instead of sys/auxv.h so we were never defining HAVE_SYS_AUXV_H.

Instead of fixing the typo let's switch to checking for HAVE_GETAUXVAL which is what coreclr/libs.native are using.

[am11]

#if HAVE_GETAUXVAL since it is using cmakedefine01 instead of cmakedefine.

[akoeplinger]

ah thanks, I've changed it to cmakedefine since that is what we mostly use in mono.

[am11]

Then it will break src/native/minipal case. Please use cmakedefine01 since this is a shared code.

[akoeplinger]

Mono has its own config.h.in where we set this, there should be no effect to the minipal.

[akoeplinger]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

runtime/src/native/libs/System.Native/pal_io.c

Line 214 in fa1f283

#if defined(HAVE_STAT_FLAGS) && defined(UF_HIDDEN)

runtime/src/native/libs/Common/pal_config.h.in

Line 25 in fa1f283

#cmakedefine01 HAVE_STAT_FLAGS

[am11]

Since I added that cmakedefine01 c88c88a, naturally I know what mono is using. :)

Your change is wrong and will suffer from same thing what I have fixed yesterday #66874.

[am11]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

Yes, we should fix that too.

[akoeplinger]

I can't see why this wouldn't work, would you mind explaining why you think it'd break (on my phone right now so can't play with it)?

[am11]

minipal/getexepath is used by all: coreclr, mono, libs and corehost partitions. When HAVE_GETAUXVAL is detected on a system (which is a case with most modern linux systems), we wanted to use getauxval to get the exe path (and avoid the fallback, procfs, path since procfs is usually not reliable).

So there are three ways we can define a macro in cmake's config file (.in):

// 1. if detected, defines HAVE_GETAUXVAL, else skips the definition
#cmakedefine HAVE_GETAUXVAL
// 2. if detected, defines HAVE_GETAUXVAL as 1, else defines HAVE_GETAUXVAL as 0
#cmakedefine01 HAVE_GETAUXVAL
// 3. if detected defines HAVE_GETAUXVAL as 1, else skips the definition
#define HAVE_GETAUXVAL 1 // or #cmakedefine HAVE_GETAUXVAL 1

Since minipal (and almost everything under src/native) is shared code, we should use the same semantics everywhere. Otherwise, we get Wundef with 3. from minipal that is using #elif HAVE_GETAUXVAL.

[akoeplinger]

Ok so it's more a consistency thing rather than something that wouldn't work, got it. I'll change it.

[akoeplinger]

We were checking sts/auxv.h instead of sys/auxv.h so we were never defining HAVE_SYS_AUXV_H.

Instead of fixing the typo let's switch to checking for HAVE_GETAUXVAL which is what coreclr/libs.native are using.

[am11]

#if HAVE_GETAUXVAL since it is using cmakedefine01 instead of cmakedefine.

[akoeplinger]

ah thanks, I've changed it to cmakedefine since that is what we mostly use in mono.

[am11]

Then it will break src/native/minipal case. Please use cmakedefine01 since this is a shared code.

[akoeplinger]

Mono has its own config.h.in where we set this, there should be no effect to the minipal.

[akoeplinger]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

runtime/src/native/libs/System.Native/pal_io.c

Line 214 in fa1f283

#if defined(HAVE_STAT_FLAGS) && defined(UF_HIDDEN)

runtime/src/native/libs/Common/pal_config.h.in

Line 25 in fa1f283

#cmakedefine01 HAVE_STAT_FLAGS

[am11]

Since I added that cmakedefine01 c88c88a, naturally I know what mono is using. :)

Your change is wrong and will suffer from same thing what I have fixed yesterday #66874.

[am11]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

Yes, we should fix that too.

[akoeplinger]

I can't see why this wouldn't work, would you mind explaining why you think it'd break (on my phone right now so can't play with it)?

[am11]

minipal/getexepath is used by all: coreclr, mono, libs and corehost partitions. When HAVE_GETAUXVAL is detected on a system (which is a case with most modern linux systems), we wanted to use getauxval to get the exe path (and avoid the fallback, procfs, path since procfs is usually not reliable).

So there are three ways we can define a macro in cmake's config file (.in):

// 1. if detected, defines HAVE_GETAUXVAL, else skips the definition
#cmakedefine HAVE_GETAUXVAL
// 2. if detected, defines HAVE_GETAUXVAL as 1, else defines HAVE_GETAUXVAL as 0
#cmakedefine01 HAVE_GETAUXVAL
// 3. if detected defines HAVE_GETAUXVAL as 1, else skips the definition
#define HAVE_GETAUXVAL 1 // or #cmakedefine HAVE_GETAUXVAL 1

Since minipal (and almost everything under src/native) is shared code, we should use the same semantics everywhere. Otherwise, we get Wundef with 3. from minipal that is using #elif HAVE_GETAUXVAL.

[akoeplinger]

Ok so it's more a consistency thing rather than something that wouldn't work, got it. I'll change it.

[akoeplinger]

We were checking sts/auxv.h instead of sys/auxv.h so we were never defining HAVE_SYS_AUXV_H.

Instead of fixing the typo let's switch to checking for HAVE_GETAUXVAL which is what coreclr/libs.native are using.

[am11]

#if HAVE_GETAUXVAL since it is using cmakedefine01 instead of cmakedefine.

[akoeplinger]

ah thanks, I've changed it to cmakedefine since that is what we mostly use in mono.

[am11]

Then it will break src/native/minipal case. Please use cmakedefine01 since this is a shared code.

[akoeplinger]

Mono has its own config.h.in where we set this, there should be no effect to the minipal.

[akoeplinger]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

runtime/src/native/libs/System.Native/pal_io.c

Line 214 in fa1f283

#if defined(HAVE_STAT_FLAGS) && defined(UF_HIDDEN)

runtime/src/native/libs/Common/pal_config.h.in

Line 25 in fa1f283

#cmakedefine01 HAVE_STAT_FLAGS

[am11]

Since I added that cmakedefine01 c88c88a, naturally I know what mono is using. :)

Your change is wrong and will suffer from same thing what I have fixed yesterday #66874.

[am11]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

Yes, we should fix that too.

[akoeplinger]

I can't see why this wouldn't work, would you mind explaining why you think it'd break (on my phone right now so can't play with it)?

[am11]

minipal/getexepath is used by all: coreclr, mono, libs and corehost partitions. When HAVE_GETAUXVAL is detected on a system (which is a case with most modern linux systems), we wanted to use getauxval to get the exe path (and avoid the fallback, procfs, path since procfs is usually not reliable).

So there are three ways we can define a macro in cmake's config file (.in):

// 1. if detected, defines HAVE_GETAUXVAL, else skips the definition
#cmakedefine HAVE_GETAUXVAL
// 2. if detected, defines HAVE_GETAUXVAL as 1, else defines HAVE_GETAUXVAL as 0
#cmakedefine01 HAVE_GETAUXVAL
// 3. if detected defines HAVE_GETAUXVAL as 1, else skips the definition
#define HAVE_GETAUXVAL 1 // or #cmakedefine HAVE_GETAUXVAL 1

Since minipal (and almost everything under src/native) is shared code, we should use the same semantics everywhere. Otherwise, we get Wundef with 3. from minipal that is using #elif HAVE_GETAUXVAL.

[akoeplinger]

Ok so it's more a consistency thing rather than something that wouldn't work, got it. I'll change it.

[akoeplinger]

We were checking sts/auxv.h instead of sys/auxv.h so we were never defining HAVE_SYS_AUXV_H.

Instead of fixing the typo let's switch to checking for HAVE_GETAUXVAL which is what coreclr/libs.native are using.

[am11]

#if HAVE_GETAUXVAL since it is using cmakedefine01 instead of cmakedefine.

[akoeplinger]

ah thanks, I've changed it to cmakedefine since that is what we mostly use in mono.

[am11]

Then it will break src/native/minipal case. Please use cmakedefine01 since this is a shared code.

[akoeplinger]

Mono has its own config.h.in where we set this, there should be no effect to the minipal.

[akoeplinger]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

runtime/src/native/libs/System.Native/pal_io.c

Line 214 in fa1f283

#if defined(HAVE_STAT_FLAGS) && defined(UF_HIDDEN)

runtime/src/native/libs/Common/pal_config.h.in

Line 25 in fa1f283

#cmakedefine01 HAVE_STAT_FLAGS

[am11]

Since I added that cmakedefine01 c88c88a, naturally I know what mono is using. :)

Your change is wrong and will suffer from same thing what I have fixed yesterday #66874.

[am11]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

Yes, we should fix that too.

[akoeplinger]

I can't see why this wouldn't work, would you mind explaining why you think it'd break (on my phone right now so can't play with it)?

[am11]

minipal/getexepath is used by all: coreclr, mono, libs and corehost partitions. When HAVE_GETAUXVAL is detected on a system (which is a case with most modern linux systems), we wanted to use getauxval to get the exe path (and avoid the fallback, procfs, path since procfs is usually not reliable).

So there are three ways we can define a macro in cmake's config file (.in):

// 1. if detected, defines HAVE_GETAUXVAL, else skips the definition
#cmakedefine HAVE_GETAUXVAL
// 2. if detected, defines HAVE_GETAUXVAL as 1, else defines HAVE_GETAUXVAL as 0
#cmakedefine01 HAVE_GETAUXVAL
// 3. if detected defines HAVE_GETAUXVAL as 1, else skips the definition
#define HAVE_GETAUXVAL 1 // or #cmakedefine HAVE_GETAUXVAL 1

Since minipal (and almost everything under src/native) is shared code, we should use the same semantics everywhere. Otherwise, we get Wundef with 3. from minipal that is using #elif HAVE_GETAUXVAL.

[akoeplinger]

Ok so it's more a consistency thing rather than something that wouldn't work, got it. I'll change it.

[akoeplinger]

We were checking sts/auxv.h instead of sys/auxv.h so we were never defining HAVE_SYS_AUXV_H.

Instead of fixing the typo let's switch to checking for HAVE_GETAUXVAL which is what coreclr/libs.native are using.

[am11]

#if HAVE_GETAUXVAL since it is using cmakedefine01 instead of cmakedefine.

[akoeplinger]

ah thanks, I've changed it to cmakedefine since that is what we mostly use in mono.

[am11]

Then it will break src/native/minipal case. Please use cmakedefine01 since this is a shared code.

[akoeplinger]

Mono has its own config.h.in where we set this, there should be no effect to the minipal.

[akoeplinger]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

runtime/src/native/libs/System.Native/pal_io.c

Line 214 in fa1f283

#if defined(HAVE_STAT_FLAGS) && defined(UF_HIDDEN)

runtime/src/native/libs/Common/pal_config.h.in

Line 25 in fa1f283

#cmakedefine01 HAVE_STAT_FLAGS

[am11]

Since I added that cmakedefine01 c88c88a, naturally I know what mono is using. :)

Your change is wrong and will suffer from same thing what I have fixed yesterday #66874.

[am11]

btw. this looks wrong in the existing native/libs code since we use cmakedefine01 for it too:

Yes, we should fix that too.

[akoeplinger]

I can't see why this wouldn't work, would you mind explaining why you think it'd break (on my phone right now so can't play with it)?

[am11]

minipal/getexepath is used by all: coreclr, mono, libs and corehost partitions. When HAVE_GETAUXVAL is detected on a system (which is a case with most modern linux systems), we wanted to use getauxval to get the exe path (and avoid the fallback, procfs, path since procfs is usually not reliable).

So there are three ways we can define a macro in cmake's config file (.in):

// 1. if detected, defines HAVE_GETAUXVAL, else skips the definition
#cmakedefine HAVE_GETAUXVAL
// 2. if detected, defines HAVE_GETAUXVAL as 1, else defines HAVE_GETAUXVAL as 0
#cmakedefine01 HAVE_GETAUXVAL
// 3. if detected defines HAVE_GETAUXVAL as 1, else skips the definition
#define HAVE_GETAUXVAL 1 // or #cmakedefine HAVE_GETAUXVAL 1

Since minipal (and almost everything under src/native) is shared code, we should use the same semantics everywhere. Otherwise, we get Wundef with 3. from minipal that is using #elif HAVE_GETAUXVAL.

[akoeplinger]

Ok so it's more a consistency thing rather than something that wouldn't work, got it. I'll change it.