1994 1995 1996 1997 1998 1999 2000 2001 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 | 1994 1995 1996 1997 1998 1999 2000 2001 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: cross-compiling v7.0.7 |
From: | "Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov> |
To: | Pierrick M Hanlet <hanlet at fnal.gov>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Thu, 15 Jun 2023 15:12:05 -0500 |
Most of that looks fine, but could you try unsetting your EPICS_BASE
environment variable and see whether that makes a difference? I can't replicate your symptoms when I try setting it myself, but I suspect it's likely to be related to that somehow. I haven't tried setting it in my .bashrc or .profile, I don't see how that could make a difference but it might. Were does your environment variable get set? - Andrew On 6/15/23 2:27 PM, Pierrick M Hanlet
wrote:
Hi Andrew, In base/configure/ I modify: - CONFIG_SITE to define CROSS_COMPILER_TARGET_ARCHS and CROSS_COMPILER_HOST_ARCHS. - CONFIG_COMMON to add USR_CXXFLAGS += -std=c++11 INSTALL_LOCATION remains commented out in CONFIG_SITE and I don't set it anywhere else. In base/configure/os/ I have additional files (most are unmodified): CONFIG.Common.target-arch CONFIG.linux-x86_64.target-arch CONFIG_SITE.Common.target-arch CONFIG_SITE.linux-x86_64.target-arch where target-arch matches one in the list from CROSS_COMPILER_TARGET_ARCHS. Of these, I modify CONFIG_SITE.Common.target-arch to point to the cross-compiled libraries, etc. Yes, I have the EPICS_BASE set as an environment variable. This allows me to test my build in my own area before pushing to a production build in our CI/CD pipeline. I don't use any command line flags with make apart from -s most of the time, though not at the moment until this is sorted. Cheers, Pierrick On 6/15/23 14:05, Andrew Johnson wrote:Hi, There is something unexpected in your environment then because the file should be created properly — it is when everyone else runs 'make', and I'd like to work out what's different in your case; you shouldn't have to resort to creating it manually, or to replacing the RULES_MODULES file. Do you happen to have an environment variable 'EPICS_BASE' set? Are you providing any additional command-line parameters when you run make? Do you have any files or a 'configure' directory in the parent directory of where Base is installed? Do you set INSTALL_LOCATION in any configure files? - Andrew On 6/15/23 1:56 PM, Pierrick M Hanlet via Tech-talk wrote:Greetings Andrew, Oddly, even "make clean" creates the new file, so it's a bit of a nuisance; I have to have one terminal to run make and another one to update (copy a working version of the RELEASE.linux-x86_64.local file) after the build has started. Interestingly, the v7.0.5 also has a RELEASE.linux-x86_64.local with "EPICS_BASE = ", but that did not adversely affect the build. Note that we have no special build locations. I'm running a test now, and it appears that if I use the v7.0.5 ./configure/RULES_MODULES, everything works as before. Cheers, Pierrick On 6/15/23 10:49, Andrew Johnson via Tech-talk wrote:Hi Pierrick, On 6/15/23 6:07 AM, Pierrick M Hanlet via Tech-talk wrote:Something broke, or I missed new instructions in building the modules in v7.0.7 for cross-compiled platforms. I'm building for several platforms. The host build is fine, but when the cross-compiled platforms start building a new RELEASE.linux-x86_64.local is created with "EPICS_BASE = ", i.e. empty. I did not experience this with v7.0.5.Hopefully the fix should be to just delete that file and run 'make' again in that directory, but if you have a more complex local build process (e.g. if you're building on multiple host arch's) that might need some modifications. How were you doing the cross-builds? Getting the build rules right for generating the modules/RELEASE.<host>.local file was tricky, and there were some changes made to them between 7.0.5 and 7.0.7:$ git log R7.0.5.. -- configure/RULES_MODULES commit 098ee6c063c25c3b4483d7d5a0b6c8c6d8d17769 Author: Andrew Johnson<anj at anl.gov> Date: Sat Sep 3 10:59:26 2022 -0500 Oops: Fix to RULES_MODULES commit efc7cbaf7f93c1bc58f98b30b9d20a27bc0a7f91 Author: Andrew Johnson<anj at anl.gov> Date: Fri Sep 2 14:10:27 2022 -0500 Build system fixes related to INSTALL_LOCATION * The build can't descend into external submodules when there is no configure/RULES_TOP file present in $(INSTALL_LOCATION). * Recreate modules/RELEASE.<host>.local if configure/CONFIG_SITE or configure/CONFIG_SITE.local have changed. * Move the distclean of modules/RELEASE.<host>.local to RULES_TOP * Several comment and white-space changes commit 191ff137f17eecde9e836f0f9aeaec5eecb73b24 Author: Andrew Johnson<anj at anl.gov> Date: Wed Nov 24 21:58:32 2021 -0600 configure: Use GNU Make's abspath instead of fullPathname.pl Add new INSTALL_ABSOLUTE variable, remove duplicates.There are some comments at the top of the RULES_MODULES file but they were mostly intended for other applications that want to adopt the submodules scheme (the motor record uses it too). - Andrew -- Complexity is free, it's Simplicity that takes work.-- Complexity is free, it's Simplicity that takes work. -- Complexity is free, it's Simplicity that takes work. |