[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool RFE
Re: libtool RFE
Wed, 12 Sep 2001 12:04:04 -0700
Guido Draheim wrote:
> address@hidden wrote:
> > On Tue, Sep 11, 2001 at 12:14:42PM -0700, Bruce Korb wrote:
> > > It seems I need to be able to build both 32 and 64 bit
> > > libraries. Since nobody seems to have anything to do,
> > > maybe we can add this to our copious spare time activities:
> > >
> > > Construction of multiple output libraries based on more
> > > than just the -PIC compiler flags. viz., the
> > > ``-xarch=v9 -xregs=no%appl,no%float'' variation on Sun.
> > >
> > > Since I have not taken a serious look at how you manage
> > > the build-with-PIC vs. build-without-PIC stuff, how hard
> > > would anyone guess it might be to put together a list
> > > of compile options and associated target library names,
> > > then going through all the compiles to build libraries
> > > one after the other? Can I do it over lunch? ;-)
> > > Probably not. :-(
> > What? Are you talking about building *both* 32 and 64-bit libraries at
> > once. How do you handle naming the library?
...mumble/libfoo.so === 32 bit version
...mumble/sparcv9/libfoo.so === 64 bit version
The Sparc linker understands this implicitly. Ick.
It's not my idea.
> > What directory do they get
> > installed in. For now, I say no. Build the 32-bit libs and install,
> > then the 64-bit libs and install (into separate locations). Are you
> > aware of any OS that supports 32 and 64-bit libraries in the same
> > directory? I know Solaris and AIX don't do this.
No, Solaris does not. I did not say they were in the same result directory.
I said they had different names. I should have said, "different
> > And, if you're going to *link* a program against the library you've
> > created, do you then generate both 32 and 64-bit versions as well?
If that is what you wanted to do. OTOH, if you have two programs
using the same library, one written to run as a 32 bit process
the other as a 64 bit one, ....
> I agree that libtool is probably not the right place for it
I am willing to accept that libtool may not be the right place,
but without a better suggestion ....
> [occasionally I wish]
> I can just `configure` once and have multiple variations of
> a library be made... The option that
> comes to my mind is the availability of a multilib subdir build
> of the project instead of the in-place build, so that a toplevel
> configure will always know to fork into two build-subdirs all by
> itself and let the makefile do the same. Since I've done this for
> my project with a handmade makefile/configure pair, I can assure
> you that it is possible.
I know it is possible. I am already doing that with hand
crafted make files myself. I noticed the issue when I discovered
I needed to link my AutoOpts library with a 32 bit program and
also a 64 bit program. My solution was to do a full build,
install, blow away the build dirs, reconfigure as a 64 bit build,
build and hand copy the desired library into the desired
destination. Then I wrote my cheeky, "there's gotta be a better
> For the question asked, it would simply
> fork into a 32bit and 64bit build-subdir, let `configure` create
> different makefiles with slightly different options to be passed
> to libtool, and then `make` each of them seperatly but in the same
> go and therefore possibly in parallel. And again - I've done this
> and it works, and I guess for quite a few platforms it would be
> great if the autotools could provide us with good support for it.
Yeah. There it is. That is a better articulation of what I
was asking for :-).