> "Nikita V. Youshchenko" <[EMAIL PROTECTED]> writes:
> >> > Dpkg-cross is a tool to create cross-compile environment, useful to
> >> > cross-compile debian packages and other software.
> >> > One of dpkg-cross's functions is to process a native library or
> >> > libdev package for some arch, and turn it into arch-all packages
> >> > that install libraries info /usr/$DEB_TARGET_GNU_ARCH)/lib/, and
> >> > headers info /usr/$(DEB_TARGET_GNU_ARCH)/include/. E.g. arm
> >> > cross-compile environment was created under /usr/arm-linux/. This
> >> > was consistent with cross-binutils and cross-gcc packages file
> >> > placement.
> >>
> >> That isn't where the multiarch proposals for Debian and FHS place
> >> files and I think it is best if you follow their lead. Use
> >>
> >> /usr/lib/$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)/
> >> /usr/include/$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)/
> >
> > Hmm...
> >
> > All cross toolchains I've seen up to today, both free and commercial,
> > use include/ and lib/ subdirectories of some prefix.
> >
> > Cross-ld from binutils use ${prefix}/${target}/lib these are the path
> > to search libraries.
> >
> > Cross-gcc also uses ${prefix}/${target}/include and
> > ${prefix}/${target}/lib.
> >
> > This is how things used to work for years.
> > There should be a very serious reason to change this.
>
> The multiarch and FHS proposals say that ${prefix}/${target}/* would
> pollute the / and /usr directories while the lib and include subdirs
> already have tons of files/dirs and the extra dirs won't matter.I think that following years-old de-facto standard of cross-compilation environment file placing outweights '/usr pollution' argument. So I think I will keep this as is in dpkg-cross. However, this may change if other arguments will appear in future. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
