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

Special case Gtk related dlls to dl_load from the unpacked inc dir #8

Closed

Conversation

shawnlaffan
Copy link
Contributor

@shawnlaffan shawnlaffan commented Oct 29, 2023

This allows packed Gtk2 apps to run on Windows as they otherwise do not work with their internal PAR names.

The xs.dll pattern is specific to Strawberry Perl and could be generalised to any file with a .dll extension.

Gtk3 might not need the treatment. Gtk4 is listed for future-proofing and also might not be needed.

Tested with the script below on Strawberry Perl 5.38.0.1, packed using pp_autolink.

Alien::GtkStack::Windows is needed for the script to run. It can be installed using cpanm.

cpanm https://github.com/shawnlaffan/perl-alien-gtkstack-windows.git

The readme for that repo also includes installation instructions for the Gtk2, Pango, Cairo and Glib modules for Strawberry Perl 5.38 via PPMs.

Test script:

use 5.010;
use strict;
use warnings;
$| = 1;
say 'Running';
use Alien::GtkStack::Windows;
use Gtk2;
Gtk2->init; 
my $window = Gtk2::Window->new ('toplevel');
my $button = Gtk2::Button->new ('Quit');
$button->signal_connect (clicked => sub { Gtk2->main_quit });
$window->add ($button);
$window->show_all;
Gtk2->main;

This allows packed Gtk2 apps to run on Windows as they
otherwise do not work with their internal PAR names.

The xs.dll pattern is specific to Strawberry Perl
and could be generalised to any file with a .dll
extension.
@rschupp
Copy link
Owner

rschupp commented Oct 29, 2023

This allows packed Gtk2 apps to run on Windows as they otherwise do not work with their internal PAR names.

What is the exact problem? What do you mean by "internal PAR names"?

Gtk3 might not need the treatment. Gtk4 is listed for future-proofing and also might not be needed.

If it's not needed, leave it out. Putting in unnecessary stuff is not "future-proofing".

This is a gross hack without any justification (though I know that the PAR ecosystem already has lots of them).
Also I'm reluctant to add hacks for dead software - the last release of module Gtk2 on CPAN was 4 years ago and the final release of gtk 2.x was 2 years ago.

@shawnlaffan
Copy link
Contributor Author

shawnlaffan commented Oct 29, 2023

(Edited after posting - an overly sensitive touchpad caused a commit of a partial response).

What is the exact problem?

Sorry, I should have given links. This is a long-standing problem with Gtk related modules under PAR. Some relevant links are:
https://www.perlmonks.org/?node_id=1229903
https://www.nntp.perl.org/group/perl.par/2019/02/msg6644.html

Your post at https://www.nntp.perl.org/group/perl.par/2019/02/msg6667.html allowed me to zero-in on the part of PAR where it manifests.

What do you mean by "internal PAR names"?

These are the "mangled" names PAR uses to store files at its top level. For example "d8b0e911.xs.dll" instead of "Cairo.xs.dll" (that's not the correct rename but it serves as an example).

If it's not needed, leave it out. Putting in unnecessary stuff is not "future-proofing".

I'll get Gtk3 up and running to check if it has the same problems. I expect it will since it also depends on Cairo.

I'll remove Gtk4.

Also I'm reluctant to add hacks for dead software - the last release of module Gtk2 on CPAN was 4 years ago and the final release of gtk 2.x was 2 years ago.

Fair enough, but there are still legacy applications that use Gtk2.

FWIW, I did also try to use the files under $ENV{PAR_TEMP}/inc/auto in all cases as a more general solution but that needs more work as other modules then fail.

@shawnlaffan
Copy link
Contributor Author

I've now tested with Gtk3.

Gtk3 itself does not need special handling but it is needed for Glib::Object::Introspection as auto/Glib/Object/Introspection/Introspection.xs.dll depends on Glib.xs.dll.

I'll update this PR once #10 has been resolved (either #10 is applied or #9 is reverted).

@rschupp
Copy link
Owner

rschupp commented Oct 31, 2023

Gtk3 itself does not need special handling but it is needed for Glib::Object::Introspection as auto/Glib/Object/Introspection/Introspection.xs.dll depends on Glib.xs.dll.

Right, that's the original sin: linking Gtk2.xs.dll and others with Glib.xs.dll (only needed on Windows).

FWIW, I did also try to use the files under $ENV{PAR_TEMP}/inc/auto in all cases as a more general solution but that needs more work as other modules then fail.

My take on this idea is in branch gtk-stuff: it "registers" these XS DLLs in %FullCache and thus

  • prevents them to be extracted a second time using a mangled name
  • makes PAR::_dl_findfile return the unmangled copy

Please try it out.

@shawnlaffan
Copy link
Contributor Author

Thanks Roderich.

That's a more generic solution. It works on my machine for the Gtk2 and Gtk3 test cases, as well as the larger Biodiverse code base.

rschupp added a commit that referenced this pull request Nov 1, 2023
…ache

This solves the problems mentioned in GitHub PR #8
("Special case Gtk related dlls to dl_load from the unpacked inc dir")
with applications using modules GTK2, Pango, Cairo and othes (this is
a Windows only problem)
@rschupp
Copy link
Owner

rschupp commented Nov 1, 2023

Thanks for testing Shawn, released as PAR 1.019

Close PR as superseded by 7626a9c

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants