Re: In tree builds broken in lib/ncurses?

On Jun 14, 2014, at 7:30 PM, Steve Kargl <sgk_at_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:
>>>>>> 
>>>>>> 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.

We don’t 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’d 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