Re: Configuring libtool HEAD branch.

[Gary V . Vaughan]

Hi Dan,

Don't forget to at least Cc: one of the lists... I might be struck by 
lightning before I get chance to reply ;-)

On Monday 16 April 2001 11:05 pm, address@hidden wrote:
> Yes I ran into this problem while trying to build libtool itself.
> Sorry about the confusion.
>
> Anyway, on a hunch I went to my patched (for AIX run time linking)
> source, and did a "make distclean" (Maybe this isn't the right
> command to clean things up totally).

`make maintainer-clean' is supposed to put the tree into the same state you 
would find a fresh checkout.  If it doesn't, then that is a bug.

> I noticed that there were still
> some files around that should be rebuilt from scratch, so I removed
> them by hand.

That is bad.  Do you still have them after a maintainer-clean? Which files?

> ./bootstrap
> ./configure
> make
>
> And now things look much better!!
>
> It looks like after doing a cvs update it is very important
> to carefully clean up everything before rebuilding.

Yes.  Especially in HEAD where it is possible to get into a make loop if the 
bootstrap script is not run after a Makefile.am update...

> Building the clean source directly from CVS also now gets by my problem.
> However, without my patch it soon fails in another way.
>
> AIX by default wants it's shared libraries called lib<name>.a.
> So libltdl.a is created (as a symlink to libltdl.so.3.0.0).
> The Makefile then wants to create a non-shared library also called
> libltdl.a. This predictably fails as follows:
> ar cru .libs/libltdl.a  ltdl.o
> ar: 0707-108 File .libs/libltdl.a is not an archive file.

AIX is fast catching Ultrix in my league table of `most gratuitously 
different Unix'...

> My changes get around this problem in two ways:
>
> - When building libtool with run-time-linking enabled, we no longer need
>   to name our shared libraries lib<name>.a.  lib<name>.so is used instead,
>   so the non-shared libltdl.a can be created without any collision.
>
> - When building libtool without run-time-linking, my changes do still
> create a lib<name>.a.  However, it is an actual archive containing the
> shared object (just like the quirky way the rest of AIX does it).
>   What you end up with is a libltdl.a that contains both the shared and the
>   non-shared object.  This is not really what was intended, and would
> likely cause problems if you ever really needed to use the non-shared
> object, but for the most part it seems to work.  The only other thing I can
> think to do is not bulid the non-shared object in this case.

Is this the best approach?  (I am not arguing that it isn't... I just want 
you to reassure me that having distinct linktime vs. runtime library names is 
more broken on AIX than what you have in your current patch).

> Anyway, thanks for your help.
>
> Do you think there is any chance of getting my AIX changes in?

Certainly.  Sooner, if you help me with a port to the multi-language-branch...
I won't try to evaluate and port it now, my brain functions better before 3am 
=)O|

> Dan McNichol

Cheers,
        Gary.

> > From: "Gary V. Vaughan" <address@hidden>
> > Reply-To: address@hidden
> > To: address@hidden, address@hidden
> > Subject: Re: Configuring libtool HEAD branch.
> > Date: Mon, 16 Apr 2001 20:18:16 +0100
> >
> > Hello again Dan,
> >
> > Okay seems might I got the wrong end of the stick -- I didn't realise
> > that you were referring to building libtool.  If you were talking about
> > your own project that is making use of libltdl, then one solution is for
> > you to add AC_LIB_LTDL to your configure.in, and copy ltdl.m4 to
> > acinclude.m4 and then rebootstrap your project.  If you were referring to
> > building libtool, then read on...
> >
> > On Friday 13 April 2001  4:50 pm, address@hidden wrote:
> > > So I have added the following to configure.in:
> > > AC_CHECK_FUNCS(memcpy bcopy, break)
> > >
> > > Now libltdl compiles much better.
> > >
> > > So is this a bug, or am I doing something to cause
> > > the entry in ltdl.m4 to be ignored?
> >
> > Seems like you might have a platform dependant bug... After a fresh
> > checkout, having run only the bootstrap script I have this:
> >
> >   address@hidden:~/devel/savannah/libtool > fgrep memcpy * libltdl/*
> > 2>/dev/null ChangeLog:      * ltdl.m4:  Check for memcpy, or else bcopy.
> >   ChangeLog:      (rpl_memcpy): A minimal fallback implementation.
> >   config.cache:ac_cv_func_memcpy=${ac_cv_func_memcpy=yes}
> >   ltdl.m4:AC_CHECK_FUNCS(memcpy bcopy, break)
> >   libltdl/acinclude.m4:AC_CHECK_FUNCS(memcpy bcopy, break)
> >   libltdl/aclocal.m4:AC_CHECK_FUNCS(memcpy bcopy, break)
> >   libltdl/config.h:/* Define if you have the memcpy function.  */
> >   libltdl/config.h.in:/* Define if you have the memcpy function.  */
> >   libltdl/config.log:configure:6399: checking for memcpy
> >   libltdl/configure:for ac_func in memcpy bcopy
> >   libltdl/ltdl.c:/* NOTE:  Neither bcopy nor the memcpy implementation
> > below can
> >   libltdl/ltdl.c:          do not rely on this behaviour when invoking
> > memcpy later.  */
> >   libltdl/ltdl.c:#    define memcpy(dest, src, size)      bcopy (src,
> > dest, size)
> >   libltdl/ltdl.c:#    define memcpy rpl_memcpy
> >   libltdl/ltdl.c:memcpy (dest, src, size)
> >   libltdl/ltdl.c:   memcpy (mem, ptr, size);
> >
> > In particular, notice that libltdl/configure contains `for ac_func in
> > memcpy bcopy', which is the shell code that performs the test.
> >
> > What do you have?
> >
> > > Dan
> >
> > Cheers,
> >     Gary.
> >
> > > > From: address@hidden
> > > > To: address@hidden, address@hidden
> > > > Subject: Re: Configuring libtool HEAD branch.
> > > >
> > > > I just sucked down a fresh copy of the HEAD branch from cvs.
> > > >
> > > > libtool/ltdl.m4 contains the following line:
> > > > AC_CHECK_FUNCS(memcpy bcopy, break)
> > > >
> > > > But there is nothing in libtool/configure.in nor
> > > > libtool/libltdl/configure.in.
> > > >
> > > > Dan
> > > >
> > > > > From: "Gary V. Vaughan" <address@hidden>
> > > > >
> > > > > On Wednesday 11 April 2001 11:03 pm, address@hidden wrote:
> > > > > > I am running into a small problem when using our native
> > > > > > compiler because HAVE_MEMCPY is not being set (or even
> > > > > > checked for).
> > > > >
> > > > > Do you have AC_CHECK_FUNCS(memcpy) in your configure.in?
> > > > >
> > > > > Cheers,
> > > > >       Gary.
-- 
  ___              _   ___   __              _         mailto: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc