proto.magicrc.in:1:3: error: invalid preprocessing directive

[ryandesign]

magic 8.3.282 does build on macOS 10.15 and later but no longer builds on macOS 10.14 or earlier:

proto.magicrc.in:1:3: error: invalid preprocessing directive
#       $(CAD_ROOT)/magic/sys/.magicrc 
        ^
proto.magicrc.in:2:4: error: invalid preprocessing directive
#       System wide start up file for magic, defines default macros.
        ^
proto.magicrc.in:5:3: error: invalid preprocessing directive
#       Source file proto.magicrc.in
        ^
proto.magicrc.in:6:3: error: invalid preprocessing directive
#       Process this file with the cpp macro processor
        ^
proto.magicrc.in:13:4: error: invalid preprocessing directive
#  Default .magicrc macro file (new macros)
   ^
proto.magicrc.in:15:3: error: invalid preprocessing directive
# A key
  ^
proto.magicrc.in:19:3: error: invalid preprocessing directive
# B key
  ^
proto.magicrc.in:22:3: error: invalid preprocessing directive
# C key
  ^
proto.magicrc.in:24:3: error: invalid preprocessing directive
# D key
  ^
proto.magicrc.in:27:3: error: invalid preprocessing directive
# E key
  ^
proto.magicrc.in:29:3: error: invalid preprocessing directive
# F key
  ^
proto.magicrc.in:32:3: error: invalid preprocessing directive
# G key
  ^
proto.magicrc.in:35:3: error: invalid preprocessing directive
# I key
  ^
proto.magicrc.in:41:3: error: invalid preprocessing directive
# L key
  ^
proto.magicrc.in:50:3: error: invalid preprocessing directive
# M key
  ^
proto.magicrc.in:53:3: error: invalid preprocessing directive
# N key
  ^
proto.magicrc.in:55:3: error: invalid preprocessing directive
# O key
  ^
proto.magicrc.in:58:3: error: invalid preprocessing directive
# P key
  ^
proto.magicrc.in:65:3: error: invalid preprocessing directive
# Q key
  ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]

Full build log of magic 8.3.284 failing to build on macOS 10.14.

magic 8.3.279 and earlier built fine on macOS versions down to 10.6 at least.

Full build log of 8.3.279 building on macOS 10.14.

I did not test magic 8.3.280 or 8.3.281 so I don't know exactly which version introduced the problem.

[ryandesign]

@ryandesign is https://github.com/The-OpenROAD-Project/OpenLane#prerequisites met?

I'm not familiar with "The-OpenROAD-Project" but I see at that link that it requires Python 3.6 or later.

Indeed, macOS 10.14 and earlier do not come with Python 3. It can of course be installed separately if that's required.

I see that the magic configuration summary in the log says:

Python3:      no

  Magic installation will use the gcc preprocessor for forming
  the default SCMOS technology files and the macro definitions.
  This usually works, but in case of preprocessor failure, you
  may need python3 installed.

The build then proceeded. If python 3 is required, it should not proceed; it should error.

macOS, of course, hasn't used gcc for over a decade; it uses clang. Perhaps whatever's being done here with the preprocessor is using some gcc-specific feature that's not implemented or works differently in clang's preprocessor.

Also missing python3 ./env.py issue-survey

I'm not sure what you mean. Were you asking me to run that command and show you the output?

[RTimothyEdwards]

@ryandesign : If python3 is defined, then the "preproc.py" script will be used instead of trying to misapply the C preprocessor on the file. Otherwise, Mac OS might require some specific setting of MCPP in configure.in to make it work right.

if test "x${PYTHON3}" == "xno"; then

   dnl check size of pointer for correct behavior on 64-bit systems
   dnl If the C preprocessor is GCC, we need to force the flag to
   dnl assert that input files are of type C, or else the preprocessing
   dnl stage will not execute correctly on the ".in" files in the scmos
   dnl directory.

   usingPython3=
   if test "$CPP" = "$CC -E" ; then
      MCPP="$CPP -x c"
      MSED="sed -e 's/\\/\\\\/'"
   else
      MCPP="$CPP"
      MSED="sed -e 's/\\/\\\\/'"
   fi

else
   MCPP="\${MAGICDIR}/scripts/preproc.py -ccomm"
   MSED="cat"
   usingPython3=1
fi

[ryandesign]

Thanks. Using python3 does work. However if you intend to keep the codepath that uses cpp if python3 is not available, we should fix it so it works for all cpp flavors.

The problem here seems to be that the input files use the # character both to introduce preprocessor directives and to introduce comment lines. When the python3 script is used to process the file, these comment lines are preserved and only known preprocessor directives are acted upon. When clang -E is used as cpp, it issues errors for the comment lines that it considers to be unknown preprocessor directives and exits with an error code after 20 such errors. When gcc -E is used as cpp, it too issues such errors and exits with an error code (though it processes the full file and doesn't give up after 20 errors) so I'm not sure with which type of cpp this would actually succeed.

Both gcc and clang delete the comment lines from the output. To solve the problem and for consistency with the python3 script, maybe the solution is to use sed to eliminate the comment lines before passing the input to either cpp or the python3 script. I intend to try out such a modification soon. Or if preservation of the comment lines in the output is preferred, I can work on a solution that accomplishes that in all cases.