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]

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

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

[Harold L Hunt II]

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: compiling DDD

[Arnaud Desitter]

----- Original Message ----- 
From: "Richard Campbell" <richard.campbell@air2web.com>
Newsgroups: gmane.os.cygwin.xfree,gmane.comp.debugging.ddd.bugs
Cc: <bug-ddd@gnu.org>
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 <Xm/Xm.h>
#include <stdio.h>
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

[Arnaud Desitter]

----- Original Message ----- 
From: "Harold L Hunt II" <huntharo@msu.edu>
Newsgroups: gmane.os.cygwin.xfree,gmane.comp.debugging.ddd.bugs
Cc: <bug-ddd@gnu.org>
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

[Harold L Hunt II]

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

INSTALL.html#compile_Windows was (Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault)

[Brian Ford]

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: [Lesstif] INSTALL.html#compile_Windows was (Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault)

[Danny Backx]

Hmm, maybe I didn't read some message carefully enough to figure
out that this was a complete and working patch set, not work
in progress.

If that is so, my apologies.

Anyway : I've located the messages in your mail and worked through
the patch set. I've applied them. One was wrong (aclocal.m4 is a
generated file, ac_find_xft.m4 needed to be changed instead.

I've edited the INSTALL document, you may want to read the
changes. I am not sure whether Interix and others still exist,
maybe you'd like me to add more comments about Cygwin. If you
do, don't hesitate to ask.

I don't run Cygwin regularly so I'm not in a position to test
these changes. Can someone check ? Do you want me to create
another release of LessTif with this change ?

	Danny

On Thu, 2003-12-04 at 20:35, Brian Ford wrote:
> 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.

Re: [Lesstif] INSTALL.html#compile_Windows

[Brian Ford]

On Sun, 7 Dec 2003, Danny Backx wrote:

> Hmm, maybe I didn't read some message carefully enough to figure
> out that this was a complete and working patch set, not work
> in progress.
>
At the time, a lesstif DLL for Cygwin was still a work in progress, all be
it an iminent one.  But, the Xt/Xmu/Xaw DLLs described by your
documentation as the reason for its impossibility did already exist.
Hence, I requested a documentation update while soliciting help for the
work in progress.

> If that is so, my apologies.
>
It was confusing, and I should have supplied an actual documentation patch
instead of just the commentary.  So, my appologies as well.

> Anyway : I've located the messages in your mail and worked through
> the patch set. I've applied them. One was wrong (aclocal.m4 is a
> generated file, ac_find_xft.m4 needed to be changed instead.
>
I definately did not expect you to do this.  As I stated previously, I
intended to clean them up and submit them myself given sufficient time.
At the time of the first report, this patch set did not exist, yet.

Anyway, thank you for taking the time to do this.  I have not yet had the
time to review the resul, but I will try to soon.

> I've edited the INSTALL document, you may want to read the
> changes. I am not sure whether Interix and others still exist,
> maybe you'd like me to add more comments about Cygwin. If you
> do, don't hesitate to ask.
>
This looks fine for now.  Thank you again.

> I don't run Cygwin regularly so I'm not in a position to test
> these changes. Can someone check ? Do you want me to create
> another release of LessTif with this change ?
>
I will check as soon as I find time.

Cygwin distributes its own binary and source releases independant of the
lesstif release schedule, so a new release from you is not necessary.
Thanks for the offer.

> On Thu, 2003-12-04 at 20:35, Brian Ford wrote:
> > 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

[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

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

[Brian Ford]

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

[Richard Campbell]

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.

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

[Richard Campbell]

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

[Harold L Hunt II]

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

[Richard Campbell]

>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

[Brian Ford]

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
cygwin@cygwin.com or libtool@gnu.org 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

[Richard Campbell]

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

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

[Richard Campbell]

>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 
<snip many lines of .o files>
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 
<snip many lines of .o files>
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: c ompiling DDD

[Richard Campbell]

>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

[Richard Campbell]

>Please try on Cygwin:
>>cat Xmcheck.c
>#include <Xm/Xm.h>
>#include <stdio.h>
>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: c ompiling DDD

[Harold L Hunt II]

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 
> <snip many more *.o files>
> 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: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD

[Richard Campbell]

>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 
<snip many more *.o files>
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.