Archive library breakage on standard UNIX systems with ranlib

2000-09-02 Thread Michael Sokolov

Hi there,

The current libtool, both -rHEAD and -rmulti-language-branch, ever since 1999-
10-01 in fact, causes catastrophic breakage on standard UNIX systems on which
archives created by ar MUST be ranlib'ed before ld can use them at all (at
least 4.0BSD through 4.3BSD, and lots of others I'm sure). I have traced the
breakage down to this change:

1999-10-01  Gary V. Vaughan  <[EMAIL PROTECTED]>

* configure.in (AC_OUTPUT_COMMANDS): generate ltmain.sh
* Makefile.am (ltmain.sh ltconfig): removed.  Automake inserts the 
rules to automatically call config.status.

* libtool.m4: be sure to AC_SUBST values no longer tested in
ltconfig.in.
* ltconfig.in: replaced several of the simple feature tests with

substitutions from config.status.
^
* Makefile.am (ltconfig): generate ltconfig with config.status.
* configure.in (AC_OUTPUT): generate ltconfig with config.status.

especially the highlighted part.

Before this change, ltconfig.in contained the following code:

  if test -n "$ac_cv_prog_RANLIB"; then
RANLIB="$ac_cv_prog_RANLIB"
old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib"
old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"
echo "$ac_t$RANLIB" 1>&6
  else
echo "$ac_t""no" 1>&6
  fi

Gary's change removed this code and switched to configure's standard ranlib
check. But this is more than just a standard configure check! See how it adds
ranlib commands to old_archive_cmds and old_postinstall_cmds. After Gary's
change old_archive_cmds and old_postinstall_cmds never contain ranlib commands.
As a result, the archive is built with ar but not ranlib'ed, causing
catastrophic breakage on all standard UNIX systems on which archives created by
ar must be ranlib'ed before ld can use them.

The breakage caused by this change currently exists on both -rHEAD and -rmulti-
language-branch and needs to be fixed in both places. However, I'm not sure
what's the right way to fix this in the current libtool given all the changes
since then. Can someone please fix this? TIA.

--
Michael Sokolov Harhan Engineering Laboratory
Public Service AgentInternational Free Computing Task Force
International Engineering and Science Task Force
615 N GOOD LATIMER EXPY STE #4
DALLAS TX 75204-5852 USA

Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: [EMAIL PROTECTED] (ARPA TCP/SMTP) (UUCP coming soon)

P.S. I don't subscribe to the libtool lists (only to the Cygnus tree ones), so
please Cc: me.




Re: Archive library breakage on standard UNIX systems with ranlib

2000-09-02 Thread Michael Sokolov

Alexandre Oliva <[EMAIL PROTECTED]> wrote:

> Please try the patch in the attached message.

I'm now building the tree with the current -rmulti-language-branch libtool with
this patch, and it already got past building libbfd.a and libopcodes.a and
linking some executables with them, so it looks good. Thanks!

--
Michael Sokolov Harhan Engineering Laboratory
Public Service AgentInternational Free Computing Task Force
International Engineering and Science Task Force
615 N GOOD LATIMER EXPY STE #4
DALLAS TX 75204-5852 USA

Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: [EMAIL PROTECTED] (ARPA TCP/SMTP) (UUCP coming soon)

P.S. Sorry for blowing my valve when I was first hit by the bug. It was just
extremely frustrating when I got up Friday morning (after starting a build
Thursday night) only to see it completely broken without an easy fix anywhere
in sight. Then while diagnosing it, in order to try out CVS libtool, which
comes without the generated files, I had to go through building and installing
perl and automake. After that several libtool builds followed by tree builds.
Ouch. I know that you are probably very spoiled by PCs and all that, but let me
just tell you that each tree build, even with a very stripped-down tree, is
several hours. Each configure run and such is anywhere from 15 to 45 minutes.
All in all this bug threw me back 48 hours.