FW: NEdit still crashes

[Suhaib Siddiqi]

> -----Original Message-----
> From: cygwin-xfree-owner@sources.redhat.com
> [ mailto:cygwin-xfree-owner@sources.redhat.com]On Behalf Of Fleischer,
> Karsten (K.)
> Sent: Friday, August 11, 2000 5:20 AM
> To: 'Sam Reynolds'; Cygwin-Xfree (E-mail)
> Subject: RE: NEdit still crashes
>
>
> Wow, that's it! I simply did the same thing, moving -lm to the end of the
> list.
>
> Thanks, Sam ;-)
>


I did not know that... but you should actually not use
-lm and -lc at all.  They are just the subs to keep ld and gcc happy..
the symbols available in libcygwin.a are enough and libcygwin.a
links by default.

Suhaib

>
> -----Original Message-----
> From: Sam Reynolds [ mailto:sam.reynolds@alphatech.com ]
> Sent: Donnerstag, 10. August 2000 21:07
> To: cygwin-xfree@sourceware.cygnus.com
> Subject: RE: NEdit still crashes
>
>
> I had a problem similar to the one reported by Karsten Fleischer:
>
> I'm porting an old SunOS X Window program to NT using Cygwin Xfree and
> LessTif with Exceed as the X server.
>
> I was able to build the current X libraries and LessTif from source and to
> build and successfully execute the X and LessTif test programs, but my own
> application crashed in XtAppInitialize with a STATUS_ACCESS_VIOLATION.
>
> I traced the execution several layers under XtAppInitialize and
> found where
> the bad address was encountered, in XtPreparseCommand in my case. The data
> coming in to XtPreparseCommand was obviously scrambled.
>
> I suspected at first that the compiler flags or -D defines in my makefile
> which had worked on SunOS 8 years ago were bad for Cygwin gcc, so I copied
> the ones from the X samples to my makefile. That didn't fix the problem.
>
> I took another look at the sample makefiles compared to mine and
> found that
> the -l options were in a different order. In my original makefile -lm was
> the first to be scanned, but in the samples, it was the last. I moved -lm
> to the end of my list, and was able to successfully execute the resulting
> build.
>
> For those new to the GNU tools and UNIX, it's possible to scan the
> libraries for references using the nm command. You can grep and sort the
> resulting lists to see cases where definitions of the same name occur in
> different libraries. Where multiple definitions occur, and one is good and
> the other bad, the order of the -l makes the difference between successful
> execution and a crash. A reference in one of the X libraries is
> more likely
> to work with X than the ones in the standard libraries.
>
> Perhaps changing the -l option order or the order of the explicitly
> included libraries would solve Karsten's problem and some of the other
> similar problems I've seen on this list.
>
> Sam Reynolds