Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Subject: Re: -q64 flag - gets in the way
To: William A Rowe Jr <wrowe@rowe-clan.net>
Cc: APR Developer List <dev@apr.apache.org>
References: <22257ede-a86f-402b-8c02-86bd2e1042c3@felt.demon.nl>
 <CACsi253TyTea8=54C=98-Ht=-QMhrQWcZWYcwh4YrbQwfvy4EQ@mail.gmail.com>
 <CACsi250VPGqp-aSoBGy2wNcHw-EhKTg667=uAv1EqPuEmMpRYg@mail.gmail.com>
 <9eb215d5-690b-ca7c-1c7c-14698f615bca@felt.demon.nl>
 <7fa26ea4-fbdb-26a7-44c5-8dfb66268257@felt.demon.nl>
 <CACsi250+W0veCbo1NENgs82uR_KepmaScuqqB3RdumrffMmYqQ@mail.gmail.com>
 <125d75b1-4c99-3db8-6550-7780e6ee8a05@felt.demon.nl>
 <CACsi253pBa+cUzcM7X_VjzxDzeat0GcVUU5rZaQbWacQpKEPQQ@mail.gmail.com>
From: Michael <aixtools@felt.demon.nl>
Message-ID: <7fe543ab-dad4-d4e4-9f0e-1ea91d65ca7d@felt.demon.nl>
Date: Thu, 7 Dec 2017 17:18:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101
 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <CACsi253pBa+cUzcM7X_VjzxDzeat0GcVUU5rZaQbWacQpKEPQQ@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------EEDD0774CFD04FADDCBA3D17"
Content-Language: en-US
archived-at: Thu, 07 Dec 2017 16:19:02 -0000

This is a multi-part message in MIME format.
--------------EEDD0774CFD04FADDCBA3D17
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 06/12/2017 17:06, 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/
>
> So, that's one sort of workaround to your quandry. It's something we
> really didn't spend a lot of time designing around in 2001 and was left
> to individual distributors to solve as time went on.

I really do not like "lib|lib64" approaches - but if that is all there is:

Either package with -64 in the package name (and use, e.g, /opt/httpd64 
and /opt/httpd32 as prefixes,
then a "user" can set symbolic links - and - also only build against 
static apr and apr-util libraries.
Then they are not "installed" during run-time, only available on the 
packaging server.

When I get that far I'll let you know (if you are interested).

Michael


--------------EEDD0774CFD04FADDCBA3D17
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 06/12/2017 17:06, William A Rowe Jr
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CACsi253pBa+cUzcM7X_VjzxDzeat0GcVUU5rZaQbWacQpKEPQQ@mail.gmail.com">
      <pre wrap="">They trust the compiler to do the right things, so there is no special
sauce added to apr-config. Respective build flags land in
<i class="moz-txt-slash"><span class="moz-txt-tag">/</span>usr/lib/apr-1/build<span class="moz-txt-tag">/</span></i>
<i class="moz-txt-slash"><span class="moz-txt-tag">/</span>usr/lib64/apr-1/build<span class="moz-txt-tag">/</span></i>

So, that's one sort of workaround to your quandry. It's something we
really didn't spend a lot of time designing around in 2001 and was left
to individual distributors to solve as time went on.
</pre>
    </blockquote>
    <p><tt>I really do not like "lib|lib64" approaches - but if that is
        all there is:<br>
      </tt></p>
    <p><tt>Either package with -64 in the package name (and use, e.g,
        /opt/httpd64 and /opt/httpd32 as prefixes,<br>
        then a "user" can set symbolic links - and - also only build
        against static apr and apr-util libraries.<br>
        Then they are not "installed" during run-time, only available on
        the packaging server.</tt></p>
    <p><tt>When I get that far I'll let you know (if you are
        interested).</tt></p>
    <p><tt>Michael<br>
      </tt></p>
  </body>
</html>

--------------EEDD0774CFD04FADDCBA3D17--