Magic vlsi layout tool "sudo make install" fails with "No rule to make target '../cmwind/libcmwind.o', needed by 'tclmagic.so'. Stop."

[cirosantilli]

http://opencircuitdesign.com/magic/

git  clone git://opencircuitdesign.com/magic-8.2
cd magic-8.2
git checkout c40547a47e2e47372093dba0a6f66bb28019983e
./configure
make
sudo make install

then:

--- installing executable to /usr/local/bin
--- installing runtime files to /usr/local/lib
make[2]: *** No rule to make target '../cmwind/libcmwind.o', needed by
'tclmagic.so'.  Stop.

Ubuntu 17.10.

[RTimothyEdwards]

I have not seen it fail to compile libcmwind like this before. However, you will need to check the error log, which is "make.log", and find the actual compile error.

[cirosantilli]

Thanks for the pointer. There was some message about missing csh so I installed it and the error went away from the CLI. I wish this dependency could be checked on configure step.

However, if I look into make.log, there are still error messages, namely:

gcc -g -m64 -fPIC -Wimplicit-int -fPIC  -I/usr/include/tcl8.6/tk-private/generic -I/usr/include/tcl8.6 -I. -I..  -o tclmagic.so  -shared -Wl,-soname,tclmagic.so -Wl,--version-script=../magic/symbol.map  \
    ../cmwind/libcmwind.o ../commands/libcommands.o ../database/libdatabase.o ../dbwind/libdbwind.o ../drc/libdrc.o ../debug/libdebug.o ../extract/libextract.o ../graphics/libgraphics.o ../select/libselect.o ../textio/libtextio.o ../tiles/libtiles.o ../windows/libwindows.o ../wiring/libwiring.o ../resis/libresis.o ../sim/libsim.o ../netmenu/libnetmenu.o ../plow/libplow.o ../utils/libutils.o ../ext2sim/libext2sim.o ../ext2spice/libext2spice.o ../calma/libcalma.o ../cif/libcif.o ../plot/libplot.o ../lef/liblef.o ../extflat/libextflat.o ../garouter/libgarouter.o   ../mzrouter/libmzrouter.o ../router/librouter.o     ../irouter/libirouter.o ../grouter/libgrouter.o     ../gcr/libgcr.o ../tcltk/libtcltk.o  \
    -lc -lX11 -lGL -lGLU -lXi  -lXext -lm -lcairo -lfontconfig -lfreetype -lstdc++    -lm    -L/usr/lib/x86_64-linux-gnu -ltkstub8.6 -L/usr/lib/x86_64-linux-gnu -ltclstub8.6 
gcc -E -x c -DX11 -DXLIB -DOGL -DCAIRO -DNDEBUG -DCAD_DIR=\"/usr/local/lib\" -DBIN_DIR=\"/usr/local/bin\" -DTCL_DIR=\"/usr/local/lib/magic/tcl\"  -DUSE_TCL_STUBS -DUSE_TK_STUBS -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DMAGIC_VERSION=\"8.2\" -DMAGIC_REVISION=\"41\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSIZEOF_VOID_P=8 -DSIZEOF_UNSIGNED_INT=4 -DSIZEOF_UNSIGNED_LONG=8 -DSIZEOF_UNSIGNED_LONG_LONG=8 -DSTDC_HEADERS=1 -DHAVE_SETENV=1 -DHAVE_PUTENV=1 -DHAVE_SYS_MMAN_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_PATHS_H=1 -DHAVE_VA_COPY=1 -DHAVE___VA_COPY=1 -DFILE_LOCKS=1 -DCALMA_MODULE=1 -DCIF_MODULE=1 -DPLOT_MODULE=1 -DLEF_MODULE=1 -DROUTE_MODULE=1 -DUSE_NEW_MACROS=1 -DHAVE_LIBGL=1 -DHAVE_LIBGLU=1 -DVECTOR_FONTS=1 -DHAVE_LIBCAIRO=1 -DMAGIC_WRAPPER=1 -DTHREE_D=1 -Dlinux=1 -DSYSV=1 -DISC=1 -DGCORE=\"/usr/bin/gcore\" -DSHDLIB_EXT=\".so\" -DNDEBUG -DMAGIC_DATE="\"`date`\"" -DCAD_DIR="/usr/local/lib" proto.magicrc.in > proto.magicrc
<command-line>:0:0: warning: "CAD_DIR" redefined
<command-line>:0:0: note: this is the location of the previous definition
proto.magicrc.in:1:3: error: invalid preprocessing directive #$
 # $(CAD_ROOT)/magic/sys/.magicrc
   ^
...

I'm not sure if this matters or not, but it looks like gcc is trying to compile a non C file.

[RTimothyEdwards]

It is using gcc as a macro preprocessor, which is a very bad idea (not mine). I once converted this to m4 (this is in version 8.1) but m4 is just as bad, for different reasons. I have a python script for the preprocessor that I intended to use in version 8.2 but I have not integrated it into the code yet.

[RTimothyEdwards]

I think that if you remove the first line of magic/proto.magicrc.in, it should work. I don't know why some versions of gcc handle macros differently.

[cirosantilli]

I wonder why not just use cpp directly if the goal is to just use the preprocessor.

[RTimothyEdwards]

I think it did, before. Version 8.2 is development code. I was in the process of changing to the python script preprocessor that better suits my purposes. Both cpp and gcc-as-preprocessor are designed to work with C syntax, not to be general-purpose macro processors.