-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/29/2014 at 12:03 PM, Reco wrote:
> Hi. > > On Mon, Sep 29, 2014 at 11:28:55AM -0400, The Wanderer wrote: >>> 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. > > Hmm. Kernel headers come to mind, but for typical userspace > headers that's unusual. It's been long enough since I was working with this (due to the same lack of multiarch support for it) that I've forgotten the details of which libraries were involved, unfortunately. I think libjpeg was one of them, but I can't swear to that. >>> 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. > > Yup. That's my usual 'modus operandi' since I've learned how to > build a Debian package. Whereas I'd pretty much never consider building a .deb for an upstream-development-tree compile, rather than just 'update_vcs_command ; ./configure --options ; make ; make install'. The extra intermediary steps to get a functional debian/ directory in place in the VCS tree, and maintain it against changes in upstream code, just make any potential advantages not worth the trouble for potentially-frequent test builds, IMO. >> 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. > > On the contrary, it's a viable practice once you take into account > a simple fact - there's more than one processor architecture, and > sometimes you use several of them. > > For example, try compiling a kernel on ARM system. Try > cross-compiling the same kernel on a conventional x86 system. > Compare build times. Unless you have an Intel Atom instead of CPU > - cross-compilation wins. That's one of the exceptions I was talking about. It doesn't apply nearly as much in the x86 vs. amd64 case, however, which is the main one I was dealing with. (That case is also special in other ways, since it's one of the few where you can reliably expect to run the foreign-arch code directly on the host where you do the build.) - -- 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 iQIcBAEBCgAGBQJUKYorAAoJEASpNY00KDJrO1MP/RbhuTBdi360doHIvHl780DS wpr2rCQxO7gCas0HAa0LQUVaiXrF2snp3q6pPfP2x3qsLxZkBgaLSR3ghaCnZNlR ZWuWXF94JoGcBdGZI3/dAtQ4cpbXPqH39vh3cSAgAbMM6zaOE0wW2gAZlqyfuSNN CW7w1leEx/Kv3/DY3JollJOzta69wue4AUUqOHYNgjvqj3Rom3HTC2Ifq4BYj3xW 70lugxKY53R1pHWU/0uKeu4M47qLcbs09cyP0FPbUzSxITyLMy96Cob9mcx3lN4o ChJq+MKpJ0Rc2aE8Yx2kn9lR6BBAl3Wxh3SfNU/Ug6o8yYA6ap/gEcQvWYCA8is2 JwvUtc+uDHH7keeEvHhOs3cYBx5QzNh4ZtAv+M1TL8lIAW4chEsi3v0Lxq5mrDqG EwqkIGmOxUkYI5ZfdB9CQptzHBPzmohvec56yi3ZNAkfjqf8ZCoZ7uUY3Rc7M/7E Z19tIl7dvBbQX4Cuq6mt6pVBRib6JemRhjdxA2JilXV9KTg/5NEse6lsrvWHZC+q cjLMEloAJvGaazRy8XsBlLTPXBCFqrSegmf8n6JrhcxDqe7qDX7tpIPL98Rc0/Fe 0iTX2TeDISC2ZyC46RM0pR/k5Os+EAcmcKlmbe4ytuzEcMZpJNzRAoVfOrf9HUR2 SGMoYEPVHyxsdxkCURfC =J4e8 -----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/54298a2b.6010...@fastmail.fm
