-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/29/2014 at 10:49 AM, Reco wrote:
> Hi. > > On Mon, Sep 29, 2014 at 07:50:21AM -0400, The Wanderer wrote: >> On 09/29/2014 at 05:49 AM, Reco wrote: >>> What's wrong with the current multiarch implementation in your >>> option? I'm really curious as all multiarch complains I've >>> seen so far (barring actual package limits) were easily solved >>> just by reading an appropriate man page (or Debian wiki page). >>> >>> And, IMO, Debian's current multiarch is way more flexible than >>> current Fedora's one. >> >> I don't know about him, but although I'm a big supporter of >> multiarch in general, I do know of one major thing which broke >> with the transition from the old arrangement: x86 builds on >> amd64 hosts. >> >> Prior to multiarch, ia32-libs provided (most of) the x86 >> libraries, and ia32-libs-dev provided the matching header files. >> (Separate lib*32 packages provided other libraries, and matching >> -dev packages provided the matching header files for those other >> libraries.) With both of those together, and compiler options >> like 'gcc -m32', it was possible to compile code against 32-bit >> libraries in a 64-bit environment and then run the result in >> that same environment. >> >> Under multiarch, lib*:i386 packages provide the x86 libraries, >> and there is nothing which provides the matching header files. >> That sort of compilation task is no longer possible, at least not >> in a remotely trivial or automated fashion. > > Header files are arch-agnostic, it's the .la files that case all > the trouble. I'm afraid that's not always the case. I've encountered specific cases where the headers are different between architectures. > Still, you're raising a valid point - compiling for several arches > was possible before multiarch, and it's not possible now without > chroots. I prefer chroots for this (less strange dependencies in > the 'base' system), but YMMV. If I'm reading you right, "strange dependencies" only matter when you're going to install what you've compiled on a machine other than the one where the build was done. For the use case of test-building (and test-running, and in some cases installing and actively using) the upstream development tree, that doesn't particularly matter; there are exceptions, but for the most part, doing that type of build on a different machine from where the resulting binary will be used is pretty much unheard of. > About the only thing that I'm missing here is why would anyone > should compile anything on a production server, Xen's dom0 > specifically (as it seems to be the main lee's concern). I did say that I didn't think lee was referring to this same type of breakage. This was just an example of a "multiarch complaint" such as you said you had not seen so far; there's nothing saying it's the only such. - -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJUKXq3AAoJEASpNY00KDJrsIgP/1Rw4F1yf17n04XXSKwqfphv KMfgANZKQUD55ykm0jxYEfpXVVTaCCP1c+Y8wIrdqAwX7nIGrZX2I7jF4PmEDVG+ FQK1xvrz/uMYag0xDNUYxRmxMO7/gMQF5AXmfFbWNDdJ8/DqdCMw7ZMRi7Prt/Dc a22gjUA6K+CLsBqj78Xm7/3qzBihQ/wIJ+kfixTC260v7OKDA/Vmd1Kg+5JeANW6 VfaZKc8M7eXwtb9KD9n+woykPRw/FqTY4YeUCYmnoPUVFPV8avOUrMV8siW/p27c p8HOvyfRf+8lN90zBxSFupUb/6b69nLGsyslBA2pCoDhMWYlCbLch4FHxme2jQfp lFaDKyYe5o8KHDSaGRMT6ar/y/LFEDAq0Cmd+kqWQT/9dOuQTEH7WT5d5x0EcfgS EyPLC2JSkRK1PA8CR3m4woyvac34B66zjU3lBQWx7mNHjOC08l1HVhERmjT+r+Ws sd5crbxWLIe7tTOXtRVhURhJpfZTZYdS7PM4nzAeAKNAgtNVmWzUA2MrzybeY7qB gJJtOxiOKlX93aGCqymHh9744+XMmiKX2h3YqM6b7Bl/YHGZA71pBCsrAs+uzt5G TJSodZzThnFXtZSzqIUkitWmckSV4OSM6xE8X5SGPl/V1Lc/+8aTWznVcXT7h1hr odNsAzlCKqUCUT4QOx5o =ISaH -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54297ab7.90...@fastmail.fm
