Re: Patch to update libtool in GCC and Src trees

[libtool at cwilson dot fastmail dot fm]

On Fri, 11 May 2007 11:29:29 -0700 (PDT), "Steve Ellcey"
> Charles Wilson wrote:
> 
> > However: on other platforms (see src/newlib/configure.host: at present,
> > only linux native) newlib may in fact use libtool.  It doesn't appear
> > that any of Steve's patches address that:
> >
> >    (1) src/newlib/configure.in says "AC_CONFIG_AUX_DIR(..)" so
> >        newlib will see the "new" ltmain.sh
> >    (2) src/newlib/Makefile.am says "ACLOCAL_AMFLAGS = -I ." so
> >        aclocal will use newlib/libtool.m4, which is "old", and NOT
> >        the "new" src/libtool.m4 and the other .m4 friends.
>   .
>   .
> > Either way, Steve's existing patch needs to be extended to do
> > _something_ with newlib, and that means a few more days of shakedown so
> > the linux-native-newlib guys can test it.
> 
> Do you know who any of these linux-native-newlib folks are? 

Not personally, no. I just noticed the newlib/libtool.m4 file, and
tracked down the libtool usage in newlib/configure.host.  Closest I can
see is this:

http://cygwin.com/cgi-bin/cvsweb.cgi/src/newlib/ChangeLog?rev=1.204&content-type=text/x-cvsweb-markup&cvsroot=src
http://cygwin.com/cgi-bin/cvsweb.cgi/src/newlib/configure.host.diff?r1=1.14&r2=1.15&cvsroot=src&f=h

Which is when Thomas Fitzsimmons of Red Hat first added libtool support
to newlib.

> I am
> looking for some guidance on how the users of libtool in newlib would
> like to address this issue.  I am thinking that libtool.m4 should be
> removed from the newlib directory.  I don't know why newlib has its
> own copy of libtool anyway.

IM-VH-O, I'd agree.  The following is *completely* untested, but I think
if you:

(1) remove src/newlib/libtool.m4

(2) update src/newlib/Makefile.am, as:
-ACLOCAL_AMFLAGS = -I .
+ACLOCAL_AMFLAGS = -I .. -I .
so that the new libtool-related .m4 files in src/ can be located.

(3) regenerate all affected files under src/newlib.  I'm not sure what
the correct 'recipe' here is.  Your original message
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01498.html
suggested that in newlib the recipe should be 'aclocal;automake
-cygnus;autoconf'

The only question then, is: does the result actually work -- e.g. does
it break anything for "regular" newlib builds -- and in particular for
the libtool-enabled case in question:

----------- from src/newlib/configure.host -------------
# Verify if shared newlib support is allowed and set appropriate
variables
# We don't want to use libtool for platforms that we are not going to
# support shared libraries.  This is because it adds executable tests
which
# we don't want for most embedded platforms.
case "${host}" in
  i[34567]86-pc-linux-*)
    use_libtool=yes
    have_sys_mach_dir=yes
    stdio64_dir=stdio64
    oext=lo
    lpfx=
    aext=la ;;
  *) ;; #shared library not supported for ${host}
esac
----------- from src/newlib/configure.host -------------

I'll follow my own advice above, and give the result a try on native
cygwin just to sanity-check that the suggestion above doesn't break
"regular"(non-libtool) newlib builds, and report back later.  I may also
be able to attempt a standalone native linux build of newlib but that's
iffy.

--
Chuck

P.S. I'm sorry I didn't notice this issue until so late in the process,
but I'd like to join the others in thanking you for taking on this
arduous task.