Summary: | arm's lang/perl5.20: via pkg install perl5: cc => '/nxb-bin/usr/bin/cc' in /usr/local/lib/perl5/5.20/mach/Config.pm | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Mark Millard <marklmi26-fbsd> | ||||
Component: | Individual Port(s) | Assignee: | Mathieu Arnold <mat> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Only Me | CC: | freebsd-arm, perl, sbruno | ||||
Priority: | --- | Keywords: | needs-patch, needs-qa | ||||
Version: | Latest | Flags: | koobs:
maintainer-feedback?
(perl) koobs: merge-quarterly? |
||||
Hardware: | arm | ||||||
OS: | Any | ||||||
See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208282 | ||||||
Attachments: |
|
Description
Mark Millard
2015-12-25 16:06:13 UTC
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 |