Re: In tree builds broken in lib/ncurses?

On Jun 14, 2014, at 7:30 PM, Steve Kargl <[e-mail]>=
 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@hub[10:35pm]~-110> grep _end /usr/libdata/ldscripts/elf_x86_64_fbs=
d.x
>> ...
>>      _end.  Align after .bss to ensure correct alignment even if the
>>  _end =3D .; PROVIDE (end =3D .);
>> =

>> It used to be built into the a.out linker, but it's in the built-in link=
er =

>> scripts since the ELF switch.
>> =

>> Your problem isn't clang vs gcc or libc_p, it's /usr/local/bin/ld or a l=
inker =

>> 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=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 o=
n all platforms to help with the eventual demise of in-tree gcc...

Warner
_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[e-mail]"