Total confusion over toolchain/xdev behavior

[Warner Losh]

On Jul 8, 2014, at 3:52 PM, Warner Losh <imp at bsdimp.com> wrote:

> 
> On Jul 8, 2014, at 3:24 PM, Sean Bruno <sbruno at ignoranthack.me> wrote:
> 
>> On Tue, 2014-07-08 at 15:01 -0600, Warner Losh wrote:
>>> On Jul 8, 2014, at 2:27 PM, Sean Bruno <sbruno at ignoranthack.me> wrote:
>>> 
>>>> On Tue, 2014-07-08 at 21:02 +0200, Dimitry Andric wrote:
>>>>> On 08 Jul 2014, at 20:27, Dimitry Andric <dim at FreeBSD.org> wrote:
>>>>>> On 08 Jul 2014, at 20:05, Sean Bruno <sbruno at ignoranthack.me> wrote:
>>>>>> ...
>>>>>>> ===> lib/libproc (all)
>>>>>>> building static proc library
>>>>>>> ranlib -D libproc.a
>>>>>>> make[5]: /var/tmp/home/sbruno/fbsd_head/lib/libproc/.depend, 322:
>>>>>>> ignoring stale .depend for /var/tmp/mips_cc/usr/lib/libstdc++.a
>>>>>>> building shared library libproc.so.2
>>>>>>> /var/tmp/mips_cc/usr/bin/ld: cannot find -lsupc++
>>>>>>> *** Error code 1
>>>>>>> 
>>>>>>> Stop.
>>>>>>> make[5]: stopped in /home/sbruno/fbsd_head/lib/libproc
>>>>>>> *** Error code 1
>>>>>> 
>>>>>> Yes, libproc and it dependencies should be disabled when MK_CXX=no.  Alternatively, libproc's demangling support could be conditionally compiled out in that case.
>>>>> 
>>>>> Now with a suggested patch.
>>>>> 
>>>>> -Dimitry
>>>> 
>>>> 
>>>> Getting closer, now we're at the point where we have some kind of
>>>> path/permission failure:
>>>> 
>>>> dirty.ysv:~/fbsd_head % make xdev MAKEOBJDIRPREFIX=/var/tmp
>>>> DESTDIR=/var/tmp/mips_cc XDDESTDIR=/var/tmp/mips_cc XDEV=mips
>>>> XDEV_ARCH=mips WITHOUT_CLANG=t WITHOUT_CLANG_BOOTSTRAP=t WITH_GCC=t
>>>> WITH_GCC_BOOTSTRAP=t WITH_GNUCXX=t WITHOUT_CXX=t
>>>> 
>>>> ===> secure/lib/libssh (install)
>>>> sh /home/sbruno/fbsd_head/tools/install.sh -C -o root -g wheel -m 444
>>>> libssh.a /var/tmp/mips_cc/usr/lib/private
>>>> sh /home/sbruno/fbsd_head/tools/install.sh -s -o root -g wheel -m 444
>>>> libssh.so.5 /var/tmp/mips_cc/usr/lib/private
>>>> sh /home/sbruno/fbsd_head/tools/install.sh -l s
>>>> libssh.so.5 /var/tmp/mips_cc/usr/lib/private/libssh.so
>>>> ===> usr.bin/lex/lib (obj,depend,all,install)
>>>> sh /home/sbruno/fbsd_head/tools/install.sh -C -o root -g wheel -m 444
>>>> libln.a /var/tmp/mips_cc/usr/lib
>>>> /var/tmp/mips_cc/usr/lib/libl.a -> /var/tmp/mips_cc/usr/lib/libln.a
>>>> /var/tmp/mips_cc/usr/lib/libfl.a -> /var/tmp/mips_cc/usr/lib/libln.a
>>>> cd /var/tmp/mips_cc/usr/bin;  mkdir -p ../../../../usr/bin;  for i in *;
>>>> do  ln
>>>> -sf ../..//usr/mips-freebsd/usr/bin/$i  ../../../../usr/bin/mips-freebsd-$i;  ln -sf ../..//usr/mips-freebsd/usr/bin/$i  ../../../../usr/bin/mips-freebsd11.0-$i;  done
>>>> mkdir: ../../../../usr: Permission denied
>>> 
>>> Oh! I know that one…
>>> 
>>> That’s from _xi-links target (the last one!).  You can safely ignore it.
>>> 
>>> Something like the following would also eliminate the warning. Just not too sure about it.  You may also need to define WITH_INSTALL_AS_USER=t.
>>> 
>>> Warner
>>> 
>> Ah crap, is there were I need "XDTP" defined or something?
> 
> Maybe…  But it looks like it is still trying to do the links, so I must have messed up something in the patch…
> 
> And the links look kinda sketchy to me like it is reaching outside the /usr/mips-freebsd area directly into /usr/bin, which won’t matter for what you are trying to do…  You don’t need mips-freebsd-cc binaries in the chroot…  though you might want different symlinks from your chroot’s /usr/bin/cc to /usr/mips-freebsd-cc/usr/bin/cc, etc.
> 
> Warner

Try this instead:

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: xdev-links
Type: application/octet-stream
Size: 1083 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140708/82e8d455/attachment.obj>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140708/82e8d455/attachment.sig>