[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: Re: m4 from cvs, cygwin]

From: Gary V. Vaughan
Subject: [Fwd: Re: m4 from cvs, cygwin]
Date: Wed, 19 Nov 2003 13:08:40 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925 Thunderbird/0.3

Hash: SHA1

Gary V. Vaughan wrote:
| | ---------------
| | 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.
| | ___w32_sharedptr _imp__m4_current_file etc.
| |
| | My fix worked in the testcase (mdemo) 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...

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

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.

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

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.

And never mind the non-deterministic testsuite behavior. :-P

| so I should look at this again in m4 incase some of the
| configury has
| bit rotted.

perhaps.  I think you're just finding the broken parts in libtool, not
in m4.  Or maybe '...and in m4.'

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

Okay, perhaps I should have said that autoconf USES m4.  Which means you
need a working m4 to use autoconf, in order to maintain 'Package X'.

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

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

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

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

*current* autoconf, true.  But not autoconf-2.60, as was made clear in
the autoconf-2.57g/2.58pre release announcement.

| or even a static m4-2.0 build for some time until the
| module
| system crystallises.

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

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

That's a roger.

| 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 ;)"

This made it sound like all of those releases were scheduled for
imminent release, given that (a) 2.58 was in -pre state as evidenced by
the release announcement itself, (b) automake-1.8 appeared to be banging
on the gate for release, given the "this is the last 1.7 release, etc
etc" tone of the automake mailing list, and (c) libtool-1.6 appeared
ready RSN since "I dunno, 1.6 is so close should we even bother to
release 1.5.1?  I know people want the 42,872 bugfixes that have
accumulated since April 14, 2003...but 1.6 will be ever so much better,
and most fixes have been going to HEAD and not 1.5-branch"

So, it looked to me like 2.58/1.8/1.6 were all due by early December, at
the latest.  And m4-2.0/ac-2.6 would follow within weeks.


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

I dunno.  I'm not using cygwin as much anymore -- mainly all I do with
it is maintain existing crap (hello, albatross).  I really use Linux
more these days...but doggone it, stuff that WAS working should STAY
working without herculean effort.

But, I suppose I'll stick with it for now...even tho I may be taking a
break for a month or two.

- --

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
- --
~  ())_.  Gary V. Vaughan    gary@(|
~  ( '/   Research Scientist       ,_())____
~  / )=   GNU Hacker  \'      `&
`(_~)_   Tech' Author   =`---d__/
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]