2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020 2021 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Why is EpicsHostArch.pl not executable? |
From: | "Johnson, Andrew N. via Core-talk" <[email protected]> |
To: | "Konrad, Martin" <[email protected]>, "[email protected]" <[email protected]> |
Date: | Mon, 1 Jul 2019 20:31:23 +0000 |
Hi Martin, On 7/1/19 2:35 PM, Konrad, Martin wrote:
EpicsHostArch.pl must be installed into the architecture-independent lib/perl directory, because the build needs it to be able to work out what the host-arch should default to when the EPICS_HOST_ARCH environment variable hasn't been set. Because of its destination path the file gets installed using the build rule for installing perl modules, which aren't executable programs so that rule doesn't set the execute flags on the targets it installs (none of the files under lib/perl have their executable flag set).I just discovered that in contrast to all the other Perl scripts EpicsHostArch.pl isn't marked executable. Steps to reproduce: git clone https://git.launchpad.net/epics-base cd epics-base/ make -s -j ls -l lib/perl/EpicsHostArch.pl -r--r--r-- 1 marko marko 2071 Jul 1 15:00 lib/perl/EpicsHostArch.pl A look at the Makefile reveals that this file is being installed in a different way [1]. The comment suggests that the different target is intentional but I'm not so sure about the missing executable flag. Could you please shine some light on this? The configure/CONFIG rule and the startup/* scripts all run EpicsHostArch.pl using perl path/to/EpicsHostArch.pl so it will work without having its executable flag set. The Perl installation that the shell runs will of course control what host-arch gets returned by the script. If that doesn't work for some specific installation the correct fix is to set the EPICS_HOST_ARCH environment variable on that system (or adjust the PATH so the correct Perl appears first in the search order, but the other solution is probably less work). Note that we can't use the $(PERL) macro in configure/CONFIG because that variable only gets set much later in an arch-specific configure/os file, and to find the right file we need to know the host-arch. Bootstrapping is a tricky process... HTH, - Andrew -- Complexity comes for free, Simplicity you have to work for. |