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: issues compiling and migrating exe / dll files

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).

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: Problem reports: Documentation: FAQ:

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