Bug 205600 - 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
Summary: arm's lang/perl5.20: via pkg install perl5: cc => '/nxb-bin/usr/bin/cc' in /u...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: arm Any
: --- Affects Only Me
Assignee: Mathieu Arnold
URL:
Keywords: needs-patch, needs-qa
Depends on:
Blocks:
 
Reported: 2015-12-25 16:06 UTC by Mark Millard
Modified: 2016-06-25 03:14 UTC (History)
3 users (show)

See Also:
koobs: maintainer-feedback? (perl)
koobs: merge-quarterly?


Attachments
nxb-perl.diff (2.04 KB, patch)
2016-03-22 01:18 UTC, Mathieu Arnold
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Millard 2015-12-25 16:06:13 UTC
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',
. . .
Comment 1 Mathieu Arnold freebsd_committer 2015-12-25 21:49:08 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.
Comment 2 Mathieu Arnold freebsd_committer 2016-03-22 01:18:20 UTC
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/...)
Comment 3 Mark Millard 2016-03-23 11:39:57 UTC
(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?
Comment 4 Mathieu Arnold freebsd_committer 2016-03-23 11:52:51 UTC
(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.
Comment 5 Mark Millard 2016-03-23 19:44:29 UTC
(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.)
Comment 6 Mathieu Arnold freebsd_committer 2016-03-23 20:14:39 UTC
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.
Comment 7 Mark Millard 2016-03-23 20:45:56 UTC
(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.
Comment 8 commit-hook freebsd_committer 2016-04-04 09:49:27 UTC
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