PATCH for libiberty when NOT using --enable-shared

[Manfred Hollstein]

On Wed, 20 May 1998, 08:51:17, law@hurl.cygnus.com wrote:

 > 
 >   In message < 13666.38256.637388.842113@slsvhmt >you write:
 >   > Jeff, the recent changes to libiberty introduced a default for
 >   > enable_shared which is different from what the toplevel scripts are
 >   > using.
 >   > 
 >   > If one omits --enable-shared, ${enable_shared}'s value is "" which is
 >   > then used by libiberty's config.table to say `OK, the user didn't
 >   > explicitly say "no", so we're going to build a shared lib'.
 >   > 
 >   > This small patch corrects it.
 > I don't think that's right -- look at the toplevel configure files,
 > they should have set enable_shared to "no" if no specification of
 > enable_shared was provided by the user.

I've actually looked at the toplevel files. configure doesn't do
anything, if no --enable-shared or --disable-shared is given.
Now the toplevel configure.in comes into play:

# We default to --with-shared on platforms where -fpic is meaningless.
# Well, we don't yet, but we will.
if false && [ "${host}" = "${target}" ] && [ x${enable_shared} = x ]; then
  case "${target}" in
    alpha*-dec-osf*)	enable_shared=yes ;;
    alpha*-*-linux*)	enable_shared=yes ;;
    mips-sgi-irix5*)	enable_shared=yes ;;
    *)			enable_shared=no ;;
  esac
fi

case "${enable_shared}" in
  yes) shared=yes ;;
  no) shared=no ;;
  "") shared=no ;;
  *) shared=yes ;;
esac

As you can see, in the last case statement ${enable_shared} is used,
without even being touched before, hence its value is undefined
( == "" ) and shared is set to "no"! This is what my patch does.

 > 
 > Something more subtle is going on.  I just haven't found it yet :-)
 > Jeff

I don't think it's subtle ;-)

manfred