Intrepid has asked for the wisdom of the Perl Monks concerning the following question:

I'm at it again: reveling in debugging the build of Someone Else's Code ;-). In this case, Someone is H. Merijn Brand with his recent release of Text::CSV_XS on CPAN.


EDIT

I don't want to give a false impression of my motivations, and where I wrote above that I "revel in debugging ..." I could be misunderstood. I don't take pleasure in calling anyone out for lack of skill, lack of knowledge, or carelessness. Rather, I revel in having a problem I can apply my own efforts to solving while seeing contributions from my fellow nuns and monks who spot things that I have missed. The collaboration is what I revel in. Thanks, now back to the matter at hand.


Looking closely at the compiler-related messages below, two things stand out as strange (see below in the "On Cygwin Perl..."):

-ffile-prefix-map=/mnt/share/cygpkgs/perl/perl.x86_64/build=/usr/src/debug/perl-5.40.2-1

-and-

-ffile-prefix-map=/mnt/share/cygpkgs/perl/perl.x86_64/src/perl-5.40.2=/usr/src/debug/perl-5.40.2-1

I don't have those paths, and self-evidently anything that starts with /mnt/ is not going to be portable, anyhow.

What happens on Gnu/Linux:

cp CSV_XS.pm blib/lib/Text/CSV_XS.pm Running Mkbootstrap for CSV_XS () chmod 644 "CSV_XS.bs" "/usr/local/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- CSV_ +XS.bs blib/arch/auto/Text/CSV_XS/CSV_XS.bs 644 "/usr/local/bin/perl" "/usr/local/lib/perl5/site_perl/ExtUtils/xsubpp" + -typemap '/usr/local/lib/perl5/5.40.1/ExtUtils/typemap' CSV_XS.xs +> CSV_XS.xsc mv CSV_XS.xsc CSV_XS.c cc -c -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe +-fsORTIFY_SOURCE=2 -O2 -DVERSION=\"1.61\" -DXS_VERSION=\"1.61\" -fP +IC "-I/usr/local/lib/perl5/5.40.1/i686-linux-gnu-thread-multi/CORE" + CSV_XS.c rm -f blib/arch/auto/Text/CSV_XS/CSV_XS.so cc -shared -O2 -L/usr/local/lib -fstack-protector-strong CSV_XS.o - +o blib/arch/auto/Text/CSV_XS/CSV_XS.so \ \ chmod 755 blib/arch/auto/Text/CSV_XS/CSV_XS.so Manifying 1 pod document

On Cygwin Perl 5.40.2 with gcc 13.4.0 what happens:

[MSG] [Thu Jul 31 18:03:07 2025] Checking if your kit is complete... Looks good Generating a Unix-style Makefile Writing Makefile for Text::CSV_XS Writing MYMETA.yml and MYMETA.json [MSG] [Thu Jul 31 18:03:07 2025] DEFAULT 'filter_prereqs' HANDLER RETU +RNING 'sub return value' [ERROR] [Thu Jul 31 18:03:23 2025] MAKE failed: No such file or direct +ory cp CSV_XS.pm blib/lib/Text/CSV_XS.pm Running Mkbootstrap for CSV_XS () chmod 644 "CSV_XS.bs" "/usr/bin/perl.exe" -MExtUtils::Command::MM -e 'cp_nonempty' -- CSV_XS +.bs blib/arch/auto/Text/CSV_XS/CSV_XS.bs 644 "/usr/bin/perl.exe" "/usr/local/share/perl5/site_perl/5.40/ExtUtils/xs +ubpp" -typemap '/usr/share/perl5/5.40/ExtUtils/typemap' CSV_XS.xs > + CSV_XS.xsc mv CSV_XS.xsc CSV_XS.c gcc -c -U__STRICT_ANSI__ -D_GNU_SOURCE -ggdb -O2 -pipe -Wall -Werror +=format-security -D_FORTIFY_SOURCE=3 -fstack-protector-strong --param +=ssp-buffer-size=4 -ffile-prefix-map=/mnt/share/cygpkgs/perl/perl.x86 +_64/build=/usr/src/debug/perl-5.40.2-1 -ffile-prefix-map=/mnt/share/c +ygpkgs/perl/perl.x86_64/src/perl-5.40.2=/usr/src/debug/perl-5.40.2-1 +-fwrapv -fno-strict-aliasing -DUSEIMPORTLIB -O3 -DVERSION=\"1.61\" +-DXS_VERSION=\"1.61\" "-I/usr/lib/perl5/5.40/x86_64-cygwin-threads/C +ORE" CSV_XS.c rm -f blib/arch/auto/Text/CSV_XS/CSV_XS.dll g++ --shared -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,- +-enable-auto-image-base -fstack-protector-strong CSV_XS.o -o blib/a +rch/auto/Text/CSV_XS/CSV_XS.dll \ /usr/lib/perl5/5.40/x86_64-cygwin-threads/CORE/cygperl5_40.dll -lpth +read -ldl -lcrypt \ make: *** [Makefile:484: blib/arch/auto/Text/CSV_XS/CSV_XS.dll] Aborte +d make: *** Deleting file 'blib/arch/auto/Text/CSV_XS/CSV_XS.dll' [ERROR] [Thu Jul 31 18:03:23 2025] Unable to create a new distribution + object for 'Text::CSV_XS' -- cannot continue

If anyone running CygPerl on Windows gets a different result trying to build Text::CSV_XS, please let me know in the thread, thanks.

    - Soren

Aug 01, 2025 at 21:39 UTC

A just machine to make big decisions
Programmed by fellows (and gals) with compassion and vision
We'll be clean when their work is done
We'll be eternally free yes, and eternally young
Donald Fagen —> I.G.Y.
(Slightly modified for inclusiveness)

  • Comment on New release of Text::CSV_XS won't build on Windows, prob a gcc input error (CygwinPerl)
  • Select or Download Code

Replies are listed 'Best First'.
Re: New release of Text::CSV_XS won't build on Windows, prob a gcc input error (CygwinPerl)
by syphilis (Archbishop) on Aug 02, 2025 at 01:41 UTC
    If anyone running CygPerl on Windows gets a different result trying to build Text::CSV_XS, please let me know in the thread, thanks

    I get something quite different:
    Owner@DESKTOP-88J497T /cygdrive/d/s/Text-CSV_XS-1.61 $ make cp CSV_XS.pm blib/lib/Text/CSV_XS.pm Running Mkbootstrap for CSV_XS () chmod 644 "CSV_XS.bs" "/cygdrive/c/cygperl-5.40.0-d/bin/perl.exe" -MExtUtils::Command::MM -e + 'cp_nonempty' -- CSV_XS.bs blib/arch/auto/Text/CSV_XS/CSV_XS.bs 644 "/cygdrive/c/cygperl-5.40.0-d/bin/perl.exe" "/cygdrive/c/cygperl-5.40. +0-d/lib/5.40.0/ExtUtils/xsubpp" -typemap '/cygdrive/c/cygperl-5.40.0 +-d/lib/5.40.0/ExtUtils/typemap' CSV_XS.xs > CSV_XS.xsc mv CSV_XS.xsc CSV_XS.c gcc -c -U__STRICT_ANSI__ -D_GNU_SOURCE -fwrapv -fno-strict-aliasing +-pipe -fstack-protector-strong -I/usr/local/include -D_FORTIFY_SOURCE +=2 -DUSEIMPORTLIB -O3 -DVERSION=\"1.61\" -DXS_VERSION=\"1.61\" "-I +/cygdrive/c/cygperl-5.40.0-d/lib/5.40.0/cygwin-thread-multi/CORE" C +SV_XS.c rm -f blib/arch/auto/Text/CSV_XS/CSV_XS.dll g++ --shared -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,- +-enable-auto-image-base -L/usr/local/lib -fstack-protector-strong CS +V_XS.o -o blib/arch/auto/Text/CSV_XS/CSV_XS.dll \ /cygdrive/c/cygperl-5.40.0-d/lib/5.40.0/cygwin-thread-multi/CORE/cyg +perl5_40_0.dll -lpthread -ldl -lcrypt \ chmod 755 blib/arch/auto/Text/CSV_XS/CSV_XS.dll Manifying 1 pod document Owner@DESKTOP-88J497T /cygdrive/d/s/Text-CSV_XS-1.61 $ make test "/cygdrive/c/cygperl-5.40.0-d/bin/perl.exe" -MExtUtils::Command::MM -e + 'cp_nonempty' -- CSV_XS.bs blib/arch/auto/Text/CSV_XS/CSV_XS.bs 644 PERL_DL_NONLAZY=1 "/cygdrive/c/cygperl-5.40.0-d/bin/perl.exe" "-MExtUt +ils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switc +hes; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/10_base.t ....... ok t/12_acc.t ........ ok t/15_flags.t ...... ok t/16_import.t ..... ok t/20_file.t ....... ok t/21_lexicalio.t .. ok t/22_scalario.t ... ok t/30_types.t ...... ok t/40_misc.t ....... ok t/41_null.t ....... ok t/45_eol.t ........ ok t/46_eol_si.t ..... ok t/47_comment.t .... ok t/50_utf8.t ....... ok t/51_utf8.t ....... ok t/55_combi.t ...... ok t/60_samples.t .... ok t/65_allow.t ...... ok t/66_formula.t .... ok t/67_emptrow.t .... ok t/68_header.t ..... ok t/70_rt.t ......... ok t/71_strict.t ..... ok t/75_hashref.t .... ok t/76_magic.t ...... ok t/77_getall.t ..... ok t/78_fragment.t ... ok t/79_callbacks.t .. ok t/80_diag.t ....... ok t/81_subclass.t ... ok t/85_util.t ....... ok t/90_csv.t ........ ok t/91_csv_cb.t ..... ok t/92_stream.t ..... ok All tests successful. Files=34, Tests=52594, 17 wallclock secs ( 1.47 usr 0.34 sys + 12.54 +cusr 2.51 csys = 16.86 CPU) Result: PASS
    And I can't see that suspicious -ffile-prefix-map.... stuff in my build of the module.

    Here is my perl -V output:
    $ perl -V Summary of my perl5 (revision 5 version 40 subversion 0) configuration +: Platform: osname=cygwin osvers=3.3.6-341.x86_64 archname=cygwin-thread-multi uname='cygwin_nt-10.0-22631 desktop-88j497t 3.3.6-341.x86_64 2022- +09-05 11:15 utc x86_64 cygwin ' config_args='-des -Dusethreads -Dusemultiplicity -Dprefix=/cygdriv +e/c/cygperl-5.40.0-d -Dlibpth=/lib/gcc/x86_64-pc-cygwin/11' hint=recommended useposix=true d_sigaction=define useithreads=define usemultiplicity=define use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define Compiler: cc='gcc' ccflags ='-U__STRICT_ANSI__ -D_GNU_SOURCE -fwrapv -fno-strict-alia +sing -pipe -fstack-protector-strong -I/usr/local/include -D_FORTIFY_S +OURCE=2' optimize='-O3' cppflags='-U__STRICT_ANSI__ -D_GNU_SOURCE -fwrapv -fno-strict-alia +sing -pipe -fstack-protector-strong -I/usr/local/include' ccversion='' gccversion='11.3.0' gccosandvers='' intsize=4 longsize=8 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=3 ivtype='long' ivsize=8 nvtype='double' nvsize=8 Off_t='off_t' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='g++' ldflags =' -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,- +-enable-auto-image-base -fstack-protector-strong -L/usr/local/lib' libpth=/lib/gcc/x86_64-pc-cygwin/11 /usr/local/lib /usr/lib /usr/l +ib/w32api /lib libs=-lpthread -ldl -lcrypt perllibs=-lpthread -ldl -lcrypt libc=/usr/lib/libcygwin.a so=dll useshrplib=true libperl=cygperl5_40_0.dll gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=dll d_dlsymun=undef ccdlflags=' ' cccdlflags=' ' lddlflags=' --shared -Wl,--enable-auto-import -Wl,--export-all-sy +mbols -Wl,--enable-auto-image-base -L/usr/local/lib -fstack-protector +-strong' Characteristics of this binary (from libperl): Compile-time options: HAS_LONG_DOUBLE HAS_STRTOLD HAS_TIMES MULTIPLICITY PERLIO_LAYERS PERL_COPY_ON_WRITE PERL_DONT_CREATE_GVSV PERL_HASH_FUNC_SIPHASH13 PERL_HASH_USE_SBOX32 PERL_OP_PARENT PERL_PRESERVE_IVUV PERL_USE_SAFE_PUTENV USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API Built under cygwin Compiled at Jun 10 2024 15:00:07 @INC: /cygdrive/c/cygperl-5.40.0-d/lib/site_perl/5.40.0/cygwin-thread-mu +lti /cygdrive/c/cygperl-5.40.0-d/lib/site_perl/5.40.0 /cygdrive/c/cygperl-5.40.0-d/lib/5.40.0/cygwin-thread-multi /cygdrive/c/cygperl-5.40.0-d/lib/5.40.0
    Not exactly the same version of perl as yours, and an older gcc (11.3.0) - but I don't think any of that would be relevant to the issue you're facing.

    Cheers,
    Rob

      I want to acknowledge Ken as well as Rob, thanks guys, you've both provided pretty definitive proof that something's amiss with my system perl.

      Rob wrote:

      I get something quite different:

      That is very different indeed. Everything just worked the way it's supposed to. I noticed that it seems you are running your own locally-built perl: "/cygdrive/c/cygperl-5.40.0-d/bin/perl.exe". And Ken is running a locally built perl managed with perlbrew. I think my assignment for this weekend may be to build my own CygwinPerl.

      You got the following g++ commandline:

      
      g++  --shared  -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--enable-auto-image-base -L/usr/local/lib -fstack-protector-strong  CSV_XS.o  -o blib/arch/auto/Text/CSV_XS/CSV_XS.dll  \
        /cygdrive/c/cygperl-5.40.0-d/lib/5.40.0/cygwin-thread-multi/CORE/cygperl5_40_0.dll -lpthread -ldl -lcrypt  \ 
      

      The dangling backslash \ continue is in my output too, and is strange, but it is just an artifact that has nothing to do with my build failure.

      Thanks again Rob.

          - Soren

      Aug 02, 2025 at 16:36 UTC
Re: New release of Text::CSV_XS won't build on Windows, prob a gcc input error (CygwinPerl)
by kcott (Archbishop) on Aug 02, 2025 at 11:39 UTC

    G'day Soren,

    I believe that I've warned you in the past about working directly with Cygwin's System Perl (/usr/bin/perl). If you update to the latest Cygwin Perl (v5.40.2), you'll get Text::CSV_XS version 1.60. I do Cygwin updates regularly; most recently was Friday evening (~24hrs ago).

    $ /usr/bin/perl -Mstrict -Mwarnings -E ' use Text::CSV_XS; say "Perl version: $^V"; say "Perl location: $^X"; say "Text::CSV_XS version: $Text::CSV_XS::VERSION"; say "Text::CSV_XS location: $INC{q{Text/CSV_XS.pm}}"; ' Perl version: v5.40.2 Perl location: /usr/bin/perl Text::CSV_XS version: 1.60 Text::CSV_XS location: /usr/lib/perl5/vendor_perl/5.40/x86_64-cygwin-t +hreads/Text/CSV_XS.pm

    I'm also reasonably certain that I recommended using Perlbrew. I updated to the lastest Perl (v5.42.0) this morning (~12hrs ago); I also installed the latest Text::CSV_XS from CPAN (version 1.61) along with many other modules.

    Using Perlbrew to switch between Perl versions, and using the above code but starting with perl -Mstrict -Mwarnings -E (i.e. no /usr/bin/), here's the output using recent Perl versions:

    Perl version: v5.38.0 Perl location: /home/ken/perl5/perlbrew/perls/perl-5.38.0/bin/perl Text::CSV_XS version: 1.50 Text::CSV_XS location: /home/ken/perl5/perlbrew/perls/perl-5.38.0/lib/ +site_perl/5.38.0/cygwin-thread-multi/Text/CSV_XS.pm Perl version: v5.40.0 Perl location: /home/ken/perl5/perlbrew/perls/perl-5.40.0/bin/perl Text::CSV_XS version: 1.54 Text::CSV_XS location: /home/ken/perl5/perlbrew/perls/perl-5.40.0/lib/ +site_perl/5.40.0/cygwin-thread-multi/Text/CSV_XS.pm Perl version: v5.42.0 Perl location: /home/ken/perl5/perlbrew/perls/perl-5.42.0/bin/perl Text::CSV_XS version: 1.61 Text::CSV_XS location: /home/ken/perl5/perlbrew/perls/perl-5.42.0/lib/ +site_perl/5.42.0/cygwin-thread-multi/Text/CSV_XS.pm

    Consider leaving Cygwin's System Perl for Cygwin's use and start using Perlbrew for your own use and experimentation.

    I'm fairly sure that solutions other than Perlbrew exist. I'm not familiar with these; perhaps another monk can advise you.

    — Ken

      Ken, you are the person advocating for me to use perlbrew ;-) so I am going to toss this your way and ask if you have any suggestions. I had perlbrew installed for months but there was some initial trouble getting it to work and so I never built any perl using it. Today I tried again and unfortunately some tests failed:

        Failed tests:  269-270, 275-276, 281-282, 287-288, 293-294
                      299-300, 305-306, 311-312, 317-318, 323-324
                      329-330, 335-336, 341-342, 347-348, 353-354
                      359-360, 365-366, 371-372, 377-378, 383-384
                      389-390, 395-396, 401-402, 407-408
        Non-zero exit status: 48
      Files=2930, Tests=1351653, 907 wallclock secs (146.98 usr 139.20 sys + 1447.43 cusr 1224.94 csys = 2958.56 CPU)
      Result: FAIL
      Finished test run at Sat Aug  2 14:05:14 2025.
      make: *** (GNUmakefile:853: test_harness) Error 1
      perl-5.42.0 is successfully installed.  <-- ha ha
      perl-5.42.0 is not installed  <-- ha ha
      

      I naturally went for the newest perl release, 5.42.0.:

      perlbrew install -v -j 5 --switch --thread --multi --64all perl-5.42.0

      Any ideas? Try with an older release maybe?

          — Soren

      Aug 02, 2025 at 18:22 UTC


        FWIW, I have no experience with Perlbrew. I don't see the point of it. I actually hate it - which is quite irrational (isn't all hatred ?) given that I've never tried it.
        For mine, I just build perl in the normal way by running 'Configure', 'make test', 'make install' and finally 'make distclean' (in prepraration for the next build, of a different configuraton).

        So, for my stock standard build of perl-5.42.0, I started with:
        sh Configure -des -Dusethreads -Dusemultiplicity -Dprefix=/cygdrive/c/cygperl-5.42.0-d -Dlibpth=/lib/gcc/x86_64-pc-cygwin/11

        For my -Duselongdouble build:
        sh Configure -des -Dusethreads -Dusemultiplicity -Dprefix=/cygdrive/c/cygperl-5.42.0-ld -Dlibpth=/lib/gcc/x86_64-pc-cygwin/11 -Duselongdouble

        And for my -Dusequadmath build:
        sh Configure -des -Dusethreads -Dusemultiplicity -Dprefix=/cygdrive/c/cygperl-5.42.0-q -Dlibpth=/lib/gcc/x86_64-pc-cygwin/11 -Dusequadmath

        I think I need that '-Dlibpth' switch only because I want the quadmath library to be automatically found for all 3 builds.
        For you, I think that directive would end with "13" instead of "11", but I'm only guessing ... and it might even be the case that, with your gcc-13, there's no need for that directive any more.

        I regularly hit a failing test in t/porting/exec-bit.t, and in one other file (I forget which).
        My Cygwin installation is a few years old - your Cygwin might fare better.
        Those couple of failures don't bother me at all, and I've not reported them.

        I select which perl I want to use by running (eg):
        export PATH=/cygdrive/c/cygperl-5.42.0-d/bin:$PATH

        If I want to switch to a different perl I just run (eg):
        export PATH=/cygdrive/c/cygperl-5.42.0-q/bin:$PATH

        On cygwin I have (double, longdouble and quadmath builds) of perls 5.36.0, 5.38.0, 5.40.0, and 5.42.0.
        It's easy to handle, and I'm not about to bother with perlbrew.
        Of course, those who do want to use perlbrew for whatever purpose, are entitled to do so.

        Cheers,
        Rob

        It's been quite a few years since I set up Cygwin & Perlbrew. I'll provide what information I can: some current and some quite old.

        My current Win10 — what I see when I start cmd.exe:

        Microsoft Windows [Version 10.0.19045.6159] (c) Microsoft Corporation. All rights reserved. C:\Users\ken>

        My current system (Cygwin) information:

        $ uname -a CYGWIN_NT-10.0-19045 titan 3.6.4-1.x86_64 2025-07-15 07:55 UTC x86_64 +Cygwin

        I originally set up Cygwin using the installer on the Cygwin site; I have updated that many times over the years (currently at 3.6.4).

        As far as I remember, I originally set up Perlbrew from the instructions on that page:

        For a quick installation, do this:

        \curl -L https://install.perlbrew.pl | bash

        It would appear that I did this about six years ago and haven't changed it since:

        $ which perlbrew /home/ken/perl5/perlbrew/bin/perlbrew $ ls -l /home/ken/perl5/perlbrew/bin/perlbrew -rwxr-xr-x 1 ken None 1316905 Jul 26 2019 /home/ken/perl5/perlbrew/bi +n/perlbrew

        I've been installing Perl versions using instructions a little further down on that page. This is what I used yesterday.

        To install the latest stable release ...

        perlbrew install perl-5.42.0 perlbrew switch perl-5.42.0

        This installed Perl v5.42.0 cleanly on the first run; no test or other errors.

        I've also installed other Perl versions, stable & development, over the years:

        $ perlbrew list * perl-5.42.0 perl-5.40.0 perl-5.39.3 perl-5.38.0 perl-5.36.0 perl-5.34.0 perl-5.33.5 perl-5.32.0 perl-5.30.0

        I really can't help with the error information that you've posted. You may want to start (almost) from scratch:

        1. Get Cygwin up-to-date. I do this by downloading the Cygwin Installer (setup-x86_64.exe) then running that from Win10: File Explorer.
        2. Reinstall perlbrew using the instructions shown above.
        3. Reinstall Perl v5.42.0 using the instructions shown above.

        I'll also advise you to run the latest setup-x86_64.exe regularly — I generally aim to do this weekly so that it only takes some tens of minutes — otherwise you may find it takes hours if left for an extended period of time.

        Good luck!

        — Ken

Re: New release of Text::CSV_XS won't build on Windows, prob a gcc input error (CygwinPerl)
by pryrt (Abbot) on Aug 02, 2025 at 19:07 UTC
    Given your setup, where you have both Strawberry Perl and Cygwin intermixed, and given that we know you've had problems in the past (It's Tuesday, so it must be the day for Trouble With Cpan and Funny-business with Win32 extension module build, as two examples) where Cygwin interferes with your Strawberry setup, I am highly suspicious that now you've got your Strawberry interfering with your Cygwin.

    When you're trying to do something in Cygwin -- whether it's installing the module in the Cygwin system perl or trying to run perlbrew to install another perl in Cygwin -- you need to make sure that your paths are all pointing where you think they are, and that they aren't pointing to a conglomeration of Strawberry and Cygwin locations.

    echo $PATH which perl which cpan which cpanm which perlbrew which gcc perl -V gcc -v

    At this point, your intial post when asking for help with installing anything should include all that information (or the equivalent with cmd.exe's where or powershell's Get-Command, depending on which environment you are trying to use; I listed the linux-style which this time, since you're currently in the Cygwin environment), because otherwise the monks will waste their time assuming you have a sane setup, and only after half a dozen posts or more will it come out that there's interference between the two yet again.

    I am curious why you have both Cygwin and Strawberry. It seems to me that you'd have a lot better luck in your perl module endeavors if you'd just pick one and become fluent in it. If there's a good reason, there's a good reason... but then you should consider figuring out how to keep the two completely separate from each other (make sure that your path in cmd.exe only shows Strawberry and nothing Cygwin, and that your path in Cygwin only shows its options and nothing from Strawberry).

      G'day pryrt,

      "I am curious why you have both Cygwin and Strawberry."

      I don't know what Intrepid's reasons are but I don't think that situation is particularly unusual. I have a diverse collection of Perls for home and $work use:

      • Cygwin System Perl — only used for demonstation purposes as in this thread.
      • Perlbrew Perls (currently nine versions) sitting on Cygwin — used directly for home/personal use.
      • Strawberry Perls (several versions; couldn't be bothered to count them) — used for some specific $work projects.
      • ActivePerl (no longer used but it's still floating around somewhere) — was used for a specific $work project.
      • And I ssh from Perlbrew Perls Cygwin (typically via bash scripts)[Updated: 14/8/25] to a variety of $work Linux systems with their own Perl versions.

      You're quite correct in that these need to be managed. I recall that I used to have some issues. I sorted all of this out many years ago and I now have no problems with this many Perl versions.

      — Ken

      Hi, all. I just installed the CPAN module XS::Parse::Sublike using my system CygwinPerl and the build and test and install worked just as it ought to, and as it has before, many times, with XS (C-extension) modules being added on my system. The only difference I see with Text::CSV_XS is that it requires a call to g++ because C++ code is being used.

      I understand the point you are making, pryrt, and I appreciate the advice. I will try to provide full information about my system in the future. I don't want to waste the monks' time or frustrate anyone.

      Aug 09, 2025 at 17:37 UTC

      A just machine to make big decisions
      Programmed by fellows (and gals) with compassion and vision
      We'll be clean when their work is done
      We'll be eternally free yes, and eternally young
      Donald Fagen —> I.G.Y.
      (Slightly modified for inclusiveness)

        You don't need to manually install Text::CSV_XS version 1.61 — just update Cygwin.

        As I said last week, I typically update Cygwin weekly (usually on a Friday). Here's a reminder of the code I posted then:

        $ /usr/bin/perl -Mstrict -Mwarnings -E ' use Text::CSV_XS; say "Perl version: $^V"; say "Perl location: $^X"; say "Text::CSV_XS version: $Text::CSV_XS::VERSION"; say "Text::CSV_XS location: $INC{q{Text/CSV_XS.pm}}"; ' Perl version: v5.40.2 Perl location: /usr/bin/perl Text::CSV_XS version: 1.60 Text::CSV_XS location: /usr/lib/perl5/vendor_perl/5.40/x86_64-cygwin-t +hreads/Text/CSV_XS.pm

        When I updated Cygwin last Friday (i.e. 3 days ago) I noticed (amongst other changes) that Text::CSV_XS was updated to version 1.61 — here's what I get when I run the same code today:

        $ /usr/bin/perl -Mstrict -Mwarnings -E ' use Text::CSV_XS; say "Perl version: $^V"; say "Perl location: $^X"; say "Text::CSV_XS version: $Text::CSV_XS::VERSION"; say "Text::CSV_XS location: $INC{q{Text/CSV_XS.pm}}"; ' Perl version: v5.40.3 Perl location: /usr/bin/perl Text::CSV_XS version: 1.61 Text::CSV_XS location: /usr/lib/perl5/vendor_perl/5.40/x86_64-cygwin-t +hreads/Text/CSV_XS.pm

        I still recommend Perlbrew. ☺️

        Update: The second block of code had the start of the command twice; probably a copy-paste error; fixed.

        — Ken