Re: m4 from cvs, cygwin

[Gary V. Vaughan]

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

cwilson wrote:
| Gary V. Vaughan wrote:
|> | ---------------
|> | 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.
|
|
| I think I should probably try this again, once the libtool/ltdl inside
| m4 is more closely synced with the libtool installed on my box...

Just sychronised CVS HEADs of M4 and Libtool.

|> | ---------------
|> | 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?
|
|
| probably something like that.  There is no testcase in libtool that
| explicitly tests preloading.  But...

I ought to try and add one in my copious spare time. :-/

| If you configure "--enable-shared --disable-static", but dlpreload
| certain libraries, is libtool supposed to magically figure out that
| THOSE libraries should really be built static [and NOT dynamic?] and
| link against the static libs, but all the OTHER libraries should be
| dynamic only and NOT static?  If not, then in this case you'd still have
| dll linkage.

Ah-hah!  Quite right, I think you have it.  I'll look into this presently.
My guess is that the --disable-static to configure should be ignored by
libtool when it is building preloaded libraries... if it were only that easy :-/

|>  I have been concentrating on getting
|> libtool into the right shape to support the next release of m4 for a
|> couple of
|> months,
|
| which explains my nervousness -- as you don't have a cygwin machine
| anymore.  And I don't know of anybody but me who would ever just
| randomly "build the CVS libtool on cygwin and run the testsuite".  And
| since the testsuite doesn't seem to test the same stuff that m4
| exercises...

I do have an old PC laying around which I could install cygwin to if it
becomes an issue.  I do hope there are more people than we two that care about
libtool working on cygwin enough to at least test the alpha releases?

| And worse, it takes over 8 hours to run the testsuite as is on my
| machine -- assuming I'm there to dismiss the 'dll not found' WinPopUps
| that occur, by design, at several points during the test.  Thanks to
| Bill Gate's braindeadness, the testsuite is NOT an automated thing on
| Windows. Blech.

Ah yes, how I remember those heady days :-)

|> |   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.
|
| Not really much consolation, there...

I meant that they are the bits I'm working on, not the bits I've forgotten
about.  That should be some consolation!

|> |   4) libtool depends on automake and autoconf
|> |
|> |   5) which depends on m4, which...
|>
|> The Autoconf -> M4 -> Autoconf bootstrap dependency has been around
|> forever.
|
|
| Again, I used the wrong word.  What I really meant was not "dependency"
| exactly -- although it applies to a certain extent.  What I should have
| said was that effective use of libtool (when maintaining package X)
| typically requires that automake be used as well -- and always requires
| that autoconf be used.

But mandating m4-2.0 is some way off.  And I am sure there will be some
interrim where having m4-2.x will have advantages, but m4-1.4 will still be
sufficient...

|> | 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.
|
|
| Which assumes that preloading works.  Apparently it doesn't on cygwin.

Yet :-)

| If static libtool-module builds work.  Which they don't, at least as
| exercised in CVS m4, on cygwin.  Strangely, test/mdemo-static passes
| with flying colors...

I think the libtool testsuite is deficient.  I have been tidying it up to make
adding new cases less of a pain.

|> 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.
|
|
| Now THERE's a "why" I can support.

Phew!  :-)

|> I hope I've set your mind at ease a little.  libtool-1.6 (particularly
|> libltdl) is still a little way off,
|
| What got my panties in a twist was the phrasing of the
| autoconf-2.57g/2.58pre release announcement:
|
|   "This is our candidate release for Autoconf 2.58.  We plan to release
| it soon, so that Automake 1.8 can be released, hence Libtool 1.6, so
| that GNU M4 2.0 can be shipped, enabling Autoconf 2.60 ;)"

Note the smiley!

| P.S. Where is all of the coordination between the autotools discussed?
|  I monitor the autoconf-* automake-* and libtool-* lists, but some of
| the posts (by Akim, yourself, and others) make it clear that there is
| some other information channel being used for planning and long-range
| design.

Not that I'm aware of.  I guess some of the maintainers may discuss things
face to face at times, but everything I participate in happens on the lists.
Even this discussion (eventually!) :-b

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/u26RFRMICSmD1gYRAsI/AKDH4z7VSQ16sFyJo+OpMA1DicUDtACgz6zb
VggDn9p0k3Li0rIxgCJWefw=
=/ytU
-----END PGP SIGNATURE-----