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
