Re: Visual Studio linking

Re: Visual Studio linking

[Daniel Starin]

Hi.

	I am also trying to use functions implemented in cygwin1.dll with
Visual Studio as discussed below.  After started a blank console application
and following steps below, I get to linking which gives me the following
error:

Linking...
LIBCMTD.lib(crt0.obj) : error LNK2005: _mainCRTStartup already defined in
crt0.obj

Any suggestions?

Thanks,

Dan

---------------------------------------------------------------
From http://www.cygwin.com/ml/cygwin/2004-06/msg00274.html
And Faq...

To all those who said it couldn't be done...I've done it :)

Hahahaha.

Seriously, it is quite easy once you figure it out, and I am sure there are
plenty of people who helped write Cygwin who probably knew but couldn't be
bothered to tell me.

It involves a couple of minor hacks. It would be nice if cygwin1.dll could
export the cygwin_crt0() function.

Here is how you do it:

1) Use the impdef program to generate a .def file for the cygwin1.dll
    impdef cygwin1.dll > cygwin1.def

2) Use the MS VS linker (lib) to generate an import library
    lib /def=cygwin1.def /out=cygwin1.lib

3) Create a file "my_crt0.c" with the following contents
  
#include <sys/cygwin.h>
#include <stdlib.h>

typedef int (*MainFunc) (int argc, char *argv[], char **env);

void
my_crt0 (MainFunc f)
{
  cygwin_crt0(f);
}

4) Use gcc in a Cygwin prompt to build my_crt0.c into a DLL (e.g.
my_crt0.dll). Follow steps 1 and 2 to generate .def and .lib files for the
DLL.

5) Download crt0.c from the cygwin website and include it in your sources.
Modify it to call my_crt0() instead of cygwin_crt0().

6) Build your object files using the MS VC compiler cl.

7) Link your object files, cygwin1.lib, and my_crt0.lib (or whatever you
called it) into the executable.

Note that if you are using any other Cygwin based libraries that you will
probably need to build them as DLLs using gcc and then generate import
libraries for the MS VC linker.

Alastair.


--
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/

Re: Visual Studio linking

[Larry Hall]

At 05:39 PM 12/12/2004, you wrote:
>Hi.
>
>    I am also trying to use functions implemented in cygwin1.dll with
>Visual Studio as discussed below.  After started a blank console application
>and following steps below, I get to linking which gives me the following
>error:
>
>Linking...
>LIBCMTD.lib(crt0.obj) : error LNK2005: _mainCRTStartup already defined in
>crt0.obj
>
>Any suggestions?


Sure.  Duck and run!  

You're clearly getting both the Cygwin and MS C run times linked in, which
suggests you're using functionality from both.  This can be dangerous in
the extreme if you don't know what you're doing.  In your particular case, 
you end up trying to link against CRT initialization routines from both
libraries, which is clearly a recipe for disaster if it's not handled 
correctly.  Doing this type of thing as the series of steps provided is no
better than a work-around.  It may work.  It may not.  If Alastair is willing 
to help you out with your case, that's great.  But you should be warned 
that his approach isn't supported.  Use it at your own risk.  We're still
looking for someone who's interested enough in this subject to re-enable 
automatic support for this in the Cygwin DLL itself.  But it's been years
since it worked and the level of interest by anyone on this list has never 
produced results unfortunately...


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


--
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/

RE: Visual Studio linking

[Daniel Starin]

So, I realized I had the compile option "Use Managed Extensions" on in VS
.NET and that was causing the problem.  Now that I can include the libs in
my project, are there any header files that I can include from Visual Studio
to use them?...

When I include <pthread.h> from the cygwin/usr/include directory, for
example, I get errors like this...

test4.cpp
C:\cygwin\usr\include\sys\_types.h(15) : error C2144: syntax error :
'__int64' should be preceded by ';'
C:\cygwin\usr\include\sys\_types.h(15) : error C2501: '__extension__' :
missing storage-class or type specifiers
.....

Thanks,

Dan

-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of
Larry Hall
Sent: Sunday, December 12, 2004 5:51 PM
To: Daniel Starin; cygwin@cygwin.com
Cc: alastair.growcott@bakbone.co.uk
Subject: Re: Visual Studio linking

At 05:39 PM 12/12/2004, you wrote:
>Hi.
>
>    I am also trying to use functions implemented in cygwin1.dll with
>Visual Studio as discussed below.  After started a blank console
application
>and following steps below, I get to linking which gives me the following
>error:
>
>Linking...
>LIBCMTD.lib(crt0.obj) : error LNK2005: _mainCRTStartup already defined in
>crt0.obj
>
>Any suggestions?


Sure.  Duck and run!  

You're clearly getting both the Cygwin and MS C run times linked in, which
suggests you're using functionality from both.  This can be dangerous in
the extreme if you don't know what you're doing.  In your particular case, 
you end up trying to link against CRT initialization routines from both
libraries, which is clearly a recipe for disaster if it's not handled 
correctly.  Doing this type of thing as the series of steps provided is no
better than a work-around.  It may work.  It may not.  If Alastair is
willing 
to help you out with your case, that's great.  But you should be warned 
that his approach isn't supported.  Use it at your own risk.  We're still
looking for someone who's interested enough in this subject to re-enable 
automatic support for this in the Cygwin DLL itself.  But it's been years
since it worked and the level of interest by anyone on this list has never 
produced results unfortunately...


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


--
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/


--
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/

RE: Visual Studio linking

[Larry Hall]

At 04:36 PM 12/17/2004, you wrote:
>So, I realized I had the compile option "Use Managed Extensions" on in VS
>.NET and that was causing the problem.  


Really.  That was it?  Well, that's pretty non-intuitive.  Nice job finding 
that.


>Now that I can include the libs in
>my project, are there any header files that I can include from Visual Studio
>to use them?...


I doubt it.  Cygwin provides POSIX APIs that VS doesn't so the mere existence
of Cygwin indicates that there's not going to be such an overlap.  Also, 
Cygwin's header files are it's own.  It's not a big surprise that they 
contain specific info that's not understood by VS.  The reverse is also 
true.  You'll need to build your own set of function declarations and 
needed symbols, etc.


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


--
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/

Visual Studio linking

[Alastair Growcott]

Hi.

I have read all the FAQs and stuff. I have searched the web. I would like a step by step list of instructions to achieve the following.

I want to use check to test an MFC application. This means I must use the Visual Studio compiler, cl, and linker, link.
Check calls fork(). This function is implemented in the cygwin1.dll.
I cannot link using the DLL. I read somewhere that libcygwin.a is equivalent to the cygwin1.lib, but when I try and link against it I get all sorts of bizarre symbols not found. According to cygcheck, cygwin1.dll only has dependencies on standard Windows DLLs that I am already linking against.

So how do I;

a) obtain a version of cygwin1.lib that I can link against using the Visual Studio linker that will work nicely and neatly, or
b) link against libcygwin.a using the Visual Studio linker.

 
Alastair Growcott
Software Maintenance Engineer

BakBone Software
Merck House
Seldown Lane
Poole, BH15 1TW
P +44 (0)1202 241000
F +44 (0)1202 249000
alastair.growcott@bakbone.com
www.bakbone.com
> 


--
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/

Re: Visual Studio linking

[Max Bowsher]

Alastair Growcott wrote:
> Hi.
>
> I have read all the FAQs and stuff. I have searched the web. I would like
a
> step by step list of instructions to achieve the following.
>
> I want to use check to test an MFC application. This means I must use the
> Visual Studio compiler, cl, and linker, link.
> Check calls fork(). This function is implemented in the cygwin1.dll.
> I cannot link using the DLL. I read somewhere that libcygwin.a is
equivalent
> to the cygwin1.lib, but when I try and link against it I get all sorts of
> bizarre symbols not found. According to cygcheck, cygwin1.dll only has
> dependencies on standard Windows DLLs that I am already linking against.
>
> So how do I;
>
> a) obtain a version of cygwin1.lib that I can link against using the
Visual
> Studio linker that will work nicely and neatly, or
> b) link against libcygwin.a using the Visual Studio linker.

I don't think anyone has ever done this before, so I doubt very much whether
what you are looking for exists.

If you are serious about doing this, you will likely need to figure it out
yourself, assuming of course, that it actually is possible at all.

Max.


--
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/

Re[2]: Visual Studio linking

[Alastair Growcott]

So far so good - not.

I am trying to link against the lib*.a files using the Visual Studio linker, and it seems to accept them. However I do get the following warning;

    libcygwin.a(d001126.o) : warning LNK4078: multiple '.text' sections found with different attributes (E0000020)

Moreover when I try and run the executable, absolutely nothing happens.

Now I remember reading somewhere that MSVCRT.DLL and cygwin1.dll are mutually exclusive, so I flange my makefile to add /NODEFAULTLIB on the link line. I now get the additional message;

    LINK : error LNK2001: unresolved external symbol _mainCRTStartup

I know this is simple to fix, but my brain has just gone to sleep - any tips?

Alastair.


On Wed, 2 Jun 2004 09:51:52 +0100 Max Bowsher <maxb@ukf.net> wrote:

> Alastair Growcott wrote:
> > Hi.
> >
> > I have read all the FAQs and stuff. I have searched the web. I would like
> a
> > step by step list of instructions to achieve the following.
> >
> > I want to use check to test an MFC application. This means I must use the
> > Visual Studio compiler, cl, and linker, link.
> > Check calls fork(). This function is implemented in the cygwin1.dll.
> > I cannot link using the DLL. I read somewhere that libcygwin.a is
> equivalent
> > to the cygwin1.lib, but when I try and link against it I get all sorts of
> > bizarre symbols not found. According to cygcheck, cygwin1.dll only has
> > dependencies on standard Windows DLLs that I am already linking against.
> >
> > So how do I;
> >
> > a) obtain a version of cygwin1.lib that I can link against using the
> Visual
> > Studio linker that will work nicely and neatly, or
> > b) link against libcygwin.a using the Visual Studio linker.
> 
> I don't think anyone has ever done this before, so I doubt very much whether
> what you are looking for exists.
> 
> If you are serious about doing this, you will likely need to figure it out
> yourself, assuming of course, that it actually is possible at all.
> 
> Max.
> 
> 




--
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/

Re[3]: Visual Studio linking

[Alastair Growcott]

Ok, so progress so far. By the way, a main reason I am posting this stuff is so that in future anyone trying the same can search the archives and find all these posts. If anyone reads it and actually helps me, that would be a bonus :)

I now have what seems to be a proper import library for cygwin1.dll. I am stuck as to what  entry point I should specify. I expected cygwin1.dll to implement mainCRTStartup, and have seen guides that suggest that when compiling programs under cygwin using gcc, that you should specify manCRTStartup as the entry point with the -e option.

I have found that crt0.o implements mainCRTStartup(). Can anyone tell me what crt0.o is for? However when I take that as well it then demands a symbol _cygwin_crt0 which is defined in libc.a. If I take libc.a as well then I get loads of undefined symbols which seem to be defined in libgcc.a somehow.

If I specify main() as my entry point, I get it to compile with only those warnings about the wrong attributes on the .text sections. However when I try and run it, it just hangs. Running it through gdb and breaking it gives me the following stack;

0x7c5b9a91 in UnregisterConsoleIME ()
   from /cygdrive/c/WINNT/system32/KERNEL32.DLL

Of course, this is probably wrong.

I suspect that some of the people who wrote Cygwin could probably tell me exactly what I need to do or why it is impossible and save me stumbling around blindly like this. The question is, do they read this mailing list?


Alastair.


On Wed, 2 Jun 2004 10:17:18 +0100 (GMT Daylight Time) Alastair Growcott <Alastair.Growcott@bakbone.co.uk> wrote:

> So far so good - not.
> 
> I am trying to link against the lib*.a files using the Visual Studio linker, and it seems to accept them. However I do get the following warning;
> 
>     libcygwin.a(d001126.o) : warning LNK4078: multiple '.text' sections found with different attributes (E0000020)
> 
> Moreover when I try and run the executable, absolutely nothing happens.
> 
> Now I remember reading somewhere that MSVCRT.DLL and cygwin1.dll are mutually exclusive, so I flange my makefile to add /NODEFAULTLIB on the link line. I now get the additional message;
> 
>     LINK : error LNK2001: unresolved external symbol _mainCRTStartup
> 
> I know this is simple to fix, but my brain has just gone to sleep - any tips?
> 
> Alastair.
> 
> 
> On Wed, 2 Jun 2004 09:51:52 +0100 Max Bowsher <maxb@ukf.net> wrote:
> 
> > Alastair Growcott wrote:
> > > Hi.
> > >
> > > I have read all the FAQs and stuff. I have searched the web. I would like
> > a
> > > step by step list of instructions to achieve the following.
> > >
> > > I want to use check to test an MFC application. This means I must use the
> > > Visual Studio compiler, cl, and linker, link.
> > > Check calls fork(). This function is implemented in the cygwin1.dll.
> > > I cannot link using the DLL. I read somewhere that libcygwin.a is
> > equivalent
> > > to the cygwin1.lib, but when I try and link against it I get all sorts of
> > > bizarre symbols not found. According to cygcheck, cygwin1.dll only has
> > > dependencies on standard Windows DLLs that I am already linking against.
> > >
> > > So how do I;
> > >
> > > a) obtain a version of cygwin1.lib that I can link against using the
> > Visual
> > > Studio linker that will work nicely and neatly, or
> > > b) link against libcygwin.a using the Visual Studio linker.
> > 
> > I don't think anyone has ever done this before, so I doubt very much whether
> > what you are looking for exists.
> > 
> > If you are serious about doing this, you will likely need to figure it out
> > yourself, assuming of course, that it actually is possible at all.
> > 
> > Max.
> > 
> > 
> 
> 
> 
> 


-- 
Alastair Growcott
Software Maintenance Engineer

BakBone Software
Merck House
Seldown Lane
Poole, BH15 1TW
P +44 (0)1202 241000
F +44 (0)1202 249000
alastair.growcott@bakbone.com
www.bakbone.com
> 


--
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/

Re[4]: Visual Studio linking

[Alastair Growcott]

Conclusions:

I cannot link to a "*.a" library using the Windows linker. This is because these libraries are built with a dependency on the symbol __data_start__ which is a gcc construct.

If I can figure out the correct entry point then I can link to my manufactured cygwin DLL import library which seems to contain most of the contents of libc.

I cannot use crt0.o with my import library because it does not define _cygwin_crt0 which crt0.o is dependent on.

I could try building a DLL which wraps a library that supports either _cygwin_crt0 and then create an import library, but suspect this would not work.

I could try building crt0.o into a DLL and generate an import library for that. This might work.

I could get the source code for both crt0.o and cygwin_crt0() and build it into a DLL or link compatible static library. This might also work, but is more difficult.

Alastair.


On Wed, 2 Jun 2004 13:15:24 +0100 (GMT Daylight Time) Alastair Growcott <Alastair.Growcott@bakbone.co.uk> wrote:

> Ok, so progress so far. By the way, a main reason I am posting this stuff is so that in future anyone trying the same can search the archives and find all these posts. If anyone reads it and actually helps me, that would be a bonus :)
> 
> I now have what seems to be a proper import library for cygwin1.dll. I am stuck as to what  entry point I should specify. I expected cygwin1.dll to implement mainCRTStartup, and have seen guides that suggest that when compiling programs under cygwin using gcc, that you should specify manCRTStartup as the entry point with the -e option.
> 
> I have found that crt0.o implements mainCRTStartup(). Can anyone tell me what crt0.o is for? However when I take that as well it then demands a symbol _cygwin_crt0 which is defined in libc.a. If I take libc.a as well then I get loads of undefined symbols which seem to be defined in libgcc.a somehow.
> 
> If I specify main() as my entry point, I get it to compile with only those warnings about the wrong attributes on the .text sections. However when I try and run it, it just hangs. Running it through gdb and breaking it gives me the following stack;
> 
> 0x7c5b9a91 in UnregisterConsoleIME ()
>    from /cygdrive/c/WINNT/system32/KERNEL32.DLL
> 
> Of course, this is probably wrong.
> 
> I suspect that some of the people who wrote Cygwin could probably tell me exactly what I need to do or why it is impossible and save me stumbling around blindly like this. The question is, do they read this mailing list?
> 
> 
> Alastair.
> 
> 
> On Wed, 2 Jun 2004 10:17:18 +0100 (GMT Daylight Time) Alastair Growcott <Alastair.Growcott@bakbone.co.uk> wrote:
> 
> > So far so good - not.
> > 
> > I am trying to link against the lib*.a files using the Visual Studio linker, and it seems to accept them. However I do get the following warning;
> > 
> >     libcygwin.a(d001126.o) : warning LNK4078: multiple '.text' sections found with different attributes (E0000020)
> > 
> > Moreover when I try and run the executable, absolutely nothing happens.
> > 
> > Now I remember reading somewhere that MSVCRT.DLL and cygwin1.dll are mutually exclusive, so I flange my makefile to add /NODEFAULTLIB on the link line. I now get the additional message;
> > 
> >     LINK : error LNK2001: unresolved external symbol _mainCRTStartup
> > 
> > I know this is simple to fix, but my brain has just gone to sleep - any tips?
> > 
> > Alastair.
> > 
> > 
> > On Wed, 2 Jun 2004 09:51:52 +0100 Max Bowsher <maxb@ukf.net> wrote:
> > 
> > > Alastair Growcott wrote:
> > > > Hi.
> > > >
> > > > I have read all the FAQs and stuff. I have searched the web. I would like
> > > a
> > > > step by step list of instructions to achieve the following.
> > > >
> > > > I want to use check to test an MFC application. This means I must use the
> > > > Visual Studio compiler, cl, and linker, link.
> > > > Check calls fork(). This function is implemented in the cygwin1.dll.
> > > > I cannot link using the DLL. I read somewhere that libcygwin.a is
> > > equivalent
> > > > to the cygwin1.lib, but when I try and link against it I get all sorts of
> > > > bizarre symbols not found. According to cygcheck, cygwin1.dll only has
> > > > dependencies on standard Windows DLLs that I am already linking against.
> > > >
> > > > So how do I;
> > > >
> > > > a) obtain a version of cygwin1.lib that I can link against using the
> > > Visual
> > > > Studio linker that will work nicely and neatly, or
> > > > b) link against libcygwin.a using the Visual Studio linker.
> > > 
> > > I don't think anyone has ever done this before, so I doubt very much whether
> > > what you are looking for exists.
> > > 
> > > If you are serious about doing this, you will likely need to figure it out
> > > yourself, assuming of course, that it actually is possible at all.
> > > 
> > > Max.
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> -- 
> Alastair Growcott
> Software Maintenance Engineer
> 
> BakBone Software
> Merck House
> Seldown Lane
> Poole, BH15 1TW
> P +44 (0)1202 241000
> F +44 (0)1202 249000
> alastair.growcott@bakbone.com
> www.bakbone.com
> > 
> 
> 


-- 
Alastair Growcott
Software Maintenance Engineer

BakBone Software
Merck House
Seldown Lane
Poole, BH15 1TW
P +44 (0)1202 241000
F +44 (0)1202 249000
alastair.growcott@bakbone.com
www.bakbone.com
> 


--
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/

Re[5]: Visual Studio linking

[Alastair Growcott]

To all those who said it couldn't be done...I've done it :)

Hahahaha.

Seriously, it is quite easy once you figure it out, and I am sure there are plenty of people who helped write Cygwin who probably knew but couldn't be bothered to tell me.

It involves a couple of minor hacks. It would be nice if cygwin1.dll could export the cygwin_crt0() function.

Here is how you do it:

1) Use the impdef program to generate a .def file for the cygwin1.dll
    impdef cygwin1.dll > cygwin1.def

2) Use the MS VS linker (lib) to generate an import library
    lib /def=cygwin1.def /out=cygwin1.lib

3) Create a file "my_crt0.c" with the following contents
  
#include <sys/cygwin.h>
#include <stdlib.h>

typedef int (*MainFunc) (int argc, char *argv[], char **env);

void
my_crt0 (MainFunc f)
{
  cygwin_crt0(f);
}

4) Use gcc in a Cygwin prompt to build my_crt0.c into a DLL (e.g. my_crt0.dll). Follow steps 1 and 2 to generate .def and .lib files for the DLL.

5) Download crt0.c from the cygwin website and include it in your sources. Modify it to call my_crt0() instead of cygwin_crt0().

6) Build your object files using the MS VC compiler cl.

7) Link your object files, cygwin1.lib, and my_crt0.lib (or whatever you called it) into the executable.

Note that if you are using any other Cygwin based libraries that you will probably need to build them as DLLs using gcc and then generate import libraries for the MS VC linker.

Alastair.





--
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/

Re: Visual Studio linking

[Christopher Faylor]

On Mon, Jun 07, 2004 at 03:38:21PM +0100, Alastair Growcott wrote:
>Seriously, it is quite easy once you figure it out, and I am sure there
>are plenty of people who helped write Cygwin who probably knew but
>couldn't be bothered to tell me.

Well, we are all just very mean.

>It involves a couple of minor hacks.  It would be nice if cygwin1.dll
>could export the cygwin_crt0() function.
>
>Here is how you do it:
>
>1) Use the impdef program to generate a .def file for the cygwin1.dll
>impdef cygwin1.dll > cygwin1.def

A .def file is generated for cygwin when the DLL is built, actually.

>4) Use gcc in a Cygwin prompt to build my_crt0.c into a DLL (e.g.
>my_crt0.dll).  Follow steps 1 and 2 to generate .def and .lib files for
>the DLL.
>
>5) Download crt0.c from the cygwin website and include it in your
>sources.  Modify it to call my_crt0() instead of cygwin_crt0().

5a) Modify the license of your program to the GNU General Public
License, since your binary has now become GPLed, meaning that you must
now offer the source code to your sources under the terms of the GPL.

cgf

--
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/

Re[2]: Visual Studio linking

[Alastair Growcott]

> A .def file is generated for cygwin when the DLL is built, actually.


I'm not building the Cygwin dll, so I need this step.


> 5a) Modify the license of your program to the GNU General Public
> License, since your binary has now become GPLed, meaning that you must
> now offer the source code to your sources under the terms of the GPL.


My program is non-distributable. I am using it to run unit tests internally.

I thought that, under the terms of the GPL, if my binary links dynamically to the Cygwin DLL, I do NOT have to offer my source code up, I only need to ensure that people can use my software against future (or past) versions of Cygwin by rebuilding the DLL themselves. This includes either distributing the Cygwin DLL source code or ditributing a link to somewhere they can obtain it.

Or is that the lesser GPL?

Surely the source code will not be GPL'ed if I do not make it or the binary publically available!


Alastair.



--
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/

Re: Visual Studio linking

[Christopher Faylor]

On Mon, Jun 07, 2004 at 05:13:25PM +0100, Alastair Growcott wrote:
>>A .def file is generated for cygwin when the DLL is built, actually.
>
>I'm not building the Cygwin dll, so I need this step.
>
>>5a) Modify the license of your program to the GNU General Public
>>License, since your binary has now become GPLed, meaning that you must
>>now offer the source code to your sources under the terms of the GPL.
>
>My program is non-distributable.  I am using it to run unit tests
>internally.
>
>I thought that, under the terms of the GPL, if my binary links
>dynamically to the Cygwin DLL, I do NOT have to offer my source code
>up, I only need to ensure that people can use my software against
>future (or past) versions of Cygwin by rebuilding the DLL themselves.
>This includes either distributing the Cygwin DLL source code or
>ditributing a link to somewhere they can obtain it.

>>5) Download crt0.c from the cygwin website and include it in your
>>sources.  Modify it to call my_crt0() instead of cygwin_crt0().

You're including crt0.c in your source code.  That's not linking
dynamically.  You are also using a .def file for your linking rather
than calling LoadLibrary and cousins.

AFAICT, you aren't doing anything differently from what a normal build
of a binary using gcc and would do.

>Or is that the lesser GPL?
>
>Surely the source code will not be GPL'ed if I do not make it or the
>binary publically available!

I suspect that you probably haven't read the GPL FAQ.  This section
is probably pertinent:

http://www.gnu.org/licenses/gpl-faq.html#TOCGPLRequireSourcePostedPublic

but the rest should make interesting reading as well.

cgf

--
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/

RE: Visual Studio linking

[Alastair Growcott]

Thankyou.

Actually my source is testing a library, so if I did distribute the test
programs, I would only have to make the code for the test programs and not
the code for the libraries available (dynamic linking to the libraries).

Alastair.


-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
Of Christopher Faylor
Sent: 07 June 2004 17:25
To: cygwin@cygwin.com
Subject: Re: Visual Studio linking


On Mon, Jun 07, 2004 at 05:13:25PM +0100, Alastair Growcott wrote:
>>A .def file is generated for cygwin when the DLL is built, actually.
>
>I'm not building the Cygwin dll, so I need this step.
>
>>5a) Modify the license of your program to the GNU General Public
>>License, since your binary has now become GPLed, meaning that you must
>>now offer the source code to your sources under the terms of the GPL.
>
>My program is non-distributable.  I am using it to run unit tests
>internally.
>
>I thought that, under the terms of the GPL, if my binary links
>dynamically to the Cygwin DLL, I do NOT have to offer my source code
>up, I only need to ensure that people can use my software against
>future (or past) versions of Cygwin by rebuilding the DLL themselves.
>This includes either distributing the Cygwin DLL source code or
>ditributing a link to somewhere they can obtain it.

>>5) Download crt0.c from the cygwin website and include it in your
>>sources.  Modify it to call my_crt0() instead of cygwin_crt0().

You're including crt0.c in your source code.  That's not linking
dynamically.  You are also using a .def file for your linking rather
than calling LoadLibrary and cousins.

AFAICT, you aren't doing anything differently from what a normal build
of a binary using gcc and would do.

>Or is that the lesser GPL?
>
>Surely the source code will not be GPL'ed if I do not make it or the
>binary publically available!

I suspect that you probably haven't read the GPL FAQ.  This section
is probably pertinent:

http://www.gnu.org/licenses/gpl-faq.html#TOCGPLRequireSourcePostedPublic

but the rest should make interesting reading as well.

cgf

--
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/


--
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/

Re: Visual Studio linking

[Christopher Faylor]

On Tue, Jun 08, 2004 at 10:02:08AM +0100, Alastair Growcott wrote:
>Actually my source is testing a library, so if I did distribute the
>test programs, I would only have to make the code for the test programs
>and not the code for the libraries available (dynamic linking to the
>libraries).

As long as you don't release the cygwin DLL...  If you do, you need to
provide sources, too.

cgf

--
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/