To: cygwin AT cygwin DOT com
From: Matthew Woehlke <mw_triad AT users DOT sourceforge DOT net>
Subject:  Re: issues compiling and migrating exe / dll files
Date:  Wed, 05 Nov 2008 14:54:34 -0600
Lines: 62
Message-ID: <get16e$gjj$1@ger.gmane.org>
References:  <20081105203749 DOT D40FC1A0039 AT smtp DOT hushmail DOT com>
Mime-Version:  1.0
Content-Type:  text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding:  7bit
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.16) Gecko/20080723 Fedora/2.0.0.16-1.fc9 Thunderbird/2.0.0.16 Mnenhy/0.7.5.0
In-Reply-To: <20081105203749.D40FC1A0039@smtp.hushmail.com>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Scott Thompson wrote:
> Hi all.  I'm trying to do the following and running into some 
> problems:
> 
> 1.  Install cygwin on a host computer (works).
> 2.  Compile a set of binaries and dll's using gcc/make (works).
> 3.  Sanity check that the binaries actually run and execute 
> properly (works).
> 4.  Zip the compiled binaries and dlls, then unzip on a different 
> cygwin install (works).
> 5.  Run the compiled binaries (some of which use the dll's) (does 
> not work on some systems).
> 
> Instead of working , the claim is that the binary actually ends 
> execution and does not show up in the running process list through 
> cygwin (ps -ef).  The exectuable in question does call the 'daemon' 
> system call, which may or may not be the source of trouble here.

What's the exit status? Have you tried running it under gdb? (Have you 
performed the very basic step of running 'cygcheck myapp.exe' to see if 
you are missing any libraries?)

> Aside from removing that daemon call and running in the foreground, 
> the only other options I can think of would be to provide the full 
> source package and have the end user compile the package 
> themselves; however, would prefer to only hand out binaries in this 
> case if I can help it.

I think that by the above you really mean you want the convenience of 
handing the users a ready-made binary, not that you are unwilling to 
distribute the source (which, because you are linking against Cygwin, is 
required by the GPL), correct? Probably I am just nitpicking your use of 
the word "only", but IMO it's worth making sure :-).

> Questions for this list:
> 1 -- is the migration method used above supported by cygwin?

If you're building on a system where all dependencies are at least as 
old as on the target system, I think this should work. I don't know 
about "official support", but if it doesn't work, that's like saying 
that if you run update on the build system, the program won't run any 
more. IOW, backwards compatibility usually works.

> 2 -- any idea what can cause the termination of a program in this 
> manner?

Using a too-old library?

> 3 -- any other thoughts?

I would run 'cygcheck -s' on both machines and compare the outputs, 
looking especially for any packages that are older than those on the 
build system (or that are on the build system, but not the target system).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"NT was a marketing name that stood for New Technology, but it was still 
an amusing coincidence that WNT was VMS with each letter replaced by the 
next one."
   -- Jeremy Reimer


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