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