Patch to update libtool in GCC and Src trees

Tue May 15 07:09:00 GMT 2007

Alexandre Oliva wrote:
> One likely possibility is that the macro that first AC_REQUIREs the
> code that assigns to Xsed is inside a shell conditional statement.

Well, that seems /very/ likely: there are 15 configure.in's within 
newlib that have some variation of this:

if test "${use_libtool}" = "yes"; then
AC_LIBTOOL_WIN32_DLL
AM_PROG_LIBTOOL
fi

So, I ran an experiment.  I changed all of those to unconditionally call

LT_INIT([shared static win32-dll])

which is the official New Libtool Way (although AC_LIBTOOL_WIN32_DLL and 
AM_PROG_LIBTOOL still work, I figured while I was there...)

Because all of the relevant Makefile.am's do a little dance like this:

if USE_LIBTOOL
some_LTLIBRARIES = ...
else
some_LIBRARIES = ...
endif

it seemed that on those platforms where libtool shouldn't be used, it 
won't be.  However, with this change, even /those/ platforms will 
generate a libtool script and run the various configury tests required 
by libtool.  That may be a problem: newlib/configure.host has the 
following comment:

# 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.

But, I just wanted to run the experiment and provide a data point for 
consideration -- and, I'm not sure if that comment still applies, with 
the new libtool.  Which "executable tests" were problematic?

Perhaps someone knowledgeable about building newlib for embedded targets 
could try my recipe, below -- just for another data point?

=========================================
What I did:

(1) checkout newlib (or, on cygwin, the whole winsup+newlib)

(2) in toplevel:
       rm ltcf-*
       rm ltconfig
       rm libtool.m4
       rm ltmain.sh
       unpack Steve's libtool.tar.gz, available here:
http://sourceware.org/ml/binutils/2007-05/msg00109.html

(3) copy 'compile' from automake-1.9 into toplevel

(4) from the newlib/ directory:
       applied the attached patch, which modifies the 15 affected
       configure.in files

(5) from the newlib/ directory:
       rm -f ./libtool.m4

(6) from the newlib/ directory:
       ran the attached 'fixup-Makefile-am.sh' script, which
       changes the ACLOCAL_AMFLAGS in all 75 Makefile.am's at the
       top of each separately-configured subproject within newlib:
         before, each ACLOCAL_AMFLAGS contained the relative path
         to <toplevel>/newlib/.  The script modifies each of those
         to also include '-I <rel-path-to-toplevel>' so it can find
         the new libtool.m4 and friends.

(7) from the newlib/ directory:
       ran the attached 'run-aclocal.sh' script, which invokes
       aclocal with the correct -I flags for all 75 subprojects
       in newlib.  The -I flags are discovered by parsing the
       Makefile.am's as modified in step 6.  The effect of this
       script is invariably something really simple, like:
+m4_include([../../../../libtool.m4])
+m4_include([../../../../ltoptions.m4])
+m4_include([../../../../ltsugar.m4])
+m4_include([../../../../ltversion.m4])
  m4_include([../../../acinclude.m4])
-m4_include([../../../libtool.m4])
       or no change at all.

(8) from the newlib/ directory:
       ran the attached 'run-automake.sh' script, which simply
       executes 'automake --cygnus' in all 75 subprojects.

(9) from the newlib/ directory:
       ran the attached 'run-autoconf.sh' script...

(10)finally, in <toplevel>
       ran 'autoconf'

Steps 6 thru 9 were done with scripts because (a) they are just that 
mechanical, and (b) otherwise, I'd have to post a 4.5MB patch thanks to 
all the modified configure scripts.

On cygwin-native, using the src/ tree thus modified, I successfully 
built a new cygwin kernel with its internal newlib.  The build process 
did create about 8 libtool scripts -- which were never used; all objects 
were created by directly invoking the compiler.

On linux-native, using the src/ tree modified this way, I successfully 
built a shared newlib library, using (the new) libtool:

$ cd $BUILDDIR && find i686-pc-linux-gnu -name "*.so"
i686-pc-linux-gnu/newlib/.libs/libc.so
i686-pc-linux-gnu/newlib/.libs/libm.so
i686-pc-linux-gnu/newlib/iconvdata/.libs/EUC-JP.so
i686-pc-linux-gnu/newlib/libc/sys/linux/linuxthreads/.libs/libpthread.so
i686-pc-linux-gnu/newlib/libc/sys/linux/linuxthreads/.libs/libthread_db.so

=========================================
So, what does this tell us?

(1) the new libtool, with proper care, can be used to build a shared 
newlib on linux-native

(2) with the new libtool in place, it is possible to build newlib "sans 
libtool" on at least one other platform

=========================================
So, the problem boils down to two issues:

(1) Is it necessary to conditionally invoke LT_INIT or AM_PROG_LIBTOOL 
-- or can embedded targets deal with unconditionally invoking those 
macros?  IOW, does the configure.host warning:
# 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.
still apply?

If it is not necessary, and embedded targets can deal with it, and the 
configure.host warning no longer applies, then Steve can use the 
procedure outlined above and regenerate/extend his patch, and we're good 
to go.

(2) Otherwise: how can the auto* machinery be manipulated to 
conditionally invoke LT_INIT or AM_PROG_LIBTOOL, without experiencing 
the problems I described earlier:
http://www.cygwin.com/ml/newlib/2007/msg00523.html

--
Chuck

P.S. No changelog, because we're still just experimenting, here...
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: configureIN.patch
URL: <http://sourceware.org/pipermail/newlib/attachments/20070515/0347d9ea/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fixup-Makefile-am.sh
URL: <http://sourceware.org/pipermail/newlib/attachments/20070515/0347d9ea/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: run-aclocal.sh
URL: <http://sourceware.org/pipermail/newlib/attachments/20070515/0347d9ea/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: run-automake.sh
URL: <http://sourceware.org/pipermail/newlib/attachments/20070515/0347d9ea/attachment-0003.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: run-autoconf.sh
URL: <http://sourceware.org/pipermail/newlib/attachments/20070515/0347d9ea/attachment-0004.ksh>