It seems as if recent changes to tools/sims repo sometimes cause build failures. I have observed this on FreeBSD 13 with both gcc10 and clang10. Interestingly, on MacOS 11.6.4 with clang13, the build is successful.
Here is the error:
*** pdp10-kl Simulator being built with:
*** - compiler optimizations and no debugging support. GCC Version: 10.3.0.
*** - dynamic networking support using FreeBSD provided libpcap components.
*** - Local LAN packet transports: PCAP TAP NAT(SLiRP)
*** - Per simulator tests will be run.
***
*** git commit id is a5c53fd2f80c0f2b78367090fb6c38789fe939d2.
*** git commit time is 2018-02-06T15:01:30+0100.
***
gcc -std=gnu99 -U__STRICT_ANSI__ -O2 -finline-functions -fgcse-after-reload -fpredictive-commoning -fipa-cp-clone -fno-unsafe-loop-optimizations -fno-strict-overflow -DSIM_GIT_COMMIT_ID=a5c53fd2f80c0f2b78367090fb6c38789fe939d2 -DSIM_GIT_COMMIT_TIME=2018-02-06T15:01:30+0100 -DSIM_COMPILER="GCC Version: 10.3.0" -DSIM_BUILD_TOOL=simh-makefile -I . -D_GNU_SOURCE -I/usr/local/include -DUSE_READER_THREAD -DSIM_ASYNCH_IO -DHAVE_PCRE_H -DHAVE_SEMAPHORE -DHAVE_SYS_IOCTL -DSIM_HAVE_DLOPEN=so -DHAVE_UTIME -DHAVE_LIBPNG -DHAVE_ZLIB -DHAVE_GLOB -DHAVE_SHM_OPEN ./PDP10/kx10_cpu.c ./PDP10/kx10_sys.c ./PDP10/kx10_df.c ./PDP10/kx10_mt.c ./PDP10/kx10_dc.c ./PDP10/kx10_rh.c ./PDP10/kx10_rp.c ./PDP10/kx10_tu.c ./PDP10/kx10_rs.c ./PDP10/kx10_imp.c ./PDP10/kl10_fe.c ./PDP10/ka10_pd.c ./PDP10/ka10_ch10.c ./PDP10/kx10_lp.c ./PDP10/kl10_nia.c ./PDP10/kx10_disk.c ./PDP10/kl10_dn.c ./scp.c ./sim_console.c ./sim_fio.c ./sim_timer.c ./sim_sock.c ./sim_tmxr.c ./sim_ether.c ./sim_tape.c ./sim_disk.c ./sim_serial.c ./sim_video.c ./sim_imd.c ./sim_card.c -DKL=1 -DUSE_INT64 -I ./PDP10 -DHAVE_PCAP_NETWORK -I/usr/include/ -DBPF_CONST_STRING -DUSE_SHARED -DHAVE_TAP_NETWORK -DHAVE_BSDTUNTAP -Islirp -Islirp_glue -Islirp_glue/qemu -DHAVE_SLIRP_NETWORK -DUSE_SIMH_SLIRP_DEBUG slirp/*.c slirp_glue/*.c -o BIN/pdp10-kl -L/lib -L/usr/lib -L/usr/lib/compat -L/usr/local/lib -L/usr/local/lib/compat/pkg -L/usr/local/lib/expect5.45.4 -L/usr/local/lib/gcc10 -L/usr/local/lib/perl5/5.32/mach/CORE -L/lib/ -L/usr/lib/ -lm -lrt -lpthread -lpcre -L/usr/local/lib/ -ldl -lpng -lz
/usr/local/bin/ld: /tmp//cc3fhuG1.o:(.bss+0x0): multiple definition of `cty_done'; /tmp//ccDW1dNm.o:(.bss+0x10ed4): first defined here
/usr/local/bin/ld: /tmp//cc3fhuG1.o:(.bss+0x20): multiple definition of `cty_out'; /tmp//ccDW1dNm.o:(.bss+0x10ee0): first defined here
/usr/local/bin/ld: /tmp//cc3fhuG1.o:(.bss+0x140): multiple definition of `cty_in'; /tmp//ccDW1dNm.o:(.bss+0x11000): first defined here
collect2: error: ld returned 1 exit status
gmake[1]: *** [makefile:3076: BIN/pdp10-kl] Error 1
The underlying problem is that a new file, kl10_dn.c was added that has unqualified top level references to cty_done,
cty_out and cty_in which are also unqualified (global) top level references in kl10_fe.c. The bit that seems to have
been cut-n-pasted is
If these aren't meant to be shared across files, they ought to be declared static to limit their scope to the file in while they are
defined. If they are meant to be shared, one definition should be extern.
I have no idea what rule clang13 used to decide to resolve the symbols. I'm not sure I enjoy reading documentation that much,
be would be happy to know the answer if someone knows it off the top of their head.
(This issue has also been submitted to https://github.com/PDP-10/its)
It seems as if recent changes to tools/sims repo sometimes cause build failures. I have observed this on FreeBSD 13 with both gcc10 and clang10. Interestingly, on MacOS 11.6.4 with clang13, the build is successful.
Here is the error:
The underlying problem is that a new file,
kl10_dn.c
was added that has unqualified top level references tocty_done
,cty_out
andcty_in
which are also unqualified (global) top level references inkl10_fe.c
. The bit that seems to have been cut-n-pasted isIf these aren't meant to be shared across files, they ought to be declared
static
to limit their scope to the file in while they are defined. If they are meant to be shared, one definition should beextern
.I have no idea what rule clang13 used to decide to resolve the symbols. I'm not sure I enjoy reading documentation that much, be would be happy to know the answer if someone knows it off the top of their head.