Experimental Physics and Industrial Control System
Hi Ben,
I have an explanation, but it isn't complete. Look carefully:
On 03/07/2017 08:32 AM, Benjamin Franksen wrote:
> franksen@tiber: ...test/validate/O.linux-x86 > make
> make -f ../Makefile TOP=../../.. T_A=linux-x86 all
This is the first pass through the Makefile:
> make[1]: Entering directory
> `/home/franksen/src/seq/branch-2-3/home/test/validate/O.linux-x86'
> perl /home/franksen/src/epics-base/3.14/bin/linux-x86/mkmf.pl -m
> wait.st.d . ../os/Linux ../os/posix ../os/default .. wait.i ../wait.st
> make[1]: Leaving directory
> `/home/franksen/src/seq/branch-2-3/home/test/validate/O.linux-x86'
End of first pass, during which it generated the wait.st.d file, which
GNUmake regards as part of the Makefile because that generated file is
listed in an include statement. During the first pass GNUmake's aim is
to build the Makefile. Then GNUmake reloads the Makefile and all its
includes and runs the second pass to build the target we asked it for:
> make[1]: Entering directory
> `/home/franksen/src/seq/branch-2-3/home/test/validate/O.linux-x86'
> preprocessing ../wait.st
> /usr/bin/gcc -x c -E -D_GNU_SOURCE -D_DEFAULT_SOURCE -D_X86_
> -DUNIX -Dlinux -I. -I../O.Common -I. -I..
> -I../../../include/os/Linux -I../../../include
> -I/home/franksen/src/epics-base/3.14/include/os/Linux
> -I/home/franksen/src/epics-base/3.14/include ../wait.st > wait.i
> compiling wait.i to C
> /home/franksen/src/seq/branch-2-3/home/bin/linux-x86/snc +m wait.i -o
> wait.c.tmp
> make[1]: *** [wait.c] Segmentation fault (core dumped)
> make[1]: Leaving directory
The snc program was run in the second pass, but died and an error
message was printed.
Compare with the 3.15 run following (I removed the 'waitfun.*' lines
from your original message as they weren't relevant to the issue and
might have been slightly confusing if left in):
> franksen@tiber: ...test/validate/O.linux-x86 > make
> make -f ../Makefile TOP=../../.. T_A=linux-x86 all
Here's the first pass through the Makefile again:
> make[1]: Entering directory
> `/home/franksen/src/seq/branch-2-3/home/test/validate/O.linux-x86'
> preprocessing ../wait.st
> /usr/bin/gcc -x c -E -D_GNU_SOURCE -D_DEFAULT_SOURCE -D_X86_
> -DUNIX -Dlinux -I. -I../O.Common -I. -I. -I..
> -I../../../include/compiler/gcc -I../../../include/os/Linux
> -I../../../include
> -I/home/franksen/src/epics-base/3.15/include/compiler/gcc
> -I/home/franksen/src/epics-base/3.15/include/os/Linux
> -I/home/franksen/src/epics-base/3.15/include ../wait.st > wait.i
> compiling wait.i to C
> /home/franksen/src/seq/branch-2-3/home/bin/linux-x86/snc +m wait.i -o
> wait.c.tmp
Wasn't that the same snc command which died in the 3.14 build?
> perl -CSD /home/franksen/src/epics-base/3.15/bin/linux-x86/mkmf.pl -m
> wait.st.d . ../compiler/gcc ../compiler/default . ../os/Linux
> ../os/posix ../os/default .. wait.i ../wait.st
> make[1]: Leaving directory
> `/home/franksen/src/seq/branch-2-3/home/test/validate/O.linux-x86'
... but we've only now got to the end of the first pass through the
Makefile. Here's the second pass after the wait.st.d file has been
created and the Makefile has been reloaded:
> make[1]: Entering directory
> `/home/franksen/src/seq/branch-2-3/home/test/validate/O.linux-x86'
> compiling wait.i to C
> /home/franksen/src/seq/branch-2-3/home/bin/linux-x86/snc +m wait.i -o
> wait.c.tmp
> make[1]: Leaving directory
> `/home/franksen/src/seq/branch-2-3/home/test/validate/O.linux-x86'
> make: *** [all] Error 2
The second pass ends here, presumably because the snc command died again.
One of the significant differences between the first and second passes
of the Makefile is that recipes needed for rebuilding Makefiles can fail
in the first pass and GNUmake will ignore those failures if the file it
was trying to build was included with a '-include' statement (which our
dependency files usually are).
The EPICS build system used to suppress echoing of commands that
generated the dependency files, but they are now displayed as it's much
less confusing. You can see what GNUmake is doing by adding --debug=m
which generates somewhat verbose output but is useful in these kinds of
situations, it explains what's happening during both passes whereas
--debug=b only explains the second pass.
I don't have time right now to explain in detail what's different about
the EPICS build systems between 3.14 and 3.15, basically we split off
the commands that generated dependency (.d) files from those that do
compilation, so in 3.15 we generate the .d files during the first pass
whereas in 3.14 they were generated during the build step.
Got to go now, hope this helps.
- Andrew
--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon
- Replies:
- Re: EPICS make problem Ben Franksen
- References:
- EPICS make problem Benjamin Franksen
- Navigate by Date:
- Prev:
DAQ/Controls software position Hartman, Steven M.
- Next:
Questions about css boy opi be run as a standalone program lzf neu
- 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
- Navigate by Thread:
- Prev:
Re: 3.15 build rules suppress crash message [was: EPICS make problem] Ben Franksen
- Next:
Re: EPICS make problem Ben Franksen
- 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