Arch Linux User Repository

Missing python-setuptools in makedepends. Tested in clean container.

As I mentioned before, Perl has not been supported by upstream for years. It's probably best to finally remove it from the PKGBUILD, to align the configuration with upstream, and make PKGBUILD maintenance easier going forward.

If someone actually uses Perl scripts in Golly (that cannot easily be ported to Lua or Python) they should probably leave a comment, but I suspect nobody cares about Perl support anymore.

For reference, here is an updated PKGBUILD for Golly 4.2 with Perl support removed: https://pastebin.com/raw/WzC9xYp6

I am getting compile errors (using all latest package versions):

wxperl.cpp: In function 'void pl_help(PerlInterpreter*, CV*)':
wxperl.cpp:231:34: error: invalid conversion from 'char* (*)(PerlInterpreter*, SV*, STRLEN*, I32)' {aka 'char* (*)(interpreter*, sv*, long unsigned int*, int)'} to 'char* (*)(PerlInterpreter*, SV*, STRLEN*, U32)' {aka 'char* (*)(interpreter*, sv*, long unsigned int*, unsigned int)'} [-fpermissive]
  231 | #define Perl_sv_2pv_flags        G_Perl_sv_2pv_flags
      |                                  ^~~~~~~~~~~~~~~~~~~
      |                                  |
      |                                  char* (*)(PerlInterpreter*, SV*, STRLEN*, I32) {aka char* (*)(interpreter*, sv*, long unsigned int*, int)}
/usr/lib/perl5/5.38/core_perl/CORE/sv.h:1953:21: note: in expansion of macro 'Perl_sv_2pv_flags'
 1953 |                     Perl_sv_2pv_flags, FALSE, 0)
      |                     ^~~~~~~~~~~~~~~~~
/usr/lib/perl5/5.38/core_perl/CORE/sv.h:1972:37: note: in expansion of macro 'SvPV_flags'
 1972 | #define SvPV(sv, len)               SvPV_flags(sv, len, SV_GMAGIC)
      |                                     ^~~~~~~~~~
wxperl.cpp:3021:28: note: in expansion of macro 'SvPV'
 3021 |     const char* htmlfile = SvPV(ST(0), n_a);
      |                            ^~~~
/usr/lib/perl5/5.38/core_perl/CORE/sv_inline.h:911:27: note:   initializing argument 6 of 'char* Perl_SvPV_helper(PerlInterpreter*, SV*, STRLEN*, U32, PL_SvPVtype, char* (*)(PerlInterpreter*, SV*, STRLEN*, U32), bool, U32)'
  911 |                  char * (*non_trivial)(pTHX_ SV *, STRLEN * const, const U32),
      |                  ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This gets repeated several times for all kinds of pl_* functions.

Perl scripting is no longer supported in the official release, but the source code for it is still present, and the current PKGBUILD enables Perl scripting manually.

However, as it happens the current build doesn't work with the current version of Perl (5.36.0) because of a missing symbol (Perl_newSV_type). It turns out that fixing it is far from trivial because of the nonstandard way Golly uses Perl (it uses dlopen() to access libperl.so on demand, rather than having a binary dependency on libperl.so directly).

Perhaps the time has come to drop Perl support from the PKGBUILD. It does seem more consistent with the Arch Linux packaging principles as described here: https://wiki.archlinux.org/title/Arch_Linux#Simplicity

Here is an updated PKGBUILD without Perl support: https://gist.githubusercontent.com/maksverver/ebba5f944a5ac17f73774c93ce28943c/raw/b9f7f584af5a88af949f156ff591c8bd79938fdd/PKGBUILD

Is the perl dependency still required? I think Perl scripting support was removed in version 2.8.

makserver: Now it works, I retried just now and it installed without problems.

Luke: it works fine for me. Can you generate debug info including the command that fails? Something like:

cd src/golly-4.2-src/gui-wx
make -f makefile-gtk -d

...should print more information.

Can't install latest version on my Arch Linux

/bin/sh: syntax error at line 1: `(' unexpected

make: *** [makefile-gtk:226: ObjGTK/wxprefs.o] Error 3

I changed it to wxwidgets-gtk3 now, because I could not get it to compile with WX_CONFIG = wx-config --toolkit=qt and the -qt5 package also has the same provides.

Let me know when there is a ways to build with Qt5/6, would be happy to support that as option.

This could probably just depend on "wxwidgets" (which is provided by wxwidgets-gtk3) instead of a specific gtk version.