Re: Building wxPerl on Windows

Johan Vromans writes:

> On Thu,  9 Apr 2026 16:56:46 +0200 (CEST), Smylers wrote:
>=20
> > I got near to the end (mostly running the commands manually) on
> > Windows=C2=A011, but after wxPerl has been compiled, it won't load:
>=20
> This is often a case of mixing up shared libraries.

Thanks. Now fixed. The problem was that in running the steps manually I
had failed to add the gcc_dll directory to $env:path. I was just typing
in full paths to commands to run the correct ones, and hadn't realized
that Windows uses the path for DLLs as well as commands.

I now think I have everything installed properly.

Apologies for my error.

> > This computer is fairly locked down, so it's possible that a
> > privilege that Windows has by default been removed. For instance,
> > I've already had to request permission to create executable files in
> > specific directories and to be able to run PowerShell scripts.
>=20
> In general a bad idea... The computer is locked down for a reason.

It's OK: this is a dev copy of a standard workstation as issued to users
of our software. It started with the same software, config, and
permissions users have, but it is expected that as somebody upgrading
the system I'll need extra privileges.

> > =E2=80=A2 Compiling wxPerl emitted some warnings, including =E2=80=9Cc=
ommand-line=20
> option
> > '-std=3Dc99' is valid for C/ObjC but not for C++=E2=80=9D and some dep=
recations.
>=20
> Yes, this is a known warning.

Thanks for confirming.

The 7-Zip issue was that 7zr.exe can't actually extract from some
archive formats. Switching to 7za.exe made that work, which (in
combination with the previously mentioned path change) let the script
run to completion without error.

Pull requests for both changes submitted on GitHub (as you've probably
already seen).

Thank you again for creating this installer.

Smylers