Date: Sat, 14 Jun 2014 19:44:29 -0600 From: Warner Losh <imp@bsdimp.com> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org, Peter Wemm <peter@wemm.org> Subject: Re: In tree builds broken in lib/ncurses? Message-ID: <5B8DE5E2-FC48-4B61-B759-7951821C72C3@gmail.com> In-Reply-To: <20140615013057.GA66589@troutmask.apl.washington.edu> References: <20140614201933.GA65847@troutmask.apl.washington.edu> <20140614221236.GA66187@troutmask.apl.washington.edu> <20140614223002.GB66187@troutmask.apl.washington.edu> <4610322.zAJlsEjG1I@overcee.wemm.org> <20140615013057.GA66589@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 14, 2014, at 7:30 PM, Steve Kargl = <sgk@troutmask.apl.washington.edu> wrote: > On Sat, Jun 14, 2014 at 03:38:58PM -0700, Peter Wemm wrote: >> On Saturday 14 June 2014 15:30:02 Steve Kargl wrote: >>> On Sat, Jun 14, 2014 at 03:12:36PM -0700, Steve Kargl wrote: >>>> On Sat, Jun 14, 2014 at 03:01:20PM -0700, Peter Wemm wrote: >>>>> On Saturday 14 June 2014 14:44:39 Steve Kargl wrote: >>>>>>=20 >>>>>> Is it possible to using profiling on FreeBSD-current? After >>>>>> installing >>>>>> libc_p.a, I try to build math/lapack. It dies with >>>>>>=20 >>>>>> /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined = reference to >>>>>> symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing = from >>>>>> command line collect2: error: ld returned 1 exit status >>>>>> *** Error code 1 >>>>>=20 >>>>> collect2? I think you've got something odd going on there.. >>>>=20 >>>> Maybe. math/lapack is built with gfortran, which is from >>>> lang/gcc47 on my system. lang/gcc47 is probably picking >>>> up the installed devel/binutils. This would explain the >>>> /usr/local/bin/ld instead of our /usr/bin/ld. libc_p.a is >>>> built with clang, so I'm probably running into yet-another >>>> clang vs gcc problem. >>>=20 >>> Where is the symbol _end suppose to come from? >>>=20 >>> Script started on Sat Jun 14 15:26:08 2014 >>> laptop-kargl:kargl[201] foreach i (/usr/lib/*.a) >>> foreach? echo $i >>> foreach? nm $i | grep 'U _end' >>> foreach? nm $i | grep 'T _end' >>> foreach? end >>> /usr/lib/libc.a >>> U _end >>=20 >> _end is a dynamic symbol that is synthesized by ld or linker scripts. = =20 >> Normally that would be /usr/bin/ld >>=20 >> peter@hub[10:35pm]~-110> grep _end = /usr/libdata/ldscripts/elf_x86_64_fbsd.x >> ... >> _end. Align after .bss to ensure correct alignment even if the >> _end =3D .; PROVIDE (end =3D .); >>=20 >> It used to be built into the a.out linker, but it's in the built-in = linker=20 >> scripts since the ELF switch. >>=20 >> Your problem isn't clang vs gcc or libc_p, it's /usr/local/bin/ld or = a linker=20 >> script the gfortran stuff is using. >>=20 >=20 > Thanks for the pointer. The problem appears to be /usr/local/bin/ld. > If I move it to ld.old and then symlink /usr/local/bin/ld to = /usr/bin/ld, > I can build math/lapack without a problem. I guess I'll poke around > in devel/bintuils. We don=92t support building the tree with any ld but the one in the = tree. However, having said that, if you can fix it, that would be = awesome. I=92d like to see our support expand to include latter-day = versions of binutils on all platforms to help with the eventual demise = of in-tree gcc... Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5B8DE5E2-FC48-4B61-B759-7951821C72C3>