This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin 2.6.0 Fork issue


Rashi Singhal wrote:
 > Hi ,
 >
 > Thanks again for reply.Please find my response.:
 >
 > You're saying that on this same computer, running Win 2012, this
 > sample code ran properly under a previous version of Cygwin? Which
 > version was that?
 >
 > Answer: We were using pretty old version 1.7.0-58

OK.

 > Which source have you downloaded?  Whose source?
 >
 > Answer: I have downloaded Cygwin 2.26 source

That's not a valid version number.  Cygwin is at 2.6.1 now.  Due to the root
cause identified below, Cygwin source is likely to be of no use to you.

 > I have doubt ,.Is there any compilation variable or cygwin varaible
 > set for autoloading all dll's
 >
 > Not sure why you're asking this.
 >
 > Answer: As all the other dll's (windows native and actian pervasive)
 > are not getting loaded automatically with old version of
 > cygwin(1.7.0-58) so I asked if there any variable which say to
 > autoload the dll's.
 > I  know old version is very old to compare the things but I am doing
 > that as I used that as my cygwin version till now.

There is no such flag.  Under Cygwin, DLLs are either loaded as the process
begins execution or they're dynamically loaded by using dlopen().

 > Your sample program is getting exceptions (i.e., is faulting) even
 > before it fork()s the child process. The child is faulting the same
 > way. This looks pretty much like your sample program was built with
 > incorrect assumptions.
 >
 > Answer: Yes I am trying to find why such exceptions has come.
 >   are
 > You can try posting the compilation (and linking) command(s) that you
 > used to build your btrsamp.exe program. Maybe there's something
 > obvious there that somebody here can see. We can't help you debug your
 > program though, and you can't mix Windows-native DLLs that use
 > Microsoft C runtime with Cygwin code.
 >
 > Answer: Please find below compilation and linking code
 >
 > linking varaible
 >
 > export CC=gcc
 > export LEX=flex
 > export CYGWIN=server
 > export PLATFORM=NT4
 > export OS_FLAGS="-Wall -DNT4 -DNW_SUPPORT -DNORELISAM -D_KERNEL -DCYG15"
 > export OS_CIOS=
 > export OS_LIBS="-L/usr/lib -lkernel32 -lcygwin -lmingw32 -L/usr/lib
 > -lkernel32 -L/usr/bin -lgcc -L/usr/local/lib -lcompat -lbtr"

I believe that right there is where you're getting into trouble.  You have both
-lcygwin and -lmingw32. It looks like you're trying to build a MinGW program on Cygwin...

I don't know why you've specified both -lcygwin and -lmingw32.  That may be
standard procedure for building MinGW programs; I don't know about that.  If
you're using MinGW, your support questions should be directed to MinGW mailing
lists as they're off-topic here.

If you want to build on Cygwin, using Cygwin's facilities, then try setting
OS_LIBS="-lbtr" and see if that works better.  I.e., get rid of all the -L and
-l that refer to Windows DLLs and MinGW DLLs.

Be aware that MinGW and Cygwin are separate projects with separate goals and
separate build methods.  If you are unsure about the differences between the two
projects, read the mingw.org front page and the cygwin.com front page.  A big
difference is: MinGW lets you build stand-alone programs that depend on the
Microsoft C runtime, while Cygwin lets you build programs that depend on and
must be accompanied by the Cygwin DLL.  You have to choose one environment or
the other; you can't mix them together.

..mark

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]