In my environments, I setup the compiler and CFLAGS before calling
configure w/ the right information to build 32, or 64 bit binaries.
Having configure try to guess and pass in additional values is a royal
pain.  Passing in --libdir=/usr/lib64 (or equiv) is really the right
answer.  There shouldn't be any MARK64 or similar checks in configure or
other components.  If they care about type sizes, then they should use
the size types, i.e. uint32 instead of "long", or they should check
sizes using the autoconf variables and adjust things based on that.

(One rare example.  There is a mips64 target that comes back 32-bit in
all of the tests.  If the system checks for "64" in the arch name it
WILL do the wrong thing.  It needs to look at type sizes to determine
what to do.  Most software gets this right.)

--Mark

Ralf S. Engelschall wrote:
> On Mon, Jun 25, 2007, Arkadiusz Miskiewicz wrote:
> 
>> On Monday 25 of June 2007, Andy Green wrote:
>>> Arkadiusz Miskiewicz wrote:
>>>>>   Log:
>>>>>     allow one to control/override the /usr/lib64 use via Autoconf option
>>>>>     --enable-build-lib64
>>>> Usually this is done by ./configure --libdir=/usr/lib64.
>>> Possibly I misunderstand, but is that true?  I believe --libdir just
>>> sets where make install is going to place built libraries,
>> Correct. --enable-build-lib64 sets MARK64=64 which is used somewhere so looks
>> like it's needed and --libdir=/usr/lib64 will not help here too much.
> 
> Set's the reason why I haven't nuked it at all. MARK64 is used for both
> extending LDFLAGS and for setting libdir. Nevertheless this is a cruel
> hack and hence I've added the --enable possibility to optionally at
> least be able to get rid of it at all.
> 
>                                        Ralf S. Engelschall
>                                        [EMAIL PROTECTED]
>                                        www.engelschall.com
> 
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org

______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org

Reply via email to