svn commit: r284898 - in head: . share/mk

[Adrian Chadd]

I'm actively ignoring in-tree gcc and working on making sure the
external toolchain and cross compiler stuff is working out okay.

I'd like to eventually deorbit gcc-4.2 for MIPS and use an external
toolchain (in this instance, gcc-4.9.x for now) for both building MIPS
and as the compiler that will run on MIPS. Once LLVM and
cross-compiling is .. better, we can use that.

(But really, I'd like to see everyone doing compiler hijinx to just
use the external toolchain support for testing out compilers. It'll
make new CPU/board bring-up much more attractive to companies. :)



-a


On 28 June 2015 at 02:48, Dimitry Andric <dim at freebsd.org> wrote:
> On 28 Jun 2015, at 10:57, Baptiste Daroussin <bapt at FreeBSD.org> wrote:
>>
>> On Sun, Jun 28, 2015 at 01:44:21AM -0700, NGie Cooper wrote:
>>> On Sun, Jun 28, 2015 at 12:49 AM, Baptiste Daroussin <bapt at freebsd.org> wrote:
>>> ...
>>>> Not at all I have this on a both where I haven't yet r284898 iirc it is like
>>>> this since the beginning I do not remember seeing those ld scripts with absolute
>>>> path.
>>>
>>> $ cat /usr/lib/libc.so
>>> /* $FreeBSD$ */
>>> GROUP ( /lib/libc.so.7 /usr/lib/libc_nonshared.a /usr/lib/libssp_nonshared.a )
>>> $ what -q /boot/GENERIC.r283337+9c333ed/kernel
>>> FreeBSD 11.0-CURRENT #4 r283337+9c333ed(isilon-atf): Tue May 26
>>> 21:49:09 PDT 2015
>>
>> Yes you are right, I was looking at the wrong place.
>
> What is actually the perceived problem with having paths in those linker
> scripts?  If you use --sysroot, the libraries are searched relative to
> that sysroot, right?
>
> (And yes, I know our gcc's sysroot implementation is broken.  So please
> fix that instead. :-)
>
> -Dimitry
>