On 08/31/2015 03:42 PM, Steven Chamberlain wrote:
> Hi,
>
> YunQiang Su wrote:
>> +ifeq ($(DEB_TARGET_ARCH_OS),kfreebsd)
>> : # multilib builds without b-d on gcc-multilib (used in
>> FLAGS_FOR_TARGET)
>> + ln -sf /usr/include/$(DEB_TARGET_MULTIARCH) $(builddir)/sys-include
>> +else
>> if [ -d /usr/include/$(DEB_TARGET_MULTIARCH)/asm ]; then \
>> mkdir -p $(builddir)/sys-include; \
>> ln -sf /usr/include/$(DEB_TARGET_MULTIARCH)/asm
>> $(builddir)/sys-include/asm; \
>> fi
>> +endif
>>
>>
>> Why not do the same things like Linux?
>> aka, only link the headers really needed.
>
> I tried this at first, but the list became quite long:
>
> : # multilib builds without b-d on gcc-multilib (used in
> FLAGS_FOR_TARGET)
> for d in asm machine machine-i386 x86 sys osreldate.h; do \
> if [ -e /usr/include/$(DEB_TARGET_MULTIARCH)/$$d ]; then \
> mkdir -p $(builddir)/sys-include; \
> ln -sf /usr/include/$(DEB_TARGET_MULTIARCH)/$$d
> $(builddir)/sys-include/$$d; \
> fi \
> done
>
> This seems fragile and it could break build when kernel headers are
> next updated.
>
> Having all of /usr/include/$(DEB_TARGET_MULTIARCH) in the include
> search path would be much simpler, and doesn't seem harmful to me; the
> include search path already includes /usr/include and *all* our kernel
> headers are located there.
>
>> +
>> +ifeq ($(DEB_TARGET_ARCH_OS),kfreebsd)
>> + : # multilib builds without b-d on gcc-multilib (used in
>> FLAGS_FOR_TARGET)
>> + ln -sf /usr/include/$(DEB_TARGET_MULTIARCH) $(builddir_jit)/sys-include
>> +endif
>> +
>
> I'm glad you asked about this, thanks.
>
> The comment is misleading here (copy+pasted from the other patch hunk),
> and I should remove it. This is not for multilib builds, but to build
> the native jit compiler after we have moved kernel headers to a
> multiarch path.
why is this needed for the jit build?
>> Build-deps on gcc-multilib should be a better choice.
>> You can link the needed headers in libc6-dev-{i386,amd64} multilib libraries.
>
> Maybe I don't understand fully, but I don't think multilib is as
> powerful as moving kernel headers into multiarch paths; and we may
> need to move our headers anyway.
>
> We'd like to be able to cross-build glibc next, for linux-amd64 target
> from a kfreebsd-amd64 build system (and then amd64<->arm and others).
> This requires linux-libc-dev:amd64 to be installable alongside
> kfreebsd-kernel-headers (because it is build-essential).
at least for stretch, I'd like to avoid any build dependencies on foreign
architectures, for both the native and the cross compiler. It's too new, not
yet completely supported.
this might be a long term goal, however for now I would prefer using the
standalone approach like done in cross-toolchain-base.
> Since many kernel headers have the same names, one (or both) packages
> need to move headers into multiarch paths.
>
>> I think making kfreebsd have the similar way to work should be ideal.
>
> Or rather, it seems ideal if someday linux kernel headers could move
> too, and eventually multilib would become obsolete?
I mentioned this to Aurelian too, but I think this would need testing first,
what it will break ... and my guess is that this will be a lot.
Matthias
