public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Mark Geisert <mark@maxrnd.com>
To: cygwin@cygwin.com
Subject: Re: Cygwin 2.6.0 Fork issue
Date: Fri, 06 Jan 2017 09:05:00 -0000	[thread overview]
Message-ID: <586F5DE5.5060907@maxrnd.com> (raw)
In-Reply-To: <586F5B5F.1070407@maxrnd.com>

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

       reply	other threads:[~2017-01-06  9:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <586F5B5F.1070407@maxrnd.com>
2017-01-06  9:05 ` Mark Geisert [this message]
2017-01-06 20:34   ` René Berber
2017-01-03 11:17 Mark Geisert
  -- strict thread matches above, loose matches on Subject: below --
2017-01-03  8:53 Rashi Singhal
2017-01-05  4:04 ` Rashi Singhal
2017-01-05 10:17   ` Mark Geisert
2017-01-06  2:58   ` Rashi Singhal
2016-12-08  5:37 Rashi Singhal
2016-12-08  7:17 ` Brian Inglis
2016-12-16  9:28 ` Rashi Singhal
2016-12-30  8:25   ` Rashi Singhal
2016-12-30 19:25     ` Eliot Moss

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=586F5DE5.5060907@maxrnd.com \
    --to=mark@maxrnd.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).