[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: m4 from cvs, cygwin
From: |
Gary V. Vaughan |
Subject: |
Re: m4 from cvs, cygwin |
Date: |
Wed, 19 Nov 2003 13:22:25 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925 Thunderbird/0.3 |
-----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-----
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: m4 from cvs, cygwin,
Gary V. Vaughan <=