I have been climbing the "perl embedding and static linking" learning curve for some time now and it just seems that there is some logic behind what my first impression was, madness. And of course I now see opportunities to use static/embedded Perl everywhere. Your case for example...

If you are really desperate to get that working, then you can try to create a perl.exe which contains all the libraries it needs statically resulting in a very big exe which still needs to load pure-perl modules in the usual manner (so you would still need PAR for that) but does not need to load any XS libraries. They are all in there provided that you told the linker that you will need the functions in those libraries (read on).

Similar to building a static perl, you can also build statically a very basic C-Perl-embedding, see perlembed, Re: Embed perl problem and Pass signals and argv from C to embedded Perl for such program, which will load your script and execute it in the embedded perl interpreter. That means you still have your Perl program which loads up now via your own myperl.exe, instead of via perl.exe. What you achieve with that is to place in your C-program dummy statements requesting GTK and XS functions so that the linker does actually links them statically instead of scanning your C program (and not your Perl program of course, so you see now why these dummy statements are useful) for function calls and linking only those that it sees you use. This can be achieved by the newXS() call.

If I am not missing the point entirely about your situation and you decide to give this option a try, then let me know and can share my experience (I am planning to do it anyway in a couple of weeks when my stuff is more stable).

But to get you an idea of the workload and workflow:

1. install perlbrew (dont mess with your system perl!) and tell it to install a new perl and use "-Uusedl" - i.e. do not use dynamic loading (=loading XS on the fly) but instead static loading. There are some other options which may improve speed
2. Now the fun starts, you need to fetch all modules you will ever need and their dependencies and compile those that contain XS code with "LINKTYPE=static" option. Static libraries will be created and installed, e.g. Sort/XS/XS.a in my linux box). This will be a long and repeating process, especially because there are some modules which seem to fail with static linking, case in point: Term::ReadKey, a hell of a time to install that for me.
3. Now copy paste that C-Perl-embed program and start adding newXS() calls so that the linker does link the XS code you will need (remember the linker does not read Perl code!), for example newXS("Sort::XS::bootstrap", boot_Sort__XS, file) and add the Sort/XS/XS.a to the LDFLAGS.
4. From time to time your program will complain about missing libraries if you omitted including a very indirect XS dependency

ps. There are of course apps (which claim) to do static linking, like staticperl and fatpack. Maybe I have too much static (electricity, (c) BOFH) in my hands and none worked for me.

bw, bliako