Re: In tree builds broken in lib/ncurses?

From: Steve Kargl <sgk_at_troutmask.apl.washington.edu>
Date: Sat, 14 Jun 2014 18:30:57 -0700
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:
> > > > > 
> > > > > Is it possible to using profiling on FreeBSD-current?  After
> > > > > installing
> > > > > libc_p.a, I try to build math/lapack.  It dies with
> > > > > 
> > > > > /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
> > > > 
> > > > collect2? I think you've got something odd going on there..
> > > 
> > > 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.
> > 
> > Where is the symbol _end suppose to come from?
> > 
> > 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
> 
> _end is a dynamic symbol that is synthesized by ld or linker scripts.  
> Normally that would be /usr/bin/ld
> 
> peter_at_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 = .; PROVIDE (end = .);
> 
> It used to be built into the a.out linker, but it's in the built-in linker 
> scripts since the ELF switch.
> 
> Your problem isn't clang vs gcc or libc_p, it's /usr/local/bin/ld or a linker 
> script the gfortran stuff is using.
> 

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.

-- 
Steve
Received on Sat Jun 14 2014 - 23:30:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:50 UTC