Re: DDD 3.3.8 recipe - was - RE: libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault
Hi, A few suggestions: Related to #pragma interface and gang, could you submit a bug report to the gcc folks ? As far as ddd is concerned, you could write an autoconf test that makes sure that #pragma ... does not create a link failure and patch properly the ddd source code. #ifndef __CYWIN__ all over the ddd source code is not acceptable IMO. Related to the libtool problem, you should get the ddd source from the CVS repository and use ./CVSMake directly under cygwin using recent version of the autotools. It may uncover some problems in configure.ac and friends. Please report (and possibly fix) them to [EMAIL PROTECTED] Regards, - Original Message - From: Richard Campbell [EMAIL PROTECTED] Newsgroups: gmane.os.cygwin.xfree,gmane.comp.debugging.ddd.bugs Cc: [EMAIL PROTECTED] Sent: Friday, December 05, 2003 6:39 PM Subject: RE: DDD 3.3.8 recipe - was - RE: libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault Resend - got denied because of attachment size, so I've uploaded my diffs to a web page. Ok, I think this is the quickest way to get a working (as far as I can tell, and I didn't play with it all that much, although I did load up the cxxtest.exe, set a breakpoint, run through, etc.) DDD 3.3.8 on cygwin: 1. Get the DDD 3.3.8 source and a gcc 3.3.x source. 2. Copy the gcc/include contents into ddd-3.3.8/include 3. Edit ddd-3.3.8/configure to remove the old_archive_from_expsyms_cmds variable (patch below, which is just in the cygwin section of configure): bash-2.05b$ diff -u ddd-3.3.8-orig/configure ddd-3.3.8/configure --- ddd-3.3.8-orig/configure2003-10-22 15:29:40.0 -0400 +++ ddd-3.3.8/configure 2003-12-05 11:34:05.948423800 -0500 @@ -9492,7 +9492,8 @@ else $CC -o impgen impgen.c ; fi)~ $output_objdir/impgen $dir/$soroot $output_objdir/$soname-def' -old_archive_from_expsyms_cmds='$DLLTOOL --as=$AS --dllname $soname --def $output_objdir/$soname-def --output-lib $output_objdir/$newlib' +#old_archive_from_expsyms_cmds='$DLLTOOL --as=$AS --dllname $soname --def $output_objdir/$soname-def --output-lib $output_objdir/$newlib' +old_archive_from_expsyms_cmds= # cygwin and mingw dlls have different entry points and sets of symbols # to exclude. 4. bash ./configure 5. Edit all of ddd/*.C ddd/*.h to remove or guard all #pragma interface and #pragma implementation lines. 6. make 7. make install 8. run as normal. The usual disclaimers apply. I have included the output of: diff -u -r -N ddd-3.3.8-orig/ ddd-3.3.8 Available at: http://bellsouthpwp.net/u/l/ulvester/iffs.gz Feel free to play with it if the prospect of handediting 500 .C and .h files doesn't thrill you. -Richard Campbell.
Re: libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault
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 [EMAIL PROTECTED] will be considered. Best regards, - Original Message - From: Charles Wilson [EMAIL PROTECTED] Newsgroups: gmane.os.cygwin,gmane.os.cygwin.xfree,gmane.comp.debugging.ddd.bugs Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] 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 libX_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
libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault
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
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 libX_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
