RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD

RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD

[Richard Campbell]

bash-2.05b$ autoreconf --install --force
configure.ac:248: warning: AC_CANONICAL_HOST invoked multiple times
autoconf/specific.m4:363: AC_CYGWIN is expanded from...
configure.ac:248: the top level
autoheader: WARNING: Using auxiliary files such as `acconfig.h',
`config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for
`config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader: 
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template
without
autoheader: WARNING: `acconfig.h':
autoheader: 
autoheader: WARNING:   AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader:             [Define if a function `main' is needed.])
autoheader: 
autoheader: WARNING: More sophisticated templates can also be produced, see
the
autoheader: WARNING: documentation.
configure.in:54: error: possibly undefined macro: AC_PROG_CC_GNU
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:65: error: possibly undefined macro: AC_PROG_CC_G
configure.in:198: error: do not use LIBOBJS directly, use AC_LIBOBJ (see
section `AC_LIBOBJ vs LIBOBJS'
configure.in:310: error: possibly undefined macro: AC_PROG_CC_WORKS
autoreconf: /usr/autotool/devel/bin/autoconf failed with exit status: 1

bash-2.05b$ autoreconf --version
autoreconf (GNU Autoconf) 2.59

libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault

[Brian Ford]

Charles Wilson,

Could you look at the problem discovered in the thread below and give us a
comment?  Thanks.

http://www.cygwin.com/ml/cygwin-xfree/2003-12/msg00053.html

I'm not an autotool expert, but:

On Thu, 4 Dec 2003, Richard Campbell wrote:

> bash-2.05b$ autoreconf --install --force

These are just warnings, so I think this part worked fine.  I guess the
ddd people should clean these up?

> configure.ac:248: warning: AC_CANONICAL_HOST invoked multiple times
> autoconf/specific.m4:363: AC_CYGWIN is expanded from...
> configure.ac:248: the top level
> autoheader: WARNING: Using auxiliary files such as `acconfig.h',
> `config.h.bot'
> autoheader: WARNING: and `config.h.top', to define templates for
> `config.h.in'
> autoheader: WARNING: is deprecated and discouraged.
> autoheader:
> autoheader: WARNING: Using the third argument of `AC_DEFINE' and
> autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template
> without
> autoheader: WARNING: `acconfig.h':
> autoheader:
> autoheader: WARNING:   AC_DEFINE([NEED_FUNC_MAIN], 1,
> autoheader:             [Define if a function `main' is needed.])
> autoheader:
> autoheader: WARNING: More sophisticated templates can also be produced, see
> the
> autoheader: WARNING: documentation.
>
Here is where we should have stopped, although I don't know how to do
that with autoreconf.  The following are errors from subdirectories that
use older (circa 2.13) autoconf scripts.  autoreconf does not support
mixed versions, I guess?

> configure.in:54: error: possibly undefined macro: AC_PROG_CC_GNU
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
> configure.in:65: error: possibly undefined macro: AC_PROG_CC_G
> configure.in:198: error: do not use LIBOBJS directly, use AC_LIBOBJ (see
> section `AC_LIBOBJ vs LIBOBJS'
> configure.in:310: error: possibly undefined macro: AC_PROG_CC_WORKS
> autoreconf: /usr/autotool/devel/bin/autoconf failed with exit status: 1
>
So, if this hasn't left your tree broken, I think it would test what I
wanted.  You should now have libtool 1.5 for the main ddd tree.  I think
it would fix this.

New in 1.5: 2002-04-14; CVS version 1.4e, Libtool team:
* Support auto-import patch to binutils on cygwin for much improved dll
  support.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

Re: libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault

[Charles Wilson]

Brian Ford wrote:
> Charles Wilson,
> 
> Could you look at the problem discovered in the thread below and give us a
> comment?  Thanks.
> 
> http://www.cygwin.com/ml/cygwin-xfree/2003-12/msg00053.html

There are a couple of problems.

   1) OOB, DDD uses libtool-1.4.2 -- which has very minimal support for 
cygwin.  It works (barely) -- and it takes a whole chapter in the 
autobook http://sources.redhat.com/autobook/ to explain the differences 
from "normal" unix shared lib creation.  The new 1.5+ procedure (with 
binutils/gcc autoimport, autoexport, and .dll.a naming convention 
support) is much more unix-like.  Although ltmodules don't seem to work 
very well, except in toy cases. :-(

   2) Old libtool, when it finds a .la file (which specifies the DLL 
name and the static lib name, AND the import lib name) doesn't appear to 
handle the implib properly -- it thinks that it does not exist, and 
attempts to recreate it from scratch using the export table from the 
DLL.  But it uses old, buggy, obsolete, unmaintained, code to do so.

Now, there are only four libraries in your link list that have .la 
files: expat, fontconfig, freetype, and Xm.  And whaddaya know -- those 
are precisely the libs that cause problems in your link command.

QuickNDirty answer: hide those four .la files and re-run configure.

Long answer: update to the most recent autotools (relibtoolize). 
However....

>>bash-2.05b$ autoreconf --install --force
> 
> 
> These are just warnings, so I think this part worked fine.  I guess the
> ddd people should clean these up?
>

Yes, they should -- when they are ready to move to autoconf-2.5x, 
automake-1.7.x, and libtool-1.5+.  But as you can see, there are 
incompatibilities between autoconf-2.13 and -2.5x.  Basically, you CAN 
write a configure.in file that works with both -- but 2.13 was much more 
forgiving than 2.5x, so most existing configure.in's need to be brought 
up to 'spec' in order to work with 2.5x.

And the _easiest_ way to do THAT is to make changes to the configure.in 
that are NOT backwards compatible with 2.13!  So, it's possible to allow 
both versions to work with your configure.in, but much harder than just 
upgrading in a non-backwards-compatible way.

So most projects (like gcc/binutils until recently) have taken a 
wait-and-see approach to autoconf-2.5x.  Which leaves us poor cygwin 
folks, who NEED libtool-1.5 for decent DLL support, out in the cold -- 
because libtool-1.5 requires automake-1.7.x which requires autoconf-2.5x...

(And, even though it is conceivable to use ac-2.5x with old-style 
automake-1.4p6, the cygwin wrapper system doesn't let you do that.  So, 
if you re-autoconf with ac-2.5x, you'll also need to re-automake with 
am-1.[67].x -- which brings its own share of possible incompatibilities 
in the Makefile.am's.  And you'll want to add -no-undefined to the 
libXXXXX_LDFLAGS setting for any libraries that DDD builds)

>>configure.ac:248: warning: AC_CANONICAL_HOST invoked multiple times
>>autoconf/specific.m4:363: AC_CYGWIN is expanded from...
>>configure.ac:248: the top level
>>autoheader: WARNING: Using auxiliary files such as `acconfig.h',
>>`config.h.bot'
>>autoheader: WARNING: and `config.h.top', to define templates for
>>`config.h.in'
>>autoheader: WARNING: is deprecated and discouraged.
>>autoheader:
>>autoheader: WARNING: Using the third argument of `AC_DEFINE' and
>>autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template
>>without
>>autoheader: WARNING: `acconfig.h':
>>autoheader:
>>autoheader: WARNING:   AC_DEFINE([NEED_FUNC_MAIN], 1,
>>autoheader:             [Define if a function `main' is needed.])
>>autoheader:
>>autoheader: WARNING: More sophisticated templates can also be produced, see
>>the
>>autoheader: WARNING: documentation.

Yep, you're gonna have to take care of this stuff by hand.  I believe 
that support for config.h.top etc will be going away in autoconf-2.60, 
but that's **just** a guess.  And anyway, 2.60 isn't expected for at 
least several months (and 2.59 won't go 'poof' then, anyway)

> Here is where we should have stopped, although I don't know how to do
> that with autoreconf.  The following are errors from subdirectories that
> use older (circa 2.13) autoconf scripts.  autoreconf does not support
> mixed versions, I guess?

No, not at all.  That's why Zack Weinberg (Nathaniel Nerode?) over on 
the gcc list are updating gcc's (and friends') configure.in's by hand, 
one directory at a time.

Bringing the autotool infrastructure up to snuff for a large project, 
like DDD, is a significant challenge.  And it's not a job that anyone 
really wants to do -- so if you've the itch, the only person who will 
scratch it is you.  You'll need to do all this work yourself, and then 
send your patches back to the DDD developers as a fait accompli, and 
HOPE that they are ready to 'take the plunge', accept your patch, and 
**force all of their developers to switch to using the new autotools**.

It's that last bit that causes trouble.  And until they accept the 
patches and take the plunge, you'll have to maintain your changes 
out-of-baseline.  And keep reapplying-and-reautotooling each time you 
update to a new version of DDD.

One thing to keep in mind: when doing this, it helps to keep your 
patches in separate 'piles'.  I usually keep a 'pre-autotool' set, which 
are the changes to configure.in, Makefile.am's, acinclude.m4's, etc. 
Then, there's the 'post-autotool' set, which are the changes to those 
files which are automagically updated by re-running 
autoconf/automake/libtoolize (I usually include a 'bootstrap' script as 
part of my 'pre-autotool' pile-o-patches [*]).  Then, there's the 'code' 
set (changes to actual code), and the 'cygwin-packinging' set (stuff 
that goes in <srcdir>/CYGWIN-PATCHES/ like cyg-specific README, .hint, 
postinstall script, etc -- that the upstream maintainers would NEVER be 
interested in.)

[*] When actually releasing the cygwin package, there are two ways to do 
this.  The first way is to combine all four piles into one mondo patch, 
and ship it as "the" patch for the package.  (patchutils is your 
friend).  The downside is, often these patches are > 3M uncompressed, 
thanks to the MASSIVE changes to the configure script, the 
Makefile.in's, etc -- IOW, the 'post-autotool' pile-o-patches.  The 
second way is to only ship the pre-autotool, code, and cygwin-packaging 
piles as the 'mondo' patch, and then adapt cygwin's 
generic-packaging-script to run bootstrap as part of it's prep() phase. 
  This way, the patch is much smaller -- AND it's easier for you to 
maintain.  The downside is that (a) if anybody else wants to build your 
version of the package, they must have the autotools installed, (b) 
building is slow, because you have to run bootstrap each time [twice! -- 
again during mkpatch() for reasons I won't go into here -- if you're 
interested, I can send one of my old packages where I had to do this, 
and you can see how I did it and why.  None of my current packages on 
sourceware need to do this anymore...yay me.]

It's a royal pain...but there's no other choice, if (a) your-fav-pkg 
won't compile properly on cygwin without modern autotool support, (b) 
the upstream maintainers are unable/unwilling/properly-cautious to 'take 
the plunge' and refuse to integrate your patches for a few release cycles.

>>configure.in:54: error: possibly undefined macro: AC_PROG_CC_GNU
>>      If this token and others are legitimate, please use m4_pattern_allow.
>>      See the Autoconf documentation.
>>configure.in:65: error: possibly undefined macro: AC_PROG_CC_G
>>configure.in:198: error: do not use LIBOBJS directly, use AC_LIBOBJ (see
>>section `AC_LIBOBJ vs LIBOBJS'
>>configure.in:310: error: possibly undefined macro: AC_PROG_CC_WORKS
>>autoreconf: /usr/autotool/devel/bin/autoconf failed with exit status: 1
>>
> 
> So, if this hasn't left your tree broken, I think it would test what I
> wanted.  You should now have libtool 1.5 for the main ddd tree.  I think
> it would fix this.

But if the subtrees are configured separately AND the subtrees use 
libtool, then each subtree will create its own libtool during its own 
sub-configure step -- and you're back to the mixed-version problem 
again.  Blech.

> New in 1.5: 2002-04-14; CVS version 1.4e, Libtool team:
> * Support auto-import patch to binutils on cygwin for much improved dll
>   support.

Yep.

--
Chuck

Re: libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault

[Arnaud Desitter]

Hi,

Points taken. ddd requires autoconf 2.5x. It may well be that more work
is needed in the configure machinery to make it work with the most recent
versions of the autotools. Patches are welcome. For instance,
ddd/acconfig.h should be converted. Again any help is welcome.
An additional problem is that libiberty is bundled but has not been
converted yet to autoconf 2.5x. This causes problems but there is not
much we can do at the moment (except not using it in the first place).

The ddd cvs repository lives at http://sourceforge.net/projects/ddd/.
Patches posted at ddd@gnu.org will be considered.

Best regards,


----- Original Message ----- 
From: "Charles Wilson" <cygwin@cwilson.fastmail.fm>
Newsgroups:
gmane.os.cygwin,gmane.os.cygwin.xfree,gmane.comp.debugging.ddd.bugs
Cc: <bug-ddd@gnu.org>; <cygwin@cygwin.com>
Sent: Friday, December 05, 2003 3:13 AM
Subject: Re: libtool created import libs broken? was RE: DDD 3.3.8
(i686-pc-cygwin) gets `Segmentation fault


> Brian Ford wrote:
> > Charles Wilson,
> >
> > Could you look at the problem discovered in the thread below and give us
a
> > comment?  Thanks.
> >
> > http://www.cygwin.com/ml/cygwin-xfree/2003-12/msg00053.html
>
> There are a couple of problems.
>
>    1) OOB, DDD uses libtool-1.4.2 -- which has very minimal support for
> cygwin.  It works (barely) -- and it takes a whole chapter in the
> autobook http://sources.redhat.com/autobook/ to explain the differences
> from "normal" unix shared lib creation.  The new 1.5+ procedure (with
> binutils/gcc autoimport, autoexport, and .dll.a naming convention
> support) is much more unix-like.  Although ltmodules don't seem to work
> very well, except in toy cases. :-(
>
>    2) Old libtool, when it finds a .la file (which specifies the DLL
> name and the static lib name, AND the import lib name) doesn't appear to
> handle the implib properly -- it thinks that it does not exist, and
> attempts to recreate it from scratch using the export table from the
> DLL.  But it uses old, buggy, obsolete, unmaintained, code to do so.
>
> Now, there are only four libraries in your link list that have .la
> files: expat, fontconfig, freetype, and Xm.  And whaddaya know -- those
> are precisely the libs that cause problems in your link command.
>
> QuickNDirty answer: hide those four .la files and re-run configure.
>
> Long answer: update to the most recent autotools (relibtoolize).
> However....
>
> >>bash-2.05b$ autoreconf --install --force
> >
> >
> > These are just warnings, so I think this part worked fine.  I guess the
> > ddd people should clean these up?
> >
>
> Yes, they should -- when they are ready to move to autoconf-2.5x,
> automake-1.7.x, and libtool-1.5+.  But as you can see, there are
> incompatibilities between autoconf-2.13 and -2.5x.  Basically, you CAN
> write a configure.in file that works with both -- but 2.13 was much more
> forgiving than 2.5x, so most existing configure.in's need to be brought
> up to 'spec' in order to work with 2.5x.
>
> And the _easiest_ way to do THAT is to make changes to the configure.in
> that are NOT backwards compatible with 2.13!  So, it's possible to allow
> both versions to work with your configure.in, but much harder than just
> upgrading in a non-backwards-compatible way.
>
> So most projects (like gcc/binutils until recently) have taken a
> wait-and-see approach to autoconf-2.5x.  Which leaves us poor cygwin
> folks, who NEED libtool-1.5 for decent DLL support, out in the cold -- 
> because libtool-1.5 requires automake-1.7.x which requires
autoconf-2.5x...
>
> (And, even though it is conceivable to use ac-2.5x with old-style
> automake-1.4p6, the cygwin wrapper system doesn't let you do that.  So,
> if you re-autoconf with ac-2.5x, you'll also need to re-automake with
> am-1.[67].x -- which brings its own share of possible incompatibilities
> in the Makefile.am's.  And you'll want to add -no-undefined to the
> libXXXXX_LDFLAGS setting for any libraries that DDD builds)
>
> >>configure.ac:248: warning: AC_CANONICAL_HOST invoked multiple times
> >>autoconf/specific.m4:363: AC_CYGWIN is expanded from...
> >>configure.ac:248: the top level
> >>autoheader: WARNING: Using auxiliary files such as `acconfig.h',
> >>`config.h.bot'
> >>autoheader: WARNING: and `config.h.top', to define templates for
> >>`config.h.in'
> >>autoheader: WARNING: is deprecated and discouraged.
> >>autoheader:
> >>autoheader: WARNING: Using the third argument of `AC_DEFINE' and
> >>autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template
> >>without
> >>autoheader: WARNING: `acconfig.h':
> >>autoheader:
> >>autoheader: WARNING:   AC_DEFINE([NEED_FUNC_MAIN], 1,
> >>autoheader:             [Define if a function `main' is needed.])
> >>autoheader:
> >>autoheader: WARNING: More sophisticated templates can also be produced,
see
> >>the
> >>autoheader: WARNING: documentation.
>
> Yep, you're gonna have to take care of this stuff by hand.  I believe
> that support for config.h.top etc will be going away in autoconf-2.60,
> but that's **just** a guess.  And anyway, 2.60 isn't expected for at
> least several months (and 2.59 won't go 'poof' then, anyway)
>
> > Here is where we should have stopped, although I don't know how to do
> > that with autoreconf.  The following are errors from subdirectories that
> > use older (circa 2.13) autoconf scripts.  autoreconf does not support
> > mixed versions, I guess?
>
> No, not at all.  That's why Zack Weinberg (Nathaniel Nerode?) over on
> the gcc list are updating gcc's (and friends') configure.in's by hand,
> one directory at a time.
>
> Bringing the autotool infrastructure up to snuff for a large project,
> like DDD, is a significant challenge.  And it's not a job that anyone
> really wants to do -- so if you've the itch, the only person who will
> scratch it is you.  You'll need to do all this work yourself, and then
> send your patches back to the DDD developers as a fait accompli, and
> HOPE that they are ready to 'take the plunge', accept your patch, and
> **force all of their developers to switch to using the new autotools**.
>
> It's that last bit that causes trouble.  And until they accept the
> patches and take the plunge, you'll have to maintain your changes
> out-of-baseline.  And keep reapplying-and-reautotooling each time you
> update to a new version of DDD.
>
> One thing to keep in mind: when doing this, it helps to keep your
> patches in separate 'piles'.  I usually keep a 'pre-autotool' set, which
> are the changes to configure.in, Makefile.am's, acinclude.m4's, etc.
> Then, there's the 'post-autotool' set, which are the changes to those
> files which are automagically updated by re-running
> autoconf/automake/libtoolize (I usually include a 'bootstrap' script as
> part of my 'pre-autotool' pile-o-patches [*]).  Then, there's the 'code'
> set (changes to actual code), and the 'cygwin-packinging' set (stuff
> that goes in <srcdir>/CYGWIN-PATCHES/ like cyg-specific README, .hint,
> postinstall script, etc -- that the upstream maintainers would NEVER be
> interested in.)
>
> [*] When actually releasing the cygwin package, there are two ways to do
> this.  The first way is to combine all four piles into one mondo patch,
> and ship it as "the" patch for the package.  (patchutils is your
> friend).  The downside is, often these patches are > 3M uncompressed,
> thanks to the MASSIVE changes to the configure script, the
> Makefile.in's, etc -- IOW, the 'post-autotool' pile-o-patches.  The
> second way is to only ship the pre-autotool, code, and cygwin-packaging
> piles as the 'mondo' patch, and then adapt cygwin's
> generic-packaging-script to run bootstrap as part of it's prep() phase.
>   This way, the patch is much smaller -- AND it's easier for you to
> maintain.  The downside is that (a) if anybody else wants to build your
> version of the package, they must have the autotools installed, (b)
> building is slow, because you have to run bootstrap each time [twice! -- 
> again during mkpatch() for reasons I won't go into here -- if you're
> interested, I can send one of my old packages where I had to do this,
> and you can see how I did it and why.  None of my current packages on
> sourceware need to do this anymore...yay me.]
>
> It's a royal pain...but there's no other choice, if (a) your-fav-pkg
> won't compile properly on cygwin without modern autotool support, (b)
> the upstream maintainers are unable/unwilling/properly-cautious to 'take
> the plunge' and refuse to integrate your patches for a few release cycles.
>
> >>configure.in:54: error: possibly undefined macro: AC_PROG_CC_GNU
> >>      If this token and others are legitimate, please use
m4_pattern_allow.
> >>      See the Autoconf documentation.
> >>configure.in:65: error: possibly undefined macro: AC_PROG_CC_G
> >>configure.in:198: error: do not use LIBOBJS directly, use AC_LIBOBJ (see
> >>section `AC_LIBOBJ vs LIBOBJS'
> >>configure.in:310: error: possibly undefined macro: AC_PROG_CC_WORKS
> >>autoreconf: /usr/autotool/devel/bin/autoconf failed with exit status: 1
> >>
> >
> > So, if this hasn't left your tree broken, I think it would test what I
> > wanted.  You should now have libtool 1.5 for the main ddd tree.  I think
> > it would fix this.
>
> But if the subtrees are configured separately AND the subtrees use
> libtool, then each subtree will create its own libtool during its own
> sub-configure step -- and you're back to the mixed-version problem
> again.  Blech.
>
> > New in 1.5: 2002-04-14; CVS version 1.4e, Libtool team:
> > * Support auto-import patch to binutils on cygwin for much improved dll
> >   support.
>
> Yep.
>
> --
> Chuck
>
>
>
>