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: | ioc executable being made corrupted |
From: | "Crisp, Daniel" <[email protected]> |
To: | "[email protected]" <[email protected]> |
Date: | Mon, 3 Oct 2016 22:13:07 +0000 |
Hello, When running my st.cmd, I get a bad interpreter error for my ioc’s executable: ../../bin/linux-x86_64/<PROD_IOC>^M: bad interpreter: No such file or directory This was a working IOC I’m trying to port to a new host, at one point I even got it to work on the new host ($(TOP): make distclean, make, cd iocboot/ioc<name>, ./st.cmd) using CRLF settings on git, but ended up reverting back and can’t
re-create this solution. Prevention is probably the best method to deal with this, by ensuring all editors are using LF/UNIX settings. But now that I’m in this state, I’m unsure what the best course of action is.. I can’t seem to tell what file is corrupting my
binary output. How does the EPICS community handle fixing CRLF/LF eols, or even know where to find the conflict? Is it even expected that my freshly output binary executable would be corrupted due to (…any?) ‘CRLF files’ having existed under TOP at time of
make? For reference, what I thought made it work before was using LF only for files matching: *.c, *.h, *.db, and *.substitutions.
Any and all help, or direction is very much appreciated. Thank you! -Dan |