[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?



Am 16.04.2013 15:19, schrieb Wookey:
> +++ Игорь Пашев [2013-04-16 16:49 +0400]:
>> 2013/4/16 Neil Williams <codehelp@debian.org>:
>>> On Tue, 16 Apr 2013 16:11:24 +0400
>>>
>>
>>
>> So, is it important, that multiarch dirs go after crossdirs:
>> our @librarypaths = (DEFAULT_LIBRARY_PATH, @crosslibrarypaths);
>> ?
> 
> That's actually a rather problematic question because it's an awkward
> transition and we want to break as few things as possible during it.

No, it's not awkward, and it's not a transition.  The existing paths will still
be used at least for third party software for years.  So you should get
comfortable supporting a layout which supports both the existing layout and the
use of the target architecture installed by Multi-Arch:same packages of this
architecture.  Restricting the cross-compilers in some way is not an option.

> I believe the correct answer for now is to check multiarch paths,
> 'crossdirs' paths (if crossbuilding), and 'plain' paths. In that
> order. At some point in the future we can drop the 'crossdirs' paths
> as they will no longer be used. 

There is no need to remove the lookup to the crossdir paths.

Again, you are missing here the lookup for the non-default multilib paths.

> So in multiarch world crossbuilding is not special. You always look in
> 'multiarch dirs' (for the correct architecture) for the libraries.
> Until everything is multiarched you also want to look in the 'plain
> dirs' for backwards compatibility.
> 
> If you know you are crossbuilding you want to look in the appropriate
> dirs where cross libaries are installed. Unfortunately which those are
> depends on the mechanism you used to install them. If using
> dpkg/multiarch then they will be in the multiarch dirs, so the
> situation is as above (the same as native building). If using older
> tools (dpkg-cross, xapt, xdeb) then they will be in the 'dpkg-cross
> crossdirs' and you need to look in there too. As it will be possible
> (but not a good idea) to install both a foreign-arch multiarch -dev
> package (into multiarch dirs) and the corresponding foreign-arch
> dpkg-crossed package (into dpkg-cross crossdirs) at the same time,
> there is no such things as a 'perfect' correct path search order. But
> as we are moving away from the old crossdirs paths to the new
> multiarch paths, it is reasonable to declare that the multiarch paths
> should be treated preferntially, and thus searched first.

With this scenario you are restricting cross toolchains to targets which are
already in the Debian archive.  There is a use case for that, however it doesn't
help setting up a new architecture.  I think it's bad to leave the initial
bootstrap in the dark, and only present a target architecture after frickling
with the initial bits outside any archives.

> This is the 'wrinkles that still needed to be sorted out' for the
> multiarch -dev spec. https://wiki.ubuntu.com/MultiarchCross
> 
> Updating that doc (and the main multiarch spec) has been on my todo
> list for about a year.
> 
> I've been thinking that a 'crossbuilding sprint' would be a good idea
> for a while, to tie down the recommendations for -dev packages,
> in-archive cross-toolchains, multiarch perl and the 'arch-indepedent
> dep-stack interruption' problem, and other outstanding issues such as
> cross gobject-introspection. We've experimented on most of this in
> Ubuntu with armhf and arm64 so (a select few of us) have a reasonable
> idea of how it should work, but that knowledge now needs formalising
> and documenting, and outstanding questions need some discussion.
> Hopefully we can get this sorted by/at debconf. 

It's a good idea to have such a sprint about the cross-building itself.  But
issues pop up now for related things like buildd support, packaging support and
probably with archive maintenance.  Can we list the open issues and decisions to
be made and make sure that the affected people can be met at this sprint?

  Matthias


Reply to: