gprofng UCRT64

[Nick Alcock]

On 26 Oct 2025, Tom Kacvinsky outgrape:

> On Sun, Oct 26, 2025 at 4:05 AM Barrett Kauling <kaulingbe@outlook.com>
> wrote:
>
>> I got both binutils-gdb and MSYS2-package/binutils to build and both came
>> up empty.
>> $ tar -tvf *.zst | grep gprofng
>>
>> I need help with autotools and getting the gprofng makefile to build, I
>> ran `autoreconf -fi` which I understand runs `aclocal`, `autoconf`, and
>> `automake`. I don't know if I need to find the problem within running
>> autotools or the specific way the directory was configured using aclocal.
>>
>> Modifying the PKGBUILD was unsuccessful in MSYS2.
>>
>>
> I cloned the binutils-gdb repo and checked out the binutils-2_43_1 tag.
> I looked over the top level configure script and I see this
>
> if test "$enable_gprofng" = "yes"; then
>
>   case "${target}" in
>
>     x86_64-*-linux* | i?86-*-linux* | aarch64-*-linux* | riscv64-*-linux*)
>
>     configdirs="$configdirs gprofng"
>
>     ;;
>
>   esac
>
> fi
>
> So gprofng is geared towards building Linux, but only for 32-bit and 64-bit
> Intel/AMD,  aarch64, and risvc64 processors
>
> If I change this code to
>
> if test "$enable_gprofng" = "yes"; then
>
>     configdirs="$configdirs gprofng"
>
> fi
>
> and run autoreconf -fi, then configure --enable-gprofng=yes, gprofng
> is still not built.
>
> I suppose you might be sorry, out of luck - I think this is where the
> maintainers of gprofng are going to chime in. I am guessing they're
> going to say that it isn't supported on Windows because the
> performance counters they use are Linux specific.

I'm not a maintainer, but do know a little about it, and in particular I
think I added that configure test :) but no, making gprofng work on
mingw (or cygwin) would likely require major surgery. It's completely
geared to an LD_PRELOAD+ptrace approach right now, and none of that is
the Windows way of getting performance info at all. The "collector" that
gathers the data is a separate program, so a Windows one could be
written without overly disturbing the Linux side of things, but right
now it's a Linux tool, no more, no less.

Making it run on *other Unixes* is probably not too terribly difficult
(the hardest part being how horribly different ptrace() is on different
platforms). But Windows is definitely not a Unix in this area.

Sorry :(