It turns out that if I have something like open(LOG, ">:encoding(UTF-8)", "$scriptpath/scripts/log.txt") or print "\nCan't create log file: $!\nContinuing anyway.\n"; before the .pm is loaded, it crashes. (It works if I remove ">:encoding(UTF-8)", but that's hardly ideal.)
It appears that the unicode IO layers are not thread-safe. I cannot help you with that, you'll have to raise a bug report.
The work around is to not open your logfile until after you've decided whether to invoke the GUI or not.
If you find that too restricting, then open the logfile without the encoding layer before making the decision and binmode the io layer on afterward:
I also have binmode STDIN, ':encoding(UTF-8)'; at the start of the script, which also crashes the GUI (IIRC it was needed for non-ASCII input file names to work on linux).
If you are using the gui, then you will not actually be using STDIN, as the input will come via Tk. So, only binmode stdin if you are not using the gui, as shown above.
From what I can tell, the thread-hostility of the unicode IO layers is not a some subtle error involving race conditions or mismatched locking, but rather a complete absence of any attempt on behalf of the code to be thread-safe. Just plain, old-fashioned bad coding.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.