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]

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

[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

[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

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

[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

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

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