From: Daniel Gomez <da.gomez@samsung.com>

program_invocation_short_name() may not be available in other systems.
Instead, replace it with the argv[0] to pass the executable name.

Fixes build error when program_invocation_short_name is not available:

drivers/gpu/drm/xe/xe_gen_wa_oob.c:34:3: error: use of
undeclared identifier 'program_invocation_short_name'    34 |
program_invocation_short_name);       |                 ^ 1 error
generated.

Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
This last patch allows for building the Linux kernel allyesconfig target
for arm64 in macOS hosts with Clang/LLVM.

Summary of previous feedback and work:

Other Makefile targets, such as defconfig, can already be built
successfully if the necessary headers are provided and the Linux kernel
build system is configured appropriately. To facilitate this process,
the Bee Headers [1] project was created not only to serve as reference
but also to document [2] the process and supply the missing headers.

To get started:

1. Setup:
	diskutil apfs addVolume /dev/disk<N> "Case-sensitive APFS" linux

	brew install coreutils findutils gnu-sed gnu-tar grep llvm make \
	pkg-config
	brew tap bee-headers/bee-headers
	brew install bee-headers/bee-headers/bee-headers

2. Build:
	source bee-init
	
	make LLVM=1 defconfig
	make LLVM=1 -j$(nproc)

[1] Project: https://github.com/bee-headers
[2] Documentation:
https://github.com/bee-headers/homebrew-bee-headers/blob/main/README.md

The changelog below has been refined to focus only on feedback related
to the xe driver. Version 3 was submitted some time ago, and although
some errors occurred in CI, they appear to be unrelated to the changes.
---
Changes in v3 (RESEND):
- Update cover letter and To/Cc list.
- Rebase patch onto next-20250221.
- Link to v3: https://lore.kernel.org/all/20240925-macos-build-support-v3-1-233dda880e60@samsung.com/
Changes in v3:
- Update drm/xe patch to replace program_invocation_short_name with
argv[0] instead of using getprogname + ifdef as suggested by Masahiro.
- Link to v2: https://lore.kernel.org/r/20240906-macos-build-support-v2-0-06beff418848@samsung.com

Changes in v2:
- Adapt xe_gen_wa_oob to solve getprogname()/
program_invocation_short_name in runtime. as suggested by Lucas De
Marchi.
- Link to v1: https://lore.kernel.org/r/20240807-macos-build-support-v1-0-4cd1ded85694@samsung.com
---
 drivers/gpu/drm/xe/xe_gen_wa_oob.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_gen_wa_oob.c b/drivers/gpu/drm/xe/xe_gen_wa_oob.c
index 904cf47925aa1d5bc37983af83232d5e4697c49e..ed9183599e31cc9d76da3f22c9fb3884384a49bc 100644
--- a/drivers/gpu/drm/xe/xe_gen_wa_oob.c
+++ b/drivers/gpu/drm/xe/xe_gen_wa_oob.c
@@ -28,10 +28,10 @@
 	"\n" \
 	"#endif\n"
 
-static void print_usage(FILE *f)
+static void print_usage(FILE *f, const char *progname)
 {
 	fprintf(f, "usage: %s <input-rule-file> <generated-c-source-file> <generated-c-header-file>\n",
-		program_invocation_short_name);
+		progname);
 }
 
 static void print_parse_error(const char *err_msg, const char *line,
@@ -144,7 +144,7 @@ int main(int argc, const char *argv[])
 
 	if (argc < 3) {
 		fprintf(stderr, "ERROR: wrong arguments\n");
-		print_usage(stderr);
+		print_usage(stderr, argv[0]);
 		return 1;
 	}
 

---
base-commit: d4b0fd87ff0d4338b259dc79b2b3c6f7e70e8afa
change-id: 20250224-macos-build-support-xe-f017c84113b6

Best regards,
-- 
Daniel Gomez <da.gomez@samsung.com>

On Mon, Feb 24, 2025 at 07:23:13AM +0100, da.gomez@kernel.org wrote:
>From: Daniel Gomez <da.gomez@samsung.com>
>
>program_invocation_short_name() may not be available in other systems.
>Instead, replace it with the argv[0] to pass the executable name.
>
>Fixes build error when program_invocation_short_name is not available:
>
>drivers/gpu/drm/xe/xe_gen_wa_oob.c:34:3: error: use of
>undeclared identifier 'program_invocation_short_name'    34 |
>program_invocation_short_name);       |                 ^ 1 error
>generated.
>
>Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
>Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
>---
>This last patch allows for building the Linux kernel allyesconfig target
>for arm64 in macOS hosts with Clang/LLVM.
>
>Summary of previous feedback and work:
>
>Other Makefile targets, such as defconfig, can already be built
>successfully if the necessary headers are provided and the Linux kernel
>build system is configured appropriately. To facilitate this process,
>the Bee Headers [1] project was created not only to serve as reference
>but also to document [2] the process and supply the missing headers.
>
>To get started:
>
>1. Setup:
>	diskutil apfs addVolume /dev/disk<N> "Case-sensitive APFS" linux
>
>	brew install coreutils findutils gnu-sed gnu-tar grep llvm make \
>	pkg-config
>	brew tap bee-headers/bee-headers
>	brew install bee-headers/bee-headers/bee-headers
>
>2. Build:
>	source bee-init
>	
>	make LLVM=1 defconfig
>	make LLVM=1 -j$(nproc)
>
>[1] Project: https://github.com/bee-headers
>[2] Documentation:
>https://github.com/bee-headers/homebrew-bee-headers/blob/main/README.md
>
>The changelog below has been refined to focus only on feedback related
>to the xe driver. Version 3 was submitted some time ago, and although
>some errors occurred in CI, they appear to be unrelated to the changes.

Is this the approach taken for other similar issues you had? Note that
argv[0] and program_invocation_short_name are not the same thing. For
this particular binary I don't really care and if it's the approach
taken in other places, I'm ok using it.

I was expecting you'd take the acks and merge it all through a single
tree since you received push back on the need to build the kernel in
macOS.  Is this the only thing missing and you'd want it to go through
drm?

Lucas De Marchi

Hi Lucas, chiming in here since I also care about building on macOS.

On Mon, Feb 24, 2025 at 10:05 AM Lucas De Marchi
<lucas.demarchi@intel.com> wrote:
>
> Is this the approach taken for other similar issues you had? Note that
> argv[0] and program_invocation_short_name are not the same thing. For
> this particular binary I don't really care and if it's the approach
> taken in other places, I'm ok using it.

Believe it or not, this is the only place that
program_invocation_short_name has ever been used in the kernel. There
have been numerous instances of:

#define _GNU_SOURCE /* for program_invocation_short_name */

but never any actual callers (that I could find in the git history)
other than this one.

> I was expecting you'd take the acks and merge it all through a single
> tree since you received push back on the need to build the kernel in
> macOS.  Is this the only thing missing and you'd want it to go through
> drm?

I believe the other patches have been applied or dropped. When I last
tested building allmodconfig this was the only issue I ran into (macOS
arm64), so I asked Daniel for this resend.

Cheers.
Tamir

On Thu, Feb 27, 2025 at 08:39:21AM -0500, Tamir Duberstein wrote:
>Hi Lucas, chiming in here since I also care about building on macOS.
>
>On Mon, Feb 24, 2025 at 10:05 AM Lucas De Marchi
><lucas.demarchi@intel.com> wrote:
>>
>> Is this the approach taken for other similar issues you had? Note that
>> argv[0] and program_invocation_short_name are not the same thing. For
>> this particular binary I don't really care and if it's the approach
>> taken in other places, I'm ok using it.
>
>Believe it or not, this is the only place that
>program_invocation_short_name has ever been used in the kernel. There
>have been numerous instances of:
>
>#define _GNU_SOURCE /* for program_invocation_short_name */
>
>but never any actual callers (that I could find in the git history)
>other than this one.
>
>> I was expecting you'd take the acks and merge it all through a single
>> tree since you received push back on the need to build the kernel in
>> macOS.  Is this the only thing missing and you'd want it to go through
>> drm?
>
>I believe the other patches have been applied or dropped. When I last
>tested building allmodconfig this was the only issue I ran into (macOS
>arm64), so I asked Daniel for this resend.

fair enough.  Pushed to drm-xe-next since nobody ever reads the
usage for this helper tool and it doesn't really matter if now it's ugly.

Lucas De Marchi

>
>Cheers.
>Tamir

On Thu, Feb 27, 2025 at 01:09:55PM +0100, Lucas De Marchi wrote:
> On Thu, Feb 27, 2025 at 08:39:21AM -0500, Tamir Duberstein wrote:
> > Hi Lucas, chiming in here since I also care about building on macOS.
> > 
> > On Mon, Feb 24, 2025 at 10:05 AM Lucas De Marchi
> > <lucas.demarchi@intel.com> wrote:
> > > 
> > > Is this the approach taken for other similar issues you had? Note that
> > > argv[0] and program_invocation_short_name are not the same thing. For
> > > this particular binary I don't really care and if it's the approach
> > > taken in other places, I'm ok using it.
> > 
> > Believe it or not, this is the only place that
> > program_invocation_short_name has ever been used in the kernel. There
> > have been numerous instances of:
> > 
> > #define _GNU_SOURCE /* for program_invocation_short_name */
> > 
> > but never any actual callers (that I could find in the git history)
> > other than this one.
> > 
> > > I was expecting you'd take the acks and merge it all through a single
> > > tree since you received push back on the need to build the kernel in
> > > macOS.  Is this the only thing missing and you'd want it to go through
> > > drm?

Yes, this is the only one missing.

> > 
> > I believe the other patches have been applied or dropped. When I last
> > tested building allmodconfig this was the only issue I ran into (macOS
> > arm64), so I asked Daniel for this resend.

That is correct.

In my opinion, the support for building the Linux kernel on macOS is primarily
supported by LLVM/Clang and the Linux kernel build system. The merged patches
were merely minor tweaks such this one (and refactors from Masahiro), intended
to enable users to configure the build system on these platforms. Patches
dropped led to the creation of the bee-headers project, which allows users
customize their build setup, which seems to be a common practice when people
requires to tweak the build environment.

> 
> fair enough.  Pushed to drm-xe-next since nobody ever reads the
> usage for this helper tool and it doesn't really matter if now it's ugly.

Thanks!

With this, we can now build arm64 in macOS defconfig, allyesconfig and
allmodconfig targets even with Rust support!

Daniel

> 
> Lucas De Marchi
> 
> > 
> > Cheers.
> > Tamir