On 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r341879: Wed Dec 12 12:07:32 CET 2018 amd64, ports tree at revison r487355, with lang/gcc7 at gcc7-7.4.0_1, I run into this error shown below. The same seem to happen with print/tex-luatex. Neither reinstalling gcc7, nor deleting both print/tex-luatex and print/tex-xetex solved the issue. I also tried to update and reinstall by force the ports providing the libraries shown in the libtool line designated with -lxxxx, but this also did not have any effect. I'm out of ideas. Another box, the very same FreeBSD 13-CURRENT, seems to compile both ports flawlessly and so I have as a workaround for the moment a package to install and circumvent the problem. But that doesn't solve the issue at all. On the box failing (a workstation used for the day-to-day work and development), there are different gcc compiler versions installed: #: pkg info -xo gcc aarch64-none-elf-gcc-6.4.0_2 devel/aarch64-none-elf-gcc gcc-7_2 lang/gcc gcc-ecj-4.5 lang/gcc-ecj45 gcc6-6.5.0_3 lang/gcc6 gcc7-7.4.0_1 lang/gcc7 gcc8-8.2.0_4 lang/gcc8 On the server which builds the ports in question (a server without most of the fancy workstation-stuff), there are only two gcc versions installed: #: pkg info -xo gcc gcc7-7.4.0_1 lang/gcc7 gcc8-8.2.0_4 lang/gcc8 Any ideas? [...] libtool: link: c++ -O2 -pipe -fstack-protector -fno-strict-aliasing -std=gnu++11 -fstack-protector -o xetex xetexdir/xetex-xetexextra.o synctexdir/xetex-synctex.o xetex-xetexini.o xetex-xetex0.o xetex-xetex-pool.o libxetex.a -L/usr/local/lib -lharfbuzz-icu -lharfbuzz -lgraphite2 -licui18n -licuuc -licudata -lpthread -lTECkit /usr/ports/print/tex-xetex/work/texlive-20150521-source/libs/poppler/libpoppler.a -lpng16 -lz -lfontconfig -lfreetype lib/lib.a -lkpathsea -lm ld: error: undefined symbol: std::_Rb_tree_decrement(std::_Rb_tree_node_base*) >>> referenced by stl_tree.h:302 (/usr/local/lib/gcc7/include/c++/bits/stl_tree.h:302) >>> Form.o:(std::pair<std::_Rb_tree_iterator<int>, bool> std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_insert_unique<int const&>(int const&)) in archive /usr/ports/print/tex-xetex/work/texlive-20150521-source/libs/poppler/libpoppler.a ld: error: undefined symbol: std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) >>> referenced by stl_tree.h:1755 (/usr/local/lib/gcc7/include/c++/bits/stl_tree.h:1755) >>> Form.o:(std::pair<std::_Rb_tree_iterator<int>, bool> std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_insert_unique<int const&>(int const&)) in archive /usr/ports/print/tex-xetex/work/texlive-20150521-source/libs/poppler/libpoppler.a ld: error: undefined symbol: std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) >>> referenced by stl_tree.h:2473 (/usr/local/lib/gcc7/include/c++/bits/stl_tree.h:2473) >>> Gfx.o:(Gfx::opXObject(Object*, int)) in archive /usr/ports/print/tex-xetex/work/texlive-20150521-source/libs/poppler/libpoppler.a
I boldly deleted lang/gcc after checking via pkg info -r (required by) what port requires that specific port and after that, the port build flawlessly! This also applies to Bug 233927 (PR 233927) which I close, too. I have no idea why the ports management did not delete lang/gcc after it has become obsoleted neither do I have aclue why it is installed at all with lang/gcc also present.
Sorry, I meant " ... why it is installed at all with lang/gcc7 also present.".
(In reply to O. Hartmann from comment #1) > I boldly deleted lang/gcc after checking via pkg info -r (required by) what > port requires that specific port and after that, the port build flawlessly! Reading this, at first I wondered whether I forgot to bump the PORTREVISION of lang/gcc (in which case it would still have referred to the older gcc7 as default), but that's not been the case. Is it possible that your rebuilds for the updates somehow were not complete? Which could well be a tools issue...
To be honest, I didn't check what the default gcc is set to - I did so today after reading your comment and realised that gcc7 is outdated. I also didn't care about gcc, since I use clang as my preferred compiler, although I know that several ports still rely on GNU gcc. Having said this, it implies I didn't took care about the change and hoped the automatic upgrade system would take care of any upgrade so far. It did not, obviously. lang/gcc7 has gone now since no port is reported to require gcc7 on some installations. lang/gcc seems to default to lang/gcc8, so I installed lang/gcc for now. I hope this solved the problems.