Date: Fri, 28 Oct 2016 06:51:12 -0700 From: Patrick Powell <papowell@astart.com> To: freebsd-ports@freebsd.org Subject: Re: Problem with gcc5 std library when building ports Message-ID: <4eeae082-de0a-65be-b934-9336a4acf8d4@astart.com> In-Reply-To: <CAGnMC6pcVCgv4_g-3At5drkTAaVicCS1U4yXXdV2-QOF92=fYg@mail.gmail.com> References: <CAGnMC6pcVCgv4_g-3At5drkTAaVicCS1U4yXXdV2-QOF92=fYg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/26/16 16:01, Dewayne Geraghty wrote: > Have spent a couple of days trying to build around 800 ports with gcc5. > This one has me stumped! > > Can anyone help regarding the apparant absence of snprintf from std? Am I > missing something, perhaps LDCONFIG or? I've looked in /usr/ports/Mk/ > bsd.gcc.mk and /usr/ports/Mk/bsd.port.mk but this is an area that I'm > unfamiliar, so nothing really stood out. > > If I change the compiler from gcc5 to clang everything compiles and runs > correctly. I have in /etc/make.conf > USE_GCC= 5 > and to use clang, I just comment out the above. So everything is constant, > on FreeBSD 10.3Stable (updated and rebuilt overnight) > > For example: /usr/ports/devel/jsoncpp (but many share this problem) > g++5 -o buildscons/linux-gcc-FreeBSD/src/lib_json/json_reader.o -c -O2 > -pipe -DOPENSSL_NO_SSL2 -DOPENSSL_NO_SSL3 -g0 -ggdb0 -DSTRIP_FBSDID > -UDEBUGGING -UDEBUG -march=c3-2 -mtune=c3-2 -Wl,-rpath=/usr/local/lib/gcc5 > -fno-strict-aliasing --std=c++11 -Wl,-rpath=/usr/local/lib/gcc5 -Iinclude > src/lib_json/json_reader.cpp > > src/lib_json/json_reader.cpp: In member function 'std::__cxx11::string > Json::Reader::getLocationLineAndColumn(Json::Reader::Location) const': > src/lib_json/json_reader.cpp:34:18: error: 'snprintf' is not a member of > 'std' > #define snprintf std::snprintf > > And for completeness: > # ldconfig -r | grep -E "gcc|\+" > search directories: > /lib:/usr/lib:/usr/lib/compat:/usr/local/lib:/usr/local/lib/gcc5:/usr/local/lib/heimdal:/usr/local/lib/perl5/5.20/mach/CORE > 35:-lgcc_s.1 => /lib/libgcc_s.so.1 > 38:-lc++.1 => /usr/lib/libc++.so.1 > 126:-lcc1.0 => /usr/local/lib/gcc5/libcc1.so.0 > 127:-lgcc_s.1 => /usr/local/lib/gcc5/libgcc_s.so.1 > 128:-lstdc++.6 => /usr/local/lib/gcc5/libstdc++.so.6 > 129:-lcilkrts.5 => /usr/local/lib/gcc5/libcilkrts.so.5 > 130:-lssp.0 => /usr/local/lib/gcc5/libssp.so.0 > 131:-lquadmath.0 => /usr/local/lib/gcc5/libquadmath.so.0 > 132:-lgfortran.3 => /usr/local/lib/gcc5/libgfortran.so.3 > 133:-lobjc.4 => /usr/local/lib/gcc5/libobjc.so.4 > 134:-lgomp.1 => /usr/local/lib/gcc5/libgomp.so.1 > 135:-lgomp-plugin-host_nonshm.1 => > /usr/local/lib/gcc5/libgomp-plugin-host_nonshm.so.1 > 136:-litm.1 => /usr/local/lib/gcc5/libitm.so.1 > 137:-latomic.1 => /usr/local/lib/gcc5/libatomic.so.1 > > Regards, Dewayne > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > Way way back in the early days of the standardization of the C library, the Great Minds decided that putting snprintf into the C library would not be done as it was 'not part of the deployed routines' or something similar. So they left in sprintf, which ended up causing more boundary overruns and attacks then any other routine. Don't get me started about strcpy, etc. etc. -- Patrick Powell Astart Technologies papowell@astart.com 1530 Jamacha Rd, Suite X Network and System San Diego, CA 92019 Consulting 858-874-6543 FAX 858-751-2435 Web: www.astart.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4eeae082-de0a-65be-b934-9336a4acf8d4>