[Fwd: Re: m4 from cvs, cygwin]

[Gary V. Vaughan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Charles Wilson wrote:
| Gary --
|
| I tried building CVS m4 again using autoconf-2.59, automake-1.7.9, and
| libtool-HEAD-20031111.

You may very well need to bootstrap libtool-HEAD with CVS automake, although
if you did so, it is a bug in m4 if automake-1.7.9 doesn't work.

| It didn't work.  I did bring in the most up-to-date version of
| libtool.m4, ltdl.h and ltdl.c (but adding lt_dlloader_find() , of course)

I will merge those changes back in to libtool before I release m4.

| ---------------
| When I configured using --enable-static --disable-shared:
|
| make install failed (actually, make install DESTDIR=...) because libtool
| was looking for m4.exe in .libs, even though for static builds, m4.exe
| is in the main builddir.
|
| Note that libtool is not confused about this point during "normal"
| builds.  I believe the problem is with dlpreopen or dlopen or somesuch.
|  It's a module thing.

Before I can release libtool-1.6, I want dlpreopening to work without .la
files.  It looks like cygwin is hit harder than most, but for this particular
case preloaded modules should "just work" when I have fixed that.

| ---------------
| When I configured using --disable-static --enable-shared:
|
| The build did not succeed.  Apparently my fix to the global symbols
| filter wasn't good enough.  It's picking up (allowing thru) a whole
| bunch of symbols that actually come from cygwin1.dll or crt1.o etc.
| Symbols like __DTOR_LIST__ __RUNTIME_PSEUDO_RELOC_LIST__
| ___w32_sharedptr _imp__m4_current_file etc.
|
| My fix worked in the testcase (mdemo) but...it still needs more work in
| this torture test.  [Later note:  on further investigation, it MAY be
| that somehow the old version of the export_symbols_cmds filter got used.
|  Because this behavior is exactly what I would've expected BEFORE my fix
| was applied)

Ugh.  I don't know the cygwin platform well enough to help you with this one,
but I will gladly apply any patches you find necessary.

| ---------------
| When I configured using --enable-static --enable-shared:
|
| build and install went okay.  But...
|
| m4.exe is intrinsically linked to m4-0.dll, traditional-0.dll, and
| gnu-0.dll, as well as to cygm4-0.dll.  But only cygm4-0.dll is installed
| in ${bindir} -- the others are in libexec/m4 -- which is not in PATH.

Argh!  That is definitely all wrong.  libtool is supposed to dlpreload all of
those modules without any dependency on the dlls.  Is libtool stupidly
preloading the import libs or something?  I have been concentrating on getting
libtool into the right shape to support the next release of m4 for a couple of
months, so I should look at this again in m4 incase some of the configury has
bit rotted.

| ---------------
|
| And now for the even less-fun part of the email.  I have some serious
| concerns about the direction you've been taking m4, and how that will
| impact the portability of the autotools in the future.
|
| <rant>
|
|   1) the autotools: most importantly autoconf, then automake, then
| libtool, are KEY portability tools, used to help insure that stuff will
| actually build on J-Q-random-platform.

Agreed.

|   2) autoconf depends on m4.

Autoconf also depends on itself.  It is configured with a configure.ac file.

|   3) m4 now depends on some of the most arcane, poorly supported, dusty
| corners of libtool.

Not true.  M4 depends on some of the newest, most poorly tested, fast changing
parts of libtool.

|   4) libtool depends on automake and autoconf
|
|   5) which depends on m4, which...

The Autoconf -> M4 -> Autoconf bootstrap dependency has been around forever.

| Do you see the problem here?  In the very near future, the autotools
| will CEASE TO WORK AT ALL on my platform -- because the new autoconf
| will require the new m4, and the new m4 DOES NOT WORK on cygwin.

I understand your frustration, and I am just as keen as you that autotools
(including m4) continue to be useful on your platform.  I have made a point of
statically linking all of the functionality from m4-1.4 into cvs m4, and
giving configure options to allow package builders on platforms with no
support for modules in libtool to specify additional modules to preload.  On
the other hand, I would also like to see better module support for all
platforms coalesce in libltdl, so that modules *can* be used more easily in a
portable fashion.

| Modules are the most underused and undertested part of
| libtool.  And now you are forcing autoconf to depend on a working
| implementation of libtool-modules.

No I'm not.  I'm forcing the next release of m4 to depend on the next release
of libtool-modules.  The concerns are similar, but autoconf can continue to
work with m4-1.4, or even a static m4-2.0 build for some time until the module
system crystallises.

I think m4 modules will make m4 a much more useful and powerful tool, and it
would be a shame to never allow them to be used incase it takes a bit of work
to get them working everywhere.  At some point in the future it would be great
to see chunks of Autoconf and Libtool coded in C as m4 modules.  But that is a
lofty goal for the distant future.  Before we can seriously aspire to that
kind of improvement, we need to find out how to get modules working at all.

I hope I've set your mind at ease a little.  libtool-1.6 (particularly
libltdl) is still a little way off, and m4-2.0 might even need to wait for
libtool-1.8 before it has widely supported modules that will be safe for
autoconf to start using.  Your concerns are valid, and I hope you will
continue to help me keep libtool, libltdl and m4 working on cygwin.

Cheers,
        Gary.
- --
~  ())_.  Gary V. Vaughan    gary@(lilith.warpmail.net|gnu.org)
~  ( '/   Research Scientist http://www.oranda.demon.co.uk       ,_())____
~  / )=   GNU Hacker         http://www.gnu.org/software/libtool  \'      `&
`(_~)_   Tech' Author       http://sources.redhat.com/autobook   =`---d__/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/u2riFRMICSmD1gYRAp24AKCaTMP+ThAi9zInW4zCN6pXchM4IACfUGTW
a9mDs43tW2LSedv2KoQ2XlY=
=Mari
-----END PGP SIGNATURE-----