Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <49E43EF2.9060302@rowe-clan.net>
Date: Tue, 14 Apr 2009 02:44:50 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Daniel.Pocock@barclayscapital.com
CC: tfheen@err.no, dev@apr.apache.org
Subject: Re: apr-1-config on mixed 32/64bit build server
References: 
 <B9AEC8265E202D4BA6540EA32F49579007DAFA4B@LDNPCMEU301VEUA.INTRANET.BARCAPINT.COM>
In-Reply-To: 
 <B9AEC8265E202D4BA6540EA32F49579007DAFA4B@LDNPCMEU301VEUA.INTRANET.BARCAPINT.COM>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Daniel.Pocock@barclayscapital.com wrote:
>  
> 
> 
>> | - the output of `apr-X-config --ld-flags' will always be .../lib or 
>> | .../lib64, depending on which version of apr-X-config was installed 
>> | most recently
>>
>> You should not add the -L path if it's part of the system 
>> search path as that'll confuse gcc in some cases.
> 
> In my case, apr is being installed to a non-standard location (under
> /opt) with some enterprise management tools (e.g. Ganglia).  Therefore,
> -L is required, and the gmond binaries (e.g. gmond) use the RPATH to
> find apr.

Only if apr-X-config hasn't been hacked, appropriately, to find the right
answer.

>> In Debian, if you want to build for another environment, use 
>> a chroot (or a VM).
> 
> What about the special case of creating 32 bit libs for an amd64
> install?  In this case, the 32 bit libs go under /usr/lib32 or something
> similar (opposite to Redhat, which puts the 64 bit libs under
> /usr/lib64)

And thus you understand why the apr project isn't seeking actively to
solve this.  Whichever answer we choose is wrong for another group of
folks, so it becomes your puzzle to solve for {insert distro here}