Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID: <38C81A4A.2A661C0F@weru.ksu.edu>
Date: Thu, 09 Mar 2000 15:40:26 -0600
From: "Larry E. Wagner" <wagner AT weru DOT ksu DOT edu>
Organization: USDA-ARS Wind Erosion Research Unit
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin AT sourceware DOT cygnus DOT com
Subject: Compiling app under Cygwin V1.0 that doesn't require Cygwin1.dll
References: <952574635 DOT 4503 DOT ezmlm AT sourceware DOT cygnus DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have an apparent problem with compiling a correctly working C program
I have with the -no-cygwin option and using the mingw libraries/headers.
I get the program to compile and link correctly.  It will run.  However,
sometimes it will print a "$" in place of a numeric digit in the output file
when specific valid input files are selected.  We originally discovered this
problem with a version of the program compiled under the B20.1 environment.
The problem still exists under the Cygwin V1.0 environment.  Upgrading the
version of gcc to 95.2 didn't help either.  A version of the program compiled
under the standard default cygwin environment does NOT exhibit this behavior.
Neither does a Unix version compiled with gcc on a Sun Ultra 10.

So, the problem appears to be some type of obscure bug in the DLL library
handling the fprintf() statements when compiling/linking with the -no-cygwin
option specified.

At this point, it appears that I have three options to create a standalone,
single file executable that can be run on any Windows PC without providing
a separate copy of the Cygwin1.dll:

1.  Somehow determine the source of the actual bug causing my problem.
This appears unlikely, unless someone out there on the list knows how I should
proceed to find it and possibly fix it.

2.  Determine the correct commandline incantations for the gcc compile/link 
steps to include the necessary Cygwin1.dll functionality required into the
application executable.  So far, I have not been successful doing so.
Any pointers on how to correctly do this would be appreciated as this would
be the quickest and easiest solution for me.

3.  Configure "cook", a make-like program I use to control builds of my
applications, to use a different, eg. commercial, PC compiler/linker.  This is
doable, but it requires a lot of additional conditional code to handle
the differences between "PC-style" builds and "Unix-style" builds, making
the "cookbook" files harder to maintain for use on different platforms.

So, I would appreciate any suggestions on how to accomplish option 2
above successfully.  Of course, any comments regarding option 1 are
welcome as well.

LEW

-- 
Larry Wagner, Agricultural Engineer | E-mail: wagner AT weru DOT ksu DOT edu
USDA-ARS Wind Erosion Research Unit | phone:  (785) 532-6807
Throckmorton Hall, KSU              | fax:    (785) 532-6528
Manhattan, KS 66506                 | URL:    http://www.weru.ksu.edu

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com