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.
> 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).
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?
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
