I intend to remove gets(3) in the near future and this port failed in the exp-run (PR 222796)
vh_debug.o: In function `dast_dbg':
vh_debug.c:(.text+0x444): undefined reference to `gets'
./.libs/libSch.a(sch_debug.o): In function `sch_debug':
sch_debug.c:(.text+0x317): undefined reference to `gets'
collect2: error: ld returned 1 exit status
Is marked broken - unfetchable.ports -r508077.
Created attachment 206413 [details]
update alliance links
(In reply to Walter Schwarzenfeld from comment #1)
the port is fetchable with these links:
And there is a newer version AFAIk without gets. I'll try to update it.
(In reply to Loïc Bartoletti from comment #4)
did you already have the opportunity to create a patch? I skimmed the sources of the 5.1.1 release and you're right - that release doesn't make use of gets(3) anymore.
If you had not had time yet I would develop a patch then.
(In reply to Kai Knoblich from comment #5)
Yes, I started before my vacation. My repo is here https://github.com/lbartoletti/freebsd-ports/tree/cad__alliance-5.1.1/cad/alliance
For now, I try to fix an error with ar: "ar: `u' modifier ignored since `D' is the default (see `U')"
rm -f libU.a
ar cru libU.a UConst.o USys.o UOpts.o UInter.o MMBK.o MPower.o MDRGrid.o MNodes.o MPri.o MNet.o AAstar.o ASimple.o RBox.o RMBK.o
ar: `u' modifier ignored since `D' is the default (see `U')
/bin/sh ../../libtool --tag=CXX --mode=link c++ -I/include -I../../abl/src -I../../aut/src -I../../beh/src -I../../genlib/src -I../../rds/src -I../../mbk/src -g -O2 -static -o nero nero.o -L/usr/local/lib -L/lib ./libU.a -L../../aut/src/.libs -L../../mbk/src/.libs -L../../rds/src/.libs -lMpu -lRds -lMlu -lMlo -lMph -lMut -lRcn -lAut -lm -lm -lm -lm
libtool: link: c++ -I/include -I../../abl/src -I../../aut/src -I../../beh/src -I../../genlib/src -I../../rds/src -I../../mbk/src -g -O2 -o nero nero.o -L/usr/local/lib -L/lib ./libU.a -L../../aut/src/.libs -L../../mbk/src/.libs -L../../rds/src/.libs /usr/home/lbartoletti/freebsd-ports/cad/alliance/work/alliance/src/mbk/src/.libs/libMpu.a /usr/home/lbartoletti/freebsd-ports/cad/alliance/work/alliance/src/rds/src/.libs/libRds.a ../../mbk/src/.libs/libMpu.a /usr/home/lbartoletti/freebsd-ports/cad/alliance/work/alliance/src/mbk/src/.libs/libMlu.a /usr/home/lbartoletti/freebsd-ports/cad/alliance/work/alliance/src/mbk/src/.libs/libMlo.a /usr/home/lbartoletti/freebsd-ports/cad/alliance/work/alliance/src/mbk/src/.libs/libMph.a /usr/home/lbartoletti/freebsd-ports/cad/alliance/work/alliance/src/mbk/src/.libs/libRcn.a /usr/home/lbartoletti/freebsd-ports/cad/alliance/work/alliance/src/mbk/src/.libs/libMut.a /usr/home/lbartoletti/freebsd-ports/cad/alliance/work/alliance/src/aut/src/.libs/libAut.a ../../mbk/src/.libs/libMut.a -lm
/usr/bin/ld: error: undefined symbol: TMatrix<CNode>::operator(int)
>>> referenced by MNodes.cpp:121
>>> MNodes.o:(CMatrixNodes::obstacle(CRect&, int)) in archive ./libU.a
(In reply to Loïc Bartoletti from comment #6)
Oh, that's great! I'll took a quick glance at the Makefile from your repo - maybe it still makes sense to stick with GCC and MAKE_JOBS_UNSAFE?
I'll take a closer look and do also some tests with your patch the following days.
Maybe we get cad/alliance building and running again before the 2019Q4 branch is created.
(In reply to Kai Knoblich from comment #8)
I tried with GCC, MAKE_JOBS_UNSAFE and configure --disable-static with the same error.
Created attachment 207412 [details]
(In reply to Loïc Bartoletti from comment #9)
Here's a preliminary patch based on your work. It builds fine on 11.2-, 11.3-, 12.0-RELEASE and 13.0-CURRENT@r352110 amd64 + i386.
It even seems to work without MAKE_JOBS_UNSAFE but it should be tested with some more build runs. When compiling with Clang, following error is emitted:
> ./fbl_bcomp_y.y:865:75: warning: incompatible pointer to integer conversion passing 'char *' to parameter of type 'long' [-Wint-conversion]
> addtab (hshtab,fbl_y_stack.l_mark[-5].text,0,FBL_PNTDFN,fbl_y_stack.l_mark[-1].text);
> ./fbl_bcomp_y.y:981:44: error: passing 'fbl_name' to parameter of incompatible type 'char *'
> fbtyp_pnt = (struct fbtyp*)chktab(hshtab,fbl_y_stack.l_mark[-1].name,FBL_MODNAM,FBL_PNTDFN);
> ./fbl_bcomp_y.y:1118:39: error: passing 'fbl_name' to parameter of incompatible type 'char *'
> fbl_y_val.name.FLAG = chktab(hshtab,fbl_y_stack.l_mark[-2].name,FBL_MODNAM,FBL_LBLDFN);
> 1 warning and 2 errors generated.
> gmake: *** [Makefile:661: fbl_bcomp_y.lo] Error 1
(In reply to Loïc Bartoletti from comment #9)
Meanwhile I verified the patches that no longer apply - they are definitely obsolete and were merged by upstream.
It seems that the preliminary patch attached in this PR might become the final version (with some minor modifications) because:
- Enable the build for Clang requires some additional patching, so USE_GCC=any is required at the moment
- USES=bison isn't needed as yacc(1) seems to work fine as an alternativ. Using devel/bison leads to more failures (with/without USE_GCC=yes).
- Several build cycles were completed successfully with disabled MAKE_JOBS_UNSAFE thus it can be removed.
I'm still looking through the set of patches that the Debian packages provides which ones can be used. For example, they use the same patch for "documentation/tutorials/start/start.tex" as the patch in this PR.
If you have some ideas/suggestions, I would be happy to try them out. Otherwise, if there are no objections I plan to commit the changes in the next few days.
P.S.: Would you like to become maintainer of the port?
A commit references this bug:
Date: Sat Sep 28 11:11:15 UTC 2019
New revision: 513117
cad/alliance: Update to 5.1.1, remove BROKEN and undeprecate
* The code has been modernized so most of the patches and the workaround
with USE_CXXSTD are therefore no longer required. USE_GCC is still needed
for build as some files cannot be compiled with Clang.
The updated code also contains no more occurences of the long deprecated
gets(3) function which has been removed since FreeBSD 1300043. 
* A patch from Debian's patchset  is required to remedy build issues
with the documentation.
* Add USE_XORG to pass stage QA as some binaries are linked against various
X libraries. Among these libraries is also the recently deprecated
x11/libXp, which is probably not needed but (still) pulled in by the
* Also pet portlint/portclippy while I'm here by grouping related USE_*
variables to the USES block and sort the other variables according to the
Submitted by: Lo?c Bartoletti <firstname.lastname@example.org> (based on)
Reported by: emaste 
Obtained from: Debian 
Committed, thank you all!
For the record: I added MAKE_JOBS_UNSAFE back to as I got some build failure that occurred randomly and I wasn't able to reproduce them safely. Thus better safe than sorry.