apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Pocock <dan...@pocock.com.au>
Subject Re: apr-1-config on mixed 32/64bit build server
Date Wed, 08 Apr 2009 21:44:53 GMT

> The only variation to gcc is the -64 flag - this should be transparent,
> you should have to do nothing special until you overload your box with
> multiple flavors.
>   
The real issue is not the -64 flag - that is usually added by the 
configure script that is calling apr-X-config anyway.  The real issues 
that arise:

- 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

- depending upon how fussy the packaging system is, it may not be 
thrilled about one package overwriting another package's files - RHEL 
hasn't complained about this, but maybe future versions will be more 
attentive to such issues

I'm not suggesting apr needs to implement something special for every 
weird setup.  Rather, it just needs a generalisation that can be applied 
in the most popular cases (probably RHEL and Debian).  Some possible 
solutions that I haven't completely thought through:

- make apr-X-config part of the noarch package (it is just a script 
anyway), and have a command line option for specifying architecture, 
e.g, on RHEL, I could do the following:

$host=x86_64-....
apr-2-config --host=$host --link-ld   # output: -L/usr/lib64 -lapr-2

$host=i386-....
apr-2-config --host=$host --link-ld   # output: -L/usr/lib -lapr-2

- alternatively, have different versions of apr-X-config, e.g. 
apr-2-config-x86_64 or apr-2-config-64; the end user would need to make 
sure that they invoked the right one

Regards,

Daniel

Mime
View raw message