Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GIMP 3.0 RC's fail to run python plugins #380

Open
Wormnest opened this issue Jan 19, 2025 · 4 comments
Open

GIMP 3.0 RC's fail to run python plugins #380

Wormnest opened this issue Jan 19, 2025 · 4 comments
Labels
bug Something isn't working planned The issue is planned to be addressed

Comments

@Wormnest
Copy link

A GIMP issue was raised here for the 3.0 release candidates (RC1 and RC2), where a few users have problems running GIMP's Python plug-ins.

The last reporter in the above link found that disabling windhawk allows to run GIMP's Python plug-ins.

Note that I am not a windhawk user, just a GIMP developer, so can't do any testing or give further information than what is available in the above link.

@Wormnest Wormnest added the bug Something isn't working label Jan 19, 2025
@m417z
Copy link
Member

m417z commented Jan 19, 2025

I think I know what the issue is, and it's going to be fixed in the next Windhawk update.

Does the C:\Program Files\GIMP 3\bin\libgraphite2.dll file has libc++.dll in its import table?
If you're not sure, can you post here that file?

@Wormnest
Copy link
Author

Does the C:\Program Files\GIMP 3\bin\libgraphite2.dll file has libc++.dll in its import table?

Yes it does. For Windows 64-bit we use binaries from MSYS2, the CLANG64 profile.

@m417z
Copy link
Member

m417z commented Jan 19, 2025

That's the issue, Windhawk loads its version of libc++.dll when the process starts. Then libgraphite2.dll tries to use that version instead of loading its own copy of libc++.dll, which results in an error since Windhawk's version is missing some exports.

I'm not sure when the new Windhawk version will be ready. A rough estimation is hopefully in a month or two. For now, if you'd like to implement a workaround on your side, perhaps the easiest thing is to rename your copy of libc++.dll and to update the import table of libgraphite2.dll (given it's the only library importing libc++.dll) with the new name. You can rename libc++.dll to a new name of the same length (e.g. gmpc++.dll), in which case you can simply hex-edit libgraphite2.dll. It's not pretty, but it's probably the easiest workaround which doesn't require code/toolchain changes.

@Wormnest
Copy link
Author

For now, if you'd like to implement a workaround on your side...

Thank you for your suggestion. We use automated builds through our CI and prefer to have replicatable builds. Manually patching binaries, or even doing it automated doesn't sound attractive, especially since the number of reports is low. Though we can point individual users to it that have that issue.

@m417z m417z added the planned The issue is planned to be addressed label Jan 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working planned The issue is planned to be addressed
Projects
None yet
Development

No branches or pull requests

2 participants