On Jan 22 17:25, jano trouba wrote: > >If you create static libs which don't use Cygwin functions, then you're > >build native Windows libs. That's no problem and has nothing to do with > >Cygwin anymore. You're off the hook. > > > >If you build static libs which use Cygwin functions, your application > >will be invariably linked against the Cygwin DLL. If you do this, your > >application has to be either OSS software, or you have to purchase the > >Cygwin buyout license, which is the only way to allow your application > >stay proprietary. For more details see the licensing web page > >http://cygwin.com/licensing.html. If you need more information about > >the Cygwin buyout license, contact Red Hat as described on that web page. > [...] > > OK. But what are cygwin functions ?
You should really read the user's guide first: http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html Assume you use a Cygwin installation. You build the following application: $ cat > hello.c << EOF #include <stdio.h> int main() { printf ("hello, world\n"); } EOF using Cygwin's gcc: $ gcc -o hello hello.c Then you're linking your application against the Cygwin DLL and the Cygwin DLL is necessary to run the application. If you distribute this application to your customers, you have to provide the source code to them or purchase the Cygwin buyout license. You can avoid linking against the Cygwin DLL by telling gcc: $ gcc -mno-cygwin -o hello hello.c That applikcation is a native Windows application. It does not use the Cygwin DLL, only native Windows DLLs and the MingW C-runtime which does not enforce the GPL. However, when you do that and have further questions, you're on the wrong mailing list here. This mailing list is dedicated to Cygwin and applications build for Cygwin. > >> As for the technical part, I read the FAQ's and I could not find an > >answer > >> about the sockets ... > > > >If you build your libs using Cygwin socket functions, you should use > >them as on every POSIX system. Especially asynchronous sockets are > >rather outdated and should not be used anymore. > > > > What's in use now ?? I have the original HTTP code and use it.. Is that > wrong ???????? Sorry, I mistreated the term asynchronous. What I really meant was signal driven I/O (SIGIO). Asynchronous I/O in the POSIX sense (aio_xxx functions) is not implemented in Cygwin. > >If you don't link against Cygwin socket functions but against native > >WinSock socket functions, you're using Windows semantics. > > > >"When in Sparta, do as the Spartans do" ;) > > > > Yes that's why I was asking the question... Because this is the bottom > part of the application, and thus I'd like to avoid rewriting the HTTP code > with Winsocks.... But I might be obliged to do so... Linking as shown with the first hello example above links against Cygwin, thus linking against Cygwin socket functions. Linking with -mno-cygwin does not link against Cygwin, thus requiring to use Winsock sockets. > >Question e) is not a Cygwin question so you should ask it on a mailing > >list dedicated to native Windows development, or search Microsoft's > >documentation: http://msdn.microsoft.com/ > > How come ? I perused through several developers forums, and found some > praise about cygwin as a good way of porting Linux applications to Windows. Well, the Cygwin mailing list is a Cygwin mailing list. If you're talking about native Windows problems, it's the wrong mailing list. If you ask how to start an application as Windows service with Cygwin, you're on the right mailing list. If you're asking how to start an application as Windows service without using Cygwin, you're on the wrong mailing list. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
