Date: Sat, 5 Nov 2011 15:28:16 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Dimitry Andric <dim@freebsd.org> Cc: current@freebsd.org Subject: Re: 9.0/i386 build failure Message-ID: <20111105132816.GR50300@deviant.kiev.zoral.com.ua> In-Reply-To: <4EB53803.2000205@FreeBSD.org> References: <20111104190912.GA21948@bewilderbeast.blackhelicopters.org> <4EB53803.2000205@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--ZTeqt8Ca5PdqcYoi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 05, 2011 at 02:20:03PM +0100, Dimitry Andric wrote: > On 2011-11-04 20:09, Michael W. Lucas wrote: > > I suspect I'm building on a system that's too old, but it's worth > > asking. > >=20 > > FreeBSD eyeball.lodden.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sat Aug = 29 00:31:14 EDT 2009 mwlucas@stretchlimo.blackhelicopters.org:/usr/obj/= usr/src/sys/GENERIC i386 > >=20 > > csup today. no /etc/src.conf, /etc/make.conf only contains a perl > > definition. > >=20 > > ... > > c++ -O2 -pipe -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/inc= lude -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/incl= ude -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I= . -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/inc= lude -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTA= NT_MACROS -DLLVM_HOSTTRIPLE=3D\"i386-unknown-freebsd9.0\" -I/usr/obj/usr/sr= c/tmp/legacy/usr/include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o = tblgen ARMDecoderEmitter.o AsmMatcherEmitter.o AsmWriterEmitter.o AsmWriter= Inst.o CallingConvEmitter.o CodeEmitterGen.o CodeGenDAGPatterns.o CodeGenIn= struction.o CodeGenRegisters.o CodeGenTarget.o DAGISelEmitter.o DAGISelMatc= her.o DAGISelMatcherEmitter.o DAGISelMatcherGen.o DAGISelMatcherOpt.o Disas= semblerEmitter.o EDEmitter.o FastISelEmitter.o FixedLenDecoderEmitter.o Ins= trEnumEmitter.o InstrInfoEmitter.o IntrinsicEmitter.o PseudoLoweringEmitter= .o RegisterInfoEmi > tter.o SetTheory.o StringMatcher.o SubtargetEmitter.o TGValueTypes.o Tabl= eGen.o X86DisassemblerTables.o X86RecognizableInstr.o /usr/obj/usr/src/tmp/= usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmtablegen/libllvmtabl= egen.a /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang= /libllvmsupport/libllvmsupport.a -legacy > > /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang/li= bllvmsupport/libllvmsupport.a(Atomic.o)(.text+0x25): In function `llvm::sys= ::AtomicIncrement(unsigned int volatile*)': > > : undefined reference to `__sync_add_and_fetch_4' >=20 > Hm, the only way I can imagine this happening, is then you compile your > system with -march=3Di386. In that case the atomic primitives, such as > __sync_add_and_fetch, are called as external functions, which would lead > to a link error like the above. >=20 > I tried building 9-STABLE from a 9-CURRENT box that was not updated > since April 2011, and from a fairly recent 8-STABLE, but both did not > exhibit this issue. >=20 > Are you using any special other settings, e.g. in your environment, or > on the make command line? In case, it would be handy if you post the > full buildlog somewhere, so we can see which flags have been used to > compile the llvmsupport library. The system gcc was changed to assume march=3D486 some time ago. I suppose that the current-9 system is before the change, see r198344. --ZTeqt8Ca5PdqcYoi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk61Oe8ACgkQC3+MBN1Mb4i0zwCg61j9PoGvUyfXrKXT8ehz8Twr es4An1bxrAbqcUYR3rkY2plcIC/87LxF =KnXA -----END PGP SIGNATURE----- --ZTeqt8Ca5PdqcYoi--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111105132816.GR50300>