Re: Challenge to you: Voice your concerns regarding systemd upstream
-----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-----
Reply to: