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/
