Re: libtool RFE

[Bruce Korb]

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
_path_ names".

> > 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
way" note.

> 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 :-).