Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: compiling DDD
Hi, - Original Message - From: "S Iyer" <[EMAIL PROTECTED]> Newsgroups: gmane.os.cygwin.xfree,gmane.comp.debugging.ddd.bugs Cc: <[EMAIL PROTECTED]> Sent: Wednesday, December 03, 2003 9:42 PM Subject: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: compiling DDD > As I am having similar problems with DDD, let me describe what I > have done. > 1. Setup a fresh copy of cygwin from kernel.org mirror > 2. Get ddd-3.3.8 and unpack. > 3. ./configure -- all goes well with one WARNING: > configure: WARNING: X11/Xmu/Editres.h: present but cannot be compiled > configure: WARNING: X11/Xmu/Editres.h: check for missing prerequisite headers? > configure: WARNING: X11/Xmu/Editres.h: proceeding with the preprocessor's result > > 4. make did not compile even a single file: > $make > Making all in libiberty > /usr/local/ddd-3.3.8/libiberty > make[1]: Entering directory `/usr/local/ddd-3.3.8/libiberty' > if [ x"" != x ] && [ ! -d pic ]; then \ > mkdir pic; \ > else true; fi > touch stamp-picdir > make[1]: *** No rule to make target `../include/xregex.h', needed > by `regex.o'. Stop. > make[1]: Leaving directory `/usr/local/ddd-3.3.8/libiberty' > make: *** [all-recursive] Error 1 > Some include files from libiberty have been forgotten in ddd 3.3.8. It will be fixed in the next version. Meanwhile, you can find the missing files in gcc 3.3.2. Grab the gcc source and recopy gcc/include within ddd/include. That should fix it. > Now I can use an earlier ddd or an earlier gcc. > Having read past messages, old gcc's are frowned upon. > So I got ddd-3.3.7, compile still complains that Editres cannot > be compiled. make seems to compile everything untilt eh linker > complains: > AgentM.o(.text+0x296): In function `GLOBAL(int10_t, long double, > char, short, int, double)': > /usr/include/c++/3.3.1/iostream:87: undefined reference to > `__static_initialization_and_destruction_0(int, int)' > AgentM.o(.text+0x2b6): In function `_GLOBAL__D_AgentM_rcsid': > /usr/include/c++/3.3.1/iostream:87: undefined reference to > `__static_initialization_and_destruction_0(int, int)' > AsyncAgent.o(.text+0x8b6): In function > `_GLOBAL__I_AsyncAgent_rcsid': > /usr/include/c++/3.3.1/iostream:287: undefined reference to > `__static_initialization_and_destruction_0(int, int)' > AsyncAgent.o(.text+0x8d6): In function > `_GLOBAL__D_AsyncAgent_rcsid': > /usr/include/c++/3.3.1/iostream:287: undefined reference to > `__static_initialization_and_destruction_0(int, int)' > LiterateA.o(.text+0x2496): In function > `_GLOBAL__I_LiterateAgent_rcsid': > /usr/include/c++/3.3.1/iostream:269: undefined reference to > `__static_initialization_and_destruction_0(int, int)' > LiterateA.o(.text+0x24b6):/usr/include/c++/3.3.1/iostream:269: > more undefined references to > `__static_initialization_and_destruction_0(int, int)' follow > GraphNPA.o(.ctors+0x0):/usr/local/ddd-3.3.7/ddd/GraphNPA.C: > undefined reference to `__GLOBAL__I_GraphNodePointerArray_rcsid' > GraphNPA.o(.dtors+0x0):/usr/local/ddd-3.3.7/ddd/GraphNPA.C: > undefined reference to `__GLOBAL__D_GraphNodePointerArray_rcsid' > HintGraphN.o(.text+0xa6): In function > `_GLOBAL__I_HintGraphNode_rcsid': > /usr/include/c++/3.3.1/iostream:453: undefined reference to > `__static_initialization_and_destruction_0(int, int)' > HintGraphN.o(.text+0xc6): In function > `_GLOBAL__D_HintGraphNode_rcsid': > /usr/include/c++/3.3.1/iostream:453: undefined reference to > `__static_initialization_and_destruction_0(int, int)' > PannedGE.o(.ctors+0x0):PannedGE.C: undefined reference to > `__GLOBAL__I_PannedGraphEdit_rcsid' > PannedGE.o(.dtors+0x0):PannedGE.C: undefined reference to > `__GLOBAL__D_PannedGraphEdit_rcsid' > PosGraphN.o(.text+0x36): In function > `_GLOBAL__I_PosGraphNode_rcsid': > /usr/include/c++/3.3.1/iostream:453: undefined reference to > `__static_initialization_and_destruction_0(int, int)' > PosGraphN.o(.text+0x56): In function > `_GLOBAL__D_PosGraphNode_rcsid': > /usr/include/c++/3.3.1/iostream:453: undefined reference to > `__static_initialization_and_destruction_0(int, int)' > annotation.o(.ctors+0x0): In function > `_Z13strip_leadingR6stringRKS_': > /usr/local/ddd-3.3.7/ddd/annotation.C:45: undefined reference to > `__GLOBAL__I_annotation_rcsid' > annotation.o(.dtors+0x0):/usr/local/ddd-3.3.7/ddd/annotation.C:45: > undefined reference to `__GLOBAL__D_annotation_rcsid' > complete.o(.text+0x2aa6): In function `GLOBAL(int12_t, long > double, char, short, int, double)': > /usr/include/c++/3.3.1/iostream:226: undefined reference to > `__static_initialization_and_destruction_0(int, int)' > complete.o(.text+0x2ac6): In function > `_GLOBAL__D_complete_rcsid': > /usr/include/c++/3.3.1/iostream:226: undefined reference to > `__static_initialization_and_destruction_0(int, int)' > deref.o(.text+0x856): In function `GLOBAL(int222_t, long double, > char, short, int, double)': > /usr/include/c++/3.3.1/iostream:1089: undefined reference to > `__static_initialization_and_destruction_0(int, int)' > deref.o(.
Error: procedure entry point in cygwin1.dll
Hello I try running xfree/cygwin on a PC with Windows XP. When I try to start xfree either directly from the windows explorer with startxwin.bat or from a cygwin bash or csh shell with startxwin.sh, I always get the error: The procedure entry point __getreent could not be located in the dynamic link library cygwin1.dll I have made a search in previous messages and they most of them suggest that similar errors are usually caused by having several versions of cygwin1.dll or an outdated version of this file. However I have only one version of cygwin1.dll on my hard disk, the one that came with cygwin 1.5.5-1 which is dated to 20.09.03 Has anyone another suggestion for the cause of the problem? Thanks, Martin -- +++ GMX - die erste Adresse für Mail, Message, More +++ Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net -- +++ GMX - die erste Adresse für Mail, Message, More +++ Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
Problem with emacs on Dell Inspiron 5100
I have a problem with running Cygwin/X on my Dell 5100 with ATI Mobility Radeon 7500. The windows come up without any problem, but when I start emacs, I get garbage in the emacs buffers. I'm guessing, without really knowing for sure, that some of the required emacs fonts are missing. Anyone have any ideas for how to patch this? Thanks. BTW, I have a stand-alone installation of GNU emacs which works just fine...
RE: compiling DDD
>WAG, try configuring with --without-athena. Doesn't build, then. make[2]: Entering directory `/cygdrive/c/ddd-3.3.7/ddd' source='PannedGE.C' object='PannedGE.o' libtool=no \ depfile='.deps/PannedGE.Po' tmpdepfile='.deps/PannedGE.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I. -I./.. -isystem /usr/X11R6/include -DNDEBUG - O2 -g -W -Wall -trigraphs -c -o PannedGE.o `test -f 'PannedGE.C' || echo './'`P annedGE.C PannedGE.C: In function `_WidgetRec* createPannedGraphEdit(_WidgetRec*, const char*, Arg*, unsigned int)': PannedGE.C:400: error: `cerr' undeclared (first use this function) PannedGE.C:400: error: (Each undeclared identifier is reported only once for each function it appears in.) make[2]: *** [PannedGE.o] Error 1 make[2]: Leaving directory `/cygdrive/c/ddd-3.3.7/ddd' make[1]: *** [all] Error 2 make[1]: Leaving directory `/cygdrive/c/ddd-3.3.7/ddd' make: *** [all-recursive] Error 1 That line is: cerr << "Warning: panned graph editors are not supported " "in this configuration.\n"; Checking a little further, iostream isn't included on that side of the configuration, which seems odd. Added an iostream include and it successfully built. And then failed in much the same way (different specific error in the version of Motif it didn't find): Warning: This DDD requires a Motif 2.1 library (using Motif 1275340.287) Continue at own risk. Internal error (Segmentation fault). -Richard Campbell.
Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
Richard Campbell wrote: Modifying ddd/config.h will not help. There is a problem with the lesstif distribution on cygwin. See: http://www.lesstif.org/INSTALL.html Is the following what you are referring to? "On windows using Cygwin, U/WIN or Interix, LessTif must be built as static libraries. Because, one of the biggest issues with X on Win32 is the moronic DLL format. Specifically - it is not possible to export data from a Win32 DLL in a form that can be used to statically initialize another global variable. Data access from a DLL requires at least one pointer indirection, and hence executable code. This is why X11R6 doesn't have DLLs for Xt/Xmu/Xaw (and Motif) on Win32." If yes, these rules have been changing. Brian, isn't this what you were specifically working on recently? The statement in quotes above is now misleading and completely incorrect. We are distributing *only* a shared version of LessTif on Cygwin now. The various problems mentioned in the quote all have work-arounds, some of which were already used by OS/2; we enabled those work-arounds and adding one or two more of our own and the shared LessTif library compiles and works fine now. The problem is not with Cygwin's LessTif... the problem is in how DDD is detecting LessTif on Cygwin. It must be assuming that the file name for the import library with be of the format foo.a whereas the name is of the format foo.dll.a on Cygwin. Harold
RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
>The problem is not with Cygwin's LessTif... the problem is in how DDD is >detecting LessTif on Cygwin. It must be assuming that the file name for >the import library with be of the format foo.a whereas the name is of >the format foo.dll.a on Cygwin. This would be detection inside the actual execution, then? The link step is libtoolized and ends up being: g++ -DNDEBUG -O2 -g -W -Wall -trigraphs -o ddd.exe ddd.o basename.o compare.o cook.o cwd.o glob.o UndoBuffer.o UndoBE.o WhatNextCB.o configinfo.o -L/usr/X11R6/lib .libs/libimp-cygXm-2.a -lXft -lXrender .libs/libimp-cygfontconfig-1.a .libs/libimp-cygfreetype-6.a -lz .libs/libimp-cygexpat-0.a -lXaw -lXmu -lXt -lXpm -lXp -lXext -lX11 -lSM -lICE -lncurses -ly ../libiberty/libiberty.a -Wl,--rpath -Wl,/usr/X11R6/lib -Wl,--rpath -Wl,/usr/X11R6/lib Which looks sorta automagic for the dlls, right? -Richard Campbell.
Re: AltGr and XP Powertoys not fixed yet?
Walter,
Walter Haidinger wrote:
Hi!
I've installed Cygwin XFree86 4.3.0-25 on Windows XP Professional (German
Edition, with latest patches) with TweakUI installed.
Unfortunately the AltGr key doesn't work as expected in any X11
application (no problems except with XFree86). The keys works sometimes
(that is, e.g. 3 times then not) or not at all.
FYI, the letters @~|[]{}\ are reached via the AltGr key on german
keyboards. Not having the backslash, at or pipe-symbol is quite annoying,
to say the least! ;-)
Digging through the mailing-list archives revealed that the XP Powertoys
are somehow messing up the keyboard message queue. However, the posts are
over a year old. Hasn't this been fixed yet? I supposed it was fixed
because I did not find anything in the FAQs regarding the AltGr problem.
Well, the only fix I've found so far is to deinstall the Powertoys. :-(
Good man: you actually searched the archives :)
Is there a patch or something else (perhaps a magic Registry entry to
disable Powertoys behaviour) to make AltGr work _with_ having Powertoys
installed? I'd really appreciate this as Exceed would be the only other
solution I can see for now.
No, there is not a patch. Creating a patch would be easiest for someone
with a non-U.S. keyboard and keyboard layout, Windows XP, and TweakUI
installled. The process would consist of looking for all patterns in
the keyboard messages that distinquish TweakUI from non-TweakUI (might
have been done to some degree, you would be looking for things like the
fake Ctrl and Alt keys having different timestamps or coming in in a
different order, or something along those lines) and choosing either a
compatible pattern that works regardless of whether TweakUI is running
or not, or coming up with a way of detecting that TweakUI is running and
altering the way we handle AltGr until TweakUI is stopped or we are
shutdown.
Harold
Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
Richard Campbell wrote: The problem is not with Cygwin's LessTif... the problem is in how DDD is detecting LessTif on Cygwin. It must be assuming that the file name for the import library with be of the format foo.a whereas the name is of the format foo.dll.a on Cygwin. This would be detection inside the actual execution, then? The link step is libtoolized and ends up being: g++ -DNDEBUG -O2 -g -W -Wall -trigraphs -o ddd.exe ddd.o basename.o compare.o cook.o cwd.o glob.o UndoBuffer.o UndoBE.o WhatNextCB.o configinfo.o -L/usr/X11R6/lib .libs/libimp-cygXm-2.a -lXft -lXrender .libs/libimp-cygfontconfig-1.a .libs/libimp-cygfreetype-6.a -lz .libs/libimp-cygexpat-0.a -lXaw -lXmu -lXt -lXpm -lXp -lXext -lX11 -lSM -lICE -lncurses -ly ../libiberty/libiberty.a -Wl,--rpath -Wl,/usr/X11R6/lib -Wl,--rpath -Wl,/usr/X11R6/lib Which looks sorta automagic for the dlls, right? I'm not an expert (or even a user of DDD), but it wouldn't be the first time if I saw something detected incorrectly in configure (picking Motif versus LessTif), followed by a clean compile, followed by a crash on execution. Remember, Motif and LessTif are supposed to have the same interface, so code written for either should compile and link against the other, but the code may not work (segfault). So, I would suspect that DDD's configure is detecting Motif (or assuming Motif by default), compiling some conditional segments for Motif instead of for LessTif (introducing buggy code), followed by linking with LessTif (leading to a crash when the code that works with Motif but not LessTif is run). Again, this is speculation, but that is where I would be looking at the moment. Harold
Re: Error: procedure entry point in cygwin1.dll
On Thu, Dec 04, 2003 at 01:23:38PM +0100, Martin Schmid wrote: >Hello > >I try running xfree/cygwin on a PC with Windows XP. When I try to start >xfree either directly from the windows explorer with startxwin.bat or from a >cygwin bash or csh shell with startxwin.sh, I always get the error: > >The procedure entry point __getreent could not be located in the dynamic >link library cygwin1.dll > >I have made a search in previous messages and they most of them suggest that >similar errors are usually caused by having several versions of cygwin1.dll >or an outdated version of this file. However I have only one version of >cygwin1.dll on my hard disk, the one that came with cygwin 1.5.5-1 which is >dated >to 20.09.03 You should trust the wisdom of the archives. You either have two versions of the DLL around, or you need to reboot. There are no other reasons for this problem. -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com
RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
>That is a bug in gcc on cygwin related to "#pragma interface". >Please look for help on the cygwin mailing list. Arnaud, the problem is with both "#pragma interface" and "#pragma implementation". http://www.cygwin.com/ml/cygwin/2003-07/msg00463.html Guarding all "#pragma interface" and "#pragma implementation" calls with ifndef __CYGWIN__ allows everything to compile cleanly - is this something that could be applied to the main baseline? >Modifying ddd/config.h will not help. There is a problem with the >lesstif distribution on cygwin. See: >http://www.lesstif.org/INSTALL.html Is the following what you are referring to? "On windows using Cygwin, U/WIN or Interix, LessTif must be built as static libraries. Because, one of the biggest issues with X on Win32 is the moronic DLL format. Specifically - it is not possible to export data from a Win32 DLL in a form that can be used to statically initialize another global variable. Data access from a DLL requires at least one pointer indirection, and hence executable code. This is why X11R6 doesn't have DLLs for Xt/Xmu/Xaw (and Motif) on Win32." If yes, these rules have been changing. Brian, isn't this what you were specifically working on recently? -Richard Campbell.
AltGr and XP Powertoys not fixed yet?
Hi!
I've installed Cygwin XFree86 4.3.0-25 on Windows XP Professional (German
Edition, with latest patches) with TweakUI installed.
Unfortunately the AltGr key doesn't work as expected in any X11
application (no problems except with XFree86). The keys works sometimes
(that is, e.g. 3 times then not) or not at all.
FYI, the letters @~|[]{}\ are reached via the AltGr key on german
keyboards. Not having the backslash, at or pipe-symbol is quite annoying,
to say the least! ;-)
Digging through the mailing-list archives revealed that the XP Powertoys
are somehow messing up the keyboard message queue. However, the posts are
over a year old. Hasn't this been fixed yet? I supposed it was fixed
because I did not find anything in the FAQs regarding the AltGr problem.
Well, the only fix I've found so far is to deinstall the Powertoys. :-(
Is there a patch or something else (perhaps a magic Registry entry to
disable Powertoys behaviour) to make AltGr work _with_ having Powertoys
installed? I'd really appreciate this as Exceed would be the only other
solution I can see for now.
Thanks,
Walter
Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: compiling DDD
- Original Message -
From: "Richard Campbell" <[EMAIL PROTECTED]>
Newsgroups: gmane.os.cygwin.xfree,gmane.comp.debugging.ddd.bugs
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, December 04, 2003 2:49 PM
Subject: RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re:
compiling DDD
> >That is a bug in gcc on cygwin related to "#pragma interface".
> >Please look for help on the cygwin mailing list.
>
> Arnaud, the problem is with both "#pragma interface" and "#pragma
> implementation".
> http://www.cygwin.com/ml/cygwin/2003-07/msg00463.html
>
> Guarding all "#pragma interface" and "#pragma implementation" calls with
> ifndef __CYGWIN__
>
> allows everything to compile cleanly - is this something that could be
> applied to the main baseline?
It may be better to fix gcc. However, you can try to convince the ddd
maintainer.
> >Modifying ddd/config.h will not help. There is a problem with the
> >lesstif distribution on cygwin. See:
> >http://www.lesstif.org/INSTALL.html
>
> Is the following what you are referring to?
What I was referring to is that in the curent lesstif version, the
compatibility
mode is hard-coded at build time. Therefore, there is no compatibility
switch to play with once lesstif is installed.
Please try on Cygwin:
>cat Xmcheck.c
#include
#include
int main(void){
printf("xmUseVersion=%d XmVersion=%d\n",
xmUseVersion, XmVersion);
return 0;
}
>gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib -lXm
>./a.out
xmUseVersion=2002 XmVersion=2002
If it gives different numbers, there is a good chance that your lesstif
library won't work properly.
Regards,
>
> -Richard Campbell.
>
RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
>Please try on Cygwin:
>>cat Xmcheck.c
>#include
>#include
>int main(void){
> printf("xmUseVersion=%d XmVersion=%d\n",
> xmUseVersion, XmVersion);
> return 0;
>}
>>gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib -lXm
>>./a.out
>xmUseVersion=2002 XmVersion=2002
>
>If it gives different numbers, there is a good chance that your lesstif
>library won't work properly.
bash-2.05b$ gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib -lXm
Info: resolving _xmUseVersion by linking to __imp__xmUseVersion
(auto-import)
bash-2.05b$ ./a.exe
xmUseVersion=2001 XmVersion=2001
Same numbers.
-Richard Campbell.
Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: compiling DDD
- Original Message -
From: "Richard Campbell" <[EMAIL PROTECTED]>
Newsgroups: gmane.os.cygwin.xfree,gmane.comp.debugging.ddd.bugs
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, December 04, 2003 4:54 PM
Subject: RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re:
compiling DDD
> >Please try on Cygwin:
> >>cat Xmcheck.c
> >#include
> >#include
> >int main(void){
> > printf("xmUseVersion=%d XmVersion=%d\n",
> > xmUseVersion, XmVersion);
> > return 0;
> >}
> >>gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib -lXm
> >>./a.out
> >xmUseVersion=2002 XmVersion=2002
> >
> >If it gives different numbers, there is a good chance that your lesstif
> >library won't work properly.
>
> bash-2.05b$ gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib -lXm
> Info: resolving _xmUseVersion by linking to __imp__xmUseVersion
> (auto-import)
> bash-2.05b$ ./a.exe
> xmUseVersion=2001 XmVersion=2001
>
> Same numbers.
That's progress. Could you try to perform the link using the same commands
as ddd ?
You posted:
g++ -DNDEBUG -O2 -g -W -Wall -trigraphs -o ddd.exe ddd.o basename.o
compare.o cook.o cwd.o glob.o
UndoBuffer.o UndoBE.o WhatNextCB.o configinfo.o -L/usr/X11R6/lib
.libs/libimp-cygXm-2.a -lXft -lXrender .libs/libimp-cygfontconfig-1.a
.libs/libimp-cygfreetype-6.a -lz .libs/libimp-cygexpat-0.a -lXaw -lXmu -lXt
-lXpm -lXp -lXext -lX11 -lSM -lICE -lncurses -ly ../libiberty/libiberty.a
-Wl,--rpath -Wl,/usr/X11R6/lib -Wl,--rpath -Wl,/usr/X11R6/lib
So I guess that it should be something along the lines:
gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib
.libs/libimp-cygXm-2.a
using whather .libs/libimp-cygXm-2.a points to.
Regards,
Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
- Original Message - From: "Harold L Hunt II" <[EMAIL PROTECTED]> Newsgroups: gmane.os.cygwin.xfree,gmane.comp.debugging.ddd.bugs Cc: <[EMAIL PROTECTED]> Sent: Thursday, December 04, 2003 3:49 PM Subject: Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD > Richard Campbell wrote: > >>http://www.lesstif.org/INSTALL.html > > > > "On windows using Cygwin, U/WIN or Interix, LessTif must be built as > > static libraries. Because, one of the biggest issues with X on Win32 > > is the moronic DLL format. Specifically - it is not possible to export > > data from a Win32 DLL in a form that can be used to statically initialize > > another global variable. Data access from a DLL requires at least one > > pointer indirection, and hence executable code. This is why X11R6 doesn't > > have DLLs for Xt/Xmu/Xaw (and Motif) on Win32." > > > > If yes, these rules have been changing. Brian, isn't this what you > > were specifically working on recently? > > The statement in quotes above is now misleading and completely > incorrect. We are distributing *only* a shared version of LessTif on > Cygwin now. The various problems mentioned in the quote all have > work-arounds, some of which were already used by OS/2; we enabled those > work-arounds and adding one or two more of our own and the shared > LessTif library compiles and works fine now. > Fill free to contact the lesstif guys to fix it. Regards,
RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
>So I guess that it should be something along the lines: >gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib >.libs/libimp-cygXm-2.a >using whather .libs/libimp-cygXm-2.a points to. Ok, yeah, that seems to be the problem. bash-2.05b$ gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib -lXm Info: resolving _xmUseVersion by linking to __imp__xmUseVersion (auto-import) bash-2.05b$ ./a.exe xmUseVersion=2001 XmVersion=2001 bash-2.05b$ gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib ddd/.libs/libimp-cygXm-2.a bash-2.05b$ ./a.exe xmUseVersion=1089480191 XmVersion=2001 Now, I guess, to try and walk back all of the automatic steps to figure out why ddd ended up linking against that libimp-cygXm-2.a file. But first, I'll run that last g++ linking step for ddd after editing it to remove those .libs links. -Richard Campbell.
RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
>But first, I'll run that last g++ linking step for ddd after editing it to >remove those .libs >links. Yep. The following edited line produces a segfaulting binary: g++ -DNDEBUG -O2 -g -W -Wall -trigraphs -o ddd.exe ddd.o basename.o compare.o cook.o cwd.o glob.o UndoBuffer.o UndoBE.o WhatNextCB.o configinfo.o -L/usr/X11R6/lib .libs/libimp-cygXm-2.a -lXft -lXrender .libs/libimp-cygfontconfig-1.a .libs/libimp-cygfreetype-6.a -lz .libs/libimp-cygexpat-0.a -lXt -lXpm -lXp -lXext -lX11 -lSM -lICE -lncurses -ly ../libiberty/libiberty.a -Wl,--rpath -Wl,/usr/X11R6/lib -Wl,--rpath -Wl,/usr/X11R6/lib And the following edited line produces a running (at least for simple test, breakpoint, step through, browse source, etc.) binary: g++ -DNDEBUG -O2 -g -W -Wall -trigraphs -o ddd.exe ddd.o basename.o compare.o cook.o cwd.o glob.o UndoBuffer.o UndoBE.o WhatNextCB.o configinfo.o -L/usr/X11R6/lib -lXm -lXt -lXpm -lXp -lXext -lX11 -lSM -lICE -lncurses -ly ../libiberty/libiberty.a -Wl,--rpath -Wl,/usr/X11R6/lib -Wl,--rpath -Wl,/usr/X11R6/lib That line, the bugged one anyway, was produced by libtool. So the question becomes, what is libtool doing wrong? Which will probably require shifting over to the main cygwin list and delving into hideous problems, but C'est la vie. Thanks muchly, Arnaud. -Richard Campbell.
Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: compiling DDD
- Original Message - From: "Richard Campbell" <[EMAIL PROTECTED]> Newsgroups: gmane.os.cygwin.xfree,gmane.comp.debugging.ddd.bugs Cc: <[EMAIL PROTECTED]> Sent: Thursday, December 04, 2003 5:50 PM Subject: RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: compiling DDD > >So I guess that it should be something along the lines: > >gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib > >.libs/libimp-cygXm-2.a > >using whather .libs/libimp-cygXm-2.a points to. > > Ok, yeah, that seems to be the problem. > > bash-2.05b$ gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib -lXm > Info: resolving _xmUseVersion by linking to __imp__xmUseVersion > (auto-import) > bash-2.05b$ ./a.exe > xmUseVersion=2001 XmVersion=2001 > bash-2.05b$ gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib > ddd/.libs/libimp-cygXm-2.a > bash-2.05b$ ./a.exe > xmUseVersion=1089480191 XmVersion=2001 > > Now, I guess, to try and walk back all of the automatic steps to figure out > why ddd ended > up linking against that libimp-cygXm-2.a file. Credit or blame libtool for that. > But first, I'll run that last g++ linking step for ddd after editing it to > remove those .libs > links. Just comment out libtool in the Makefile and see what it does. If you can crack and fix this problem properly, that would be great. Regards,
Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
Arnaud Desitter wrote: If yes, these rules have been changing. Brian, isn't this what you were specifically working on recently? The statement in quotes above is now misleading and completely incorrect. We are distributing *only* a shared version of LessTif on Cygwin now. The various problems mentioned in the quote all have work-arounds, some of which were already used by OS/2; we enabled those work-arounds and adding one or two more of our own and the shared LessTif library compiles and works fine now. Fill free to contact the lesstif guys to fix it. Regards, Regards, My bad... I'm just a clueless newbie to this whole open-source development thingy majig. Harold
RE: ddd compilation
Please keep replies on the cygwin-xfree mailing list. >I was wondering if you could send me the changes to the makefile needed to get >it to compile. What version of gcc are you using? 3.3.1? 3.3.1. I have described all the changes I have made. 1. If using ddd 3.3.8, get the include files from gcc as mentioned by Arnaud. I haven't done this, as I downgraded to ddd 3.3.7 for testing purposes. 2. Remove all "#pragma interface" and "#pragma implementation" lines. 3. Run make. Save off the output. You now have a segfaulting ddd.exe file. 4. Edit the last g++ line to remove the .libs/libcyg*.a libraries and to add -Xm, -Xt, etc., where appropriate. 5. Run that last g++ line again. -Richard Campbell.
RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
>> Now, I guess, to try and walk back all of the automatic steps to figure >> out why ddd ended up linking against that libimp-cygXm-2.a file. > >Credit or blame libtool for that. Specifically, the following two settings: # Whether or not to build static libraries. build_old_libs=yes # Create a temporary old-style archive to link instead of a shared archive. old_archive_from_expsyms_cmds="\$DLLTOOL --as=\$AS --dllname \$soname --def \$output_objdir/\$soname-def --output-lib \$output_objdir/\$newlib" If commented out, everything works cleanly. Now, the bizarre part of the generated libtool is the following: # Whether or not to build shared libraries. build_libtool_libs=yes # Whether or not to build static libraries. build_old_libs=yes Why would you have both "shared" and "static" turned on? Now, to configure, I suppose... -Richard Campbell.
INSTALL.html#compile_Windows was (Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault)
Arnaud Desitter wrote: > Harold L Hunt II wrote: >> Richard Campbell wrote: >>>Arnaud Desitter wrote: http://www.lesstif.org/INSTALL.html >>> >>> "On windows using Cygwin, U/WIN or Interix, LessTif must be built as >>> static libraries. Because, one of the biggest issues with X on Win32 >>> is the moronic DLL format. Specifically - it is not possible to export >>> data from a Win32 DLL in a form that can be used to statically initialize >>> another global variable. Data access from a DLL requires at least one >>> pointer indirection, and hence executable code. This is why X11R6 doesn't >>> have DLLs for Xt/Xmu/Xaw (and Motif) on Win32." >>> >>> If yes, these rules have been changing. Brian, isn't this what you >>> were specifically working on recently? >>> I was just trying to help pick up the pieces. Ralf Habacker and Harold L Hunt II fixed the shared Xt problem here: http://www.cygwin.com/ml/cygwin-xfree/2003-10/msg00173.html Then, Zhangrong Huang and Harold L Hunt II fixed lesstif here: http://www.cygwin.com/ml/cygwin-xfree/2003-10/msg00347.html > > The statement in quotes above is now misleading and completely > > incorrect. We are distributing *only* a shared version of LessTif on > > Cygwin now. The various problems mentioned in the quote all have > > work-arounds, some of which were already used by OS/2; we enabled those > > work-arounds and adding one or two more of our own and the shared > > LessTif library compiles and works fine now. > > I'll take an action item to push these changes back upstream to lesstif, but don't expect any particular time line. > Fill free to contact the lesstif guys to fix it. > I did, here: http://www.cygwin.com/ml/cygwin-xfree/2003-10/msg00291.html They have not, yet. I guess I need to supply an actual documentation patch. Again, I'll put it on my list. But, don't expect immediate action. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444
RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
On Thu, 4 Dec 2003, Richard Campbell wrote: > Arnaud Desitter wrote: > >Richard Campbell wrote: > >> Now, I guess, to try and walk back all of the automatic steps to figure > >> out why ddd ended up linking against that libimp-cygXm-2.a file. > >> > >Credit or blame libtool for that. > > What version of libtool is ddd-3.3.8 using? Does re-libtoolizing fix it? When these two questions are answered, it is probably time to move this to [EMAIL PROTECTED] or [EMAIL PROTECTED] where the Cygwin libtool experts are. > Specifically, the following two settings: > > # Whether or not to build static libraries. > build_old_libs=yes > > # Create a temporary old-style archive to link instead of a shared archive. > old_archive_from_expsyms_cmds="\$DLLTOOL --as=\$AS --dllname \$soname --def > \$output_objdir/\$soname-def --output-lib \$output_objdir/\$newlib" > > If commented out, everything works cleanly. > > Now, the bizarre part of the generated libtool is the following: > > # Whether or not to build shared libraries. > build_libtool_libs=yes > > # Whether or not to build static libraries. > build_old_libs=yes > > Why would you have both "shared" and "static" turned on? > To have the option of either, obviously. Some packages default this way as a courtesy. Static libs are useful when profiling, distributing binaries without worrying about associated libs, etc. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444
RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
>What version of libtool is ddd-3.3.8 using? Automatically generated by configure? I reconfigured with: bash ./configure --disable-static And libtool now has the settings I had hoped for - I'm running a make now, and I'm pretty confident that will work. Which would boil my steps down to (for 3.3.7): 1. Remove all "#pragma interface" and "#pragma implementation" lines. 2. Configure with: "bash ./configure --disable-static". 3. Make as usual. (For 3.3.8, add the following: 0. Copy gcc/include into libiberty/include, or whatever exactly Arnaud said ) -Richard Campbell.
Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
Richard, Richard Campbell wrote: What version of libtool is ddd-3.3.8 using? Automatically generated by configure? I reconfigured with: bash ./configure --disable-static And libtool now has the settings I had hoped for - I'm running a make now, and I'm pretty confident that will work. Which would boil my steps down to (for 3.3.7): 1. Remove all "#pragma interface" and "#pragma implementation" lines. 2. Configure with: "bash ./configure --disable-static". 3. Make as usual. (For 3.3.8, add the following: 0. Copy gcc/include into libiberty/include, or whatever exactly Arnaud said ) Does this result in a working version of ddd? If so, I can package it up for Cygwin's setup.exe. Harold
RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
bash ./configure --disable-static Only got me halfway - if old_archive_from_expsyms_cmds has a value, it will override the "build_old_libs=no" option in libtool. Strange. -Richard Campbell.
RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
Almost. When I figure out the minimum number of changes, I'll repost, and then test on the current (3.3.8) build. -Richard Campbell. >Does this result in a working version of ddd? If so, I can package it >up for Cygwin's setup.exe.
Xaw patch (focus problem) & DLL
I am working with an xterm I modified and rebuilt under the latest cygwin source files and binaries and have experienced the problem with focus (the xterm only has keyboard focus if the mouse is in the window). This was corrected with a patch by Harold Hunt recently, and I have been looking into implementing the patch. However, when I rebuilt the library with the patch, using the Imake and make with the default settings, it builds a static library. (I am building using the files in cygwin/xc/programs/Xaw. And because of the firewall I work behind, I have been unable to access the CVS source tree, so am unaware of what may be missing in my cygwin environment.) It appears from Harold's email that he rebuilt a dynamic library, as he states that he tested the patch by running a non-recompiled xterm against the library. So my question is: what library (or libraries) need to be rebuilt, and does one go about building it? I have looked at the documentation on dlltool, but have never used it before. (The last time I built xterm under cygwin was over two years ago, and I believe that static libraries were all that I used. And I am confused by the various libraries used in my cygwin setup - for example, libXaw-7.dll.a is used by the linker in building xterm, apparently, but cygxaw-7.dll is required at runtime.) Thanks in advance for any help. John Urbanczyk Developer, Research & Development Paychex Inc. 675 Basket Road Webster NY 14580 Phone: 585-216-0578 - The information contained in this message may be privileged, confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or any employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Paychex, Inc.
RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
On Thu, 4 Dec 2003, Richard Campbell wrote: > Brian Ford wrote: > >What version of libtool is ddd-3.3.8 using? > > > Automatically generated by configure? > I checked. In ltmain.sh for ddd-3.3.8 it says VERSION=1.4.2. I don't know what it was in 3.3.7. The latest is 1.5. > >Does re-libtoolizing fix it? > > Could you try "autoreconf --install --force", re-configure, and report the results? It would be nice to know if the latest autotools are still broken. Thanks. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444
RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
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
Re: Cygwin crashed by emacs???
On Thu, 4 Dec 2003, Sergey Barabash wrote:
> My entire cygwin session CRASHES CONSISTENTLY
> ("XWin.exe has generated errors... log is being created")
>
This is XWin.exe, not your "entire cygwin session" (whatever that means).
As such, please use the [EMAIL PROTECTED] list. I have directed
this reply there.
> when I try using "ediff-buffers" in emacs.
>
> Details:
> I am running cygwin 1.3-4 under Windows 2000 (v.5.00.2195, s.p.4)
>
I don't know what Cygwin version 1.3-4 was/is.
I suggest you visit http://www.cygwin.com/problems.html to see how to form
a useful bug report with the proper supporting information.
I also suggest you use http://www.cygwin.com/setup.exe to update your
installation (especially the cygwin package, emacs package, and all
XFree86 packages) before soliciting further support. If you are not
up-to-date, you will not get much help.
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax: 314-551-8444
Re: Xaw patch (focus problem) & DLL
On Thu, 4 Dec 2003, John E Urbanczyk wrote: > I am working with an xterm I modified and rebuilt under the latest > cygwin source files and binaries and have experienced the problem with > focus (the xterm only has keyboard focus if the mouse is in the window). > This was corrected with a patch by Harold Hunt recently, and I have been > looking into implementing the patch. > What do you mean, implementing the patch? > However, when I rebuilt the library > with the patch, using the Imake and make with the default settings, it > builds a static library. > Why build the library at all? Why not just use the one Harold released here? http://www.cygwin.com/ml/cygwin-xfree-announce/2003-11/msg3.html > (I am building using the files in > cygwin/xc/programs/Xaw. And because of the firewall I work behind, I > have been unable to access the CVS source tree, so am unaware of what > may be missing in my cygwin environment.) > Now I'm really lost. You said you were using the "latest cygwin source files and binaries." And, how does the XFree CVS source tree have anything to do with things missing from your "cygwin environment". > It appears from Harold's email > that he rebuilt a dynamic library, as he states that he tested the patch > by running a non-recompiled xterm against the library. > Yes. > So my question > is: what library (or libraries) need to be rebuilt, > None if you are using the release in the announcement above. > and does one go about building it? > I would say without getting up-to-date CVS sources, no one would be interested in re-inventing this for you. > I have looked at the documentation on dlltool, but > have never used it before. (The last time I built xterm under cygwin was > over two years ago, and I believe that static libraries were all that I > used. > I hope your sources are not that old :). > And I am confused by the various libraries used in my cygwin setup > - for example, libXaw-7.dll.a is used by the linker in building xterm, > It's an import library. Read up on them. > apparently, but cygxaw-7.dll is required at runtime.) Thanks in advance > for any help. > This is the actual dll. Maybe it's just me, but I found your description very confusing. Since you had not received a reply yet, I thought I would try to help you clarify. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444
RE: How to configure a windows machine as an X client?
Nope. This would require making Windows an Xclient. This was done before and even offered as a product from Insignia, but was later pulled due to contractual problems with the developer company and never brought back again. Now though, I see people getting similar functionality with VNC. - Joaquin > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Thai.Dang-Vu-1 > Sent: Wednesday, December 03, 2003 2:45 PM > To: [EMAIL PROTECTED] > Subject: How to configure a windows machine as an X client? > > > Hello everybody, > > I'm very impressed that I can use Cygwin/XFree86 and openssh > to run mozilla on a Linux machine with the mozilla window on > the Windows machine. > > I have a question. Could I configure a Windows machine as an > X client so that from a Linux machine I can run Internet > Explorer and have the IE window on that Linux machine? If it > is possible, could you tell me which document I should read? > > Regards, > > Thai > > >
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 ha
