[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: building libtool libraries for multiple ABIs

From: Tim Mooney
Subject: Re: building libtool libraries for multiple ABIs
Date: Thu, 29 Apr 2004 15:55:20 -0500 (CDT)

In regard to: Re: building libtool libraries for multiple ABIs, Albert Chin...:

>On Tue, Apr 27, 2004 at 04:58:54PM -0500, Tim Mooney wrote:
>> If you want to build and install a local package (take for example GSL,
>> the GNU Scientific Library) that builds a library via libtool, what are
>> people doing to have the library built for each ABI that a platform may
>> support?  Has anyone found a better method than configuring the package,
>> building and installing once, then reconfiguring with CFLAGS and LDFLAGS
>> set for a different ABI and overridding the library directory, and
>> building and installing again?  This can become a pretty tiresome
>> process, especially if you also package your local software (such as
>> with RPM) and install the package.
>> How are other people dealing with this issue?
>What other solution is there than rebuilding?

I haven't found one, but I was hoping someone else had.  I guess the
question I have is, "Is this something that some future version of libtool
should support naturally and automatically?".  Libtool is already building
two kinds of libraries (archive and shared) with two kinds of object files
(non-PIC and PIC) on platforms where those distinctions exist.  Should
another "factor" be added, so that libtool will (optionally) build those
two kinds of libraries for N (where N is commonly 2) kinds of ABIs, on a
platform that supports multiple ABIs?

> When we build software,
>we build most packages to a _separate_ directory. So, for GSL, we have
>something like /opt/libgsl13 and /opt/libgsl14. When we build 64-bit
>versions of these, we build as usual but set

Exactly what I figured I would have to do, but if (and it's a big if) it
were decided that libtool should support multiple ABIs, it would seem that
libtool could handle that bit automatically, and you could again go back
to a simple

        configure --prefix=/opt/libgsl14 --exec-prefix=/opt/libgsl14
        make install

Anyway, I appreciate your comments.  You've verified for me that there's
probably not some magically easy way to do this that I'm just not seeing.

Tim Mooney                              address@hidden
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

reply via email to

[Prev in Thread] Current Thread [Next in Thread]