pkg install perl5 on arm (rpi2 in my case) to get 5.20 messes up the path for cc to be "/nxb-bin/usr/bin/cc" in mach/Config.pm . This breaks builds, such as for p5-Locale-gettext-1.06 . See below for details. ===>>> All >> freetype2-2.6_1 >> devel/gmake >> devel/p5-Locale-gettext (5/66) ===> Cleaning for p5-Locale-gettext-1.06 . . . --- blib/arch/auto/Locale/gettext/gettext.so --- rm -f blib/arch/auto/Locale/gettext/gettext.so LD_RUN_PATH="/usr/local/lib" /nxb-bin/usr/bin/cc -shared -L/wrkdirs/usr/ports/lang/perl5.20/work/perl-5.20.3 -L/usr/local/lib/perl5/5.20/mach/CORE -Wl,-rpath=/usr/local/lib/perl5/5.20/mach/CORE -lperl -L/usr/local/lib -fstack-protector gettext.o -o blib/arch/auto/Locale/gettext/gettext.so -L/usr/local/lib -lintl sh: /nxb-bin/usr/bin/cc: not found *** [blib/arch/auto/Locale/gettext/gettext.so] Error code 127 The /nxb-bin/ text is from . . . # more /usr/local/lib/perl5/5.20/mach/Config.pm . . . # tie returns the object, so the value returned to require will be true. tie %Config, 'Config', { archlibexp => '/usr/local/lib/perl5/5.20/mach', archname => 'arm-freebsd-thread-multi-64int', cc => '/nxb-bin/usr/bin/cc', . . .
Adding Sean to the CC, I have no idea of how exactly the arm packages are built, so I'm not sure how it can be fixed.
Created attachment 168471 [details] nxb-perl.diff Can you tell me if the attached patch fixes your problem ? (You'll need to rebuild Perl.) (Well, or you'll need to run the sed command on the Config.pm and Config_heavy.pl files in /usr/local/lib/perl5/5.xx/...)
(In reply to Mathieu Arnold from comment #2) (1) A mistake? The ${REINPLACE_CMDNPLACE_CMD} uses seem to translate to empty strings. (I tried a direct "make post-build" in /usr/ports/lang/perl5.22 with CC set appropriately because the REINPLACE_CMDNPLACE_CMD text just looked odd. This was after patching the Makefile.) Should those have been ${REINPLACE_CMD} uses instead? (This suggests that avoiding the Makefile and directly sed'ing the Config.pm and Config_heavy.pl files in /usr/local/lib/perl5/5.xx/... would not make a great overall test as it would miss the above problem.) (2) How to test the overall behavior? My builds of perl5 would never have ${CC} == /nxb-bin/usr/bin/cc normally and if I tried having that path in the CC definition in my /etc/make.conf the build would normally fail for lack of such a path. My original work around to pkg installing something that was broken was to build the lang/perl5 port instead of using "pkg install perl5". That had no "/nxb-bin/usr/bin/cc" involved and worked fine. (It still works fine with the patch to the perl5 Makefile involved.) I expect that the /nxb-bin/usr/bin/cc comes from how things are built to make official packages (as done on the official servers). I do not know how to set up such a build. The closest simple test idea that I've come up with would be to temporarily have /nxb-bin/usr/bin/cc be a symbolic link to /usr/bin/cc during a perl5.xx build in my environment and have /etc/make.conf's CC reference /nxb-bin/usr/bin/cc at that time. Then later change /etc/make.conf's CC to reference /usr/bin/cc and remove /nxb-bin/usr/bin/cc from the file system before seeing if the devel/p5-Locale-gettext build problem repeats. Sound sufficient?
(In reply to Mark Millard from comment #3) > (In reply to Mathieu Arnold from comment #2) > > (1) A mistake? > > The ${REINPLACE_CMDNPLACE_CMD} uses seem to translate to empty strings. (I > tried a direct "make post-build" in /usr/ports/lang/perl5.22 with CC set > appropriately because the REINPLACE_CMDNPLACE_CMD text just looked odd. This > was after patching the Makefile.) > > Should those have been ${REINPLACE_CMD} uses instead? Ah, yes, something funny happened there, REINPLACE_CMD is what should be there. > (This suggests that avoiding the Makefile and directly sed'ing the Config.pm > and Config_heavy.pl files in /usr/local/lib/perl5/5.xx/... would not make a > great overall test as it would miss the above problem.) > > > (2) How to test the overall behavior? > > My builds of perl5 would never have ${CC} == /nxb-bin/usr/bin/cc normally > and if I tried having that path in the CC definition in my /etc/make.conf > the build would normally fail for lack of such a path. > > My original work around to pkg installing something that was broken was to > build the lang/perl5 port instead of using "pkg install perl5". That had no > "/nxb-bin/usr/bin/cc" involved and worked fine. (It still works fine with > the patch to the perl5 Makefile involved.) > > I expect that the /nxb-bin/usr/bin/cc comes from how things are built to > make official packages (as done on the official servers). I do not know how > to set up such a build. > > The closest simple test idea that I've come up with would be to temporarily > have /nxb-bin/usr/bin/cc be a symbolic link to /usr/bin/cc during a perl5.xx > build in my environment and have /etc/make.conf's CC reference > /nxb-bin/usr/bin/cc at that time. Then later change /etc/make.conf's CC to > reference /usr/bin/cc and remove /nxb-bin/usr/bin/cc from the file system > before seeing if the devel/p5-Locale-gettext build problem repeats. > > Sound sufficient? Yes, the /nxb-bin thing is there because of how the packages are built. It will only be there if you installed the official package. Making a symlink is a bad idea, it hides thing. I don't really get all that you're saying though. I'll just decide that my patch (with REINPLACE_CMD) works and commit it.
(In reply to Mathieu Arnold from comment #4) Okay. At least I found the one type of problem in the patches. Unless I first had built perl5.xx while "${CC} == /nxb-bin/usr/bin/cc" was true any attempt at test-building devel/p5-Locale-gettext would not be based on the new post-build target having been used during the perl5.xx build. In other words: It would not have tested your change if CC had any other path (or was undefined) during the perl5.xx build. So I was looking for a valid (but temporary) way of allowing "${CC} == /nxb-bin/usr/bin/cc" to be true during the perl5.xx build but not during the later devel/p5-Locale-gettext build. (This would simulate the conditions from my original report but with post-build used for perl5.xx.)
A simple "ln -s / /nxb-bin" solves your original problem. It's not a solution because it's not something that can be done with the Ports.
(In reply to Mathieu Arnold from comment #6) I originally solved my problem by simply building things via building ports locally based on my /etc/make.conf . (It also then used my usual clang/clang++ compiler options and path from /etc/make.conf .) I was not personally blocked by the pkg install not working but I reported it anyway. The only reason that I had to rebuild again was to do the testing of the adjusted perl5.xx Makefile structure per your request. I would never have suggested that the perl5.xx Makefile structure place any such links to enable the path involved. Manual creation of the path via using a symbolic link (and CC adjustment to use that path) would have been just a local means of getting the new perl5.xx post-build target to execute during the test sequence. After the test sequence I would have put things back to what I had before and rebuilt again.
A commit references this bug: Author: mat Date: Mon Apr 4 09:48:55 UTC 2016 New revision: 412502 URL: https://svnweb.freebsd.org/changeset/ports/412502 Log: Fix manual build of Perl modules when Perl has been cross compiled. PR: 205600 Reported by: Mark Millard Sponsored by: Absolight Changes: head/lang/perl5-devel/Makefile head/lang/perl5.18/Makefile head/lang/perl5.20/Makefile head/lang/perl5.22/Makefile