apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: -q64 flag - gets in the way
Date Sat, 09 Dec 2017 12:39:57 GMT
On 08.12.2017 19:32, William A Rowe Jr wrote:
> On Fri, Dec 8, 2017 at 5:49 AM, Branko ─îibej <brane@apache.org> wrote:
>> On 08.12.2017 12:35, Joe Orton wrote:
>>> On Wed, Dec 06, 2017 at 10:06:22AM -0600, William A Rowe Jr wrote:
>>>> They trust the compiler to do the right things, so there is no special
>>>> sauce added to apr-config. Respective build flags land in
>>>> /usr/lib/apr-1/build/
>>>> /usr/lib64/apr-1/build/
>>> We do have to hack /usr/bin/apr-1-config to do:
>>> CPPFLAGS=`pkg-config --variable=CPPFLAGS apr-1`
>>> because that file has to be identical across both 32- and 64-bit builds.
>>> Otherwise we get RPM file conflicts when trying to install both i686 and
>>> x86_64 apr-devel at the same time.
>>> Because there is no way to actually thread the choice of arch through
>>> pkg-config and the myriad /usr/bin/*-config files, this stuff is a gross
>>> hack, isn't really widely used in practice, and I don't see much point
>>> in trying to solve "properly".  It's quite likely 32-bit arches will all
>>> be dead by the time we managed it :)
> Considering I might have parallel libs for Intel and ARM and Power
> at this point, lib/ and lib64/ is sort of an underwhelming hack. But
> the autogunk arch cross-compile model for lib/ is helpful.
>> Ooh, I'm getting a 64-bit RPi? Sounds fabulous. :)
> If you gain a RPi 3, you have one. You're just probably running a
> 32-bit OS... unless you want to spin up a 64-bit kernel for ARMv8.
> With 1GB and limited 'disk', I'd avoid spinning a dual-arch kernel.
> How 32 vs 64 libs are managed is an architecture choice, Michael
> would probably want to follow IBM's example in the case of AIX.

Ack to all of the above. I've been thinking about how to solve this
problem in generic APR; but I've come to the conclusion that there's
simply no sane way to do that for all supported platforms. The best we
can do is try to make the platform/arch/cross combinations build and
work (patches welcome); packaging and deployment are somebody else's

My rather facetious point was that 32-bit architectures are not at all
likely to go away soon ... IoT will be chock-full of them and I bet
they'll all need an HTTP server. After all, it's essential that the "70%
done" event from the toaster can start the coffee machine's morning shot
workflow and that it's all controlled in a ReSTful way by the app on the
smart watch. Breakfast should be ready when the alarm rings, not 10
minutes later, eh.

-- Brane

View raw message