Home » Language IDEs » C / C++ IDE (CDT) » mingw/cdt
| mingw/cdt [message #148133] |
Mon, 04 July 2005 10:04  |
Eclipse User |
|
|
|
I was wondering if anyone could give me some help on how to get CDT to
work on Win2k with mingw.
I have Eclipse 3.1 and CDT 3.0 RC1 installed. when I creat a new
project I get this error:
"Error launching 'cygpath' command"
Thanks,
Lirong
|
|
| |
| Re: mingw/cdt [message #148144 is a reply to message #148141] |
Mon, 04 July 2005 20:25  |
| Eclipse User |
|
|
|
Hi,
Thank you for your reply. I installed cygwin and the problem is solved.
But... is the c++ compiler come with cygwin the same as the mingw one?
Thanks,
Lirong
Steffen Heinzl wrote:
> I have installed cygwin, which uses the mingw compiler, too (as far as I
> know). I got this error message when the path to c:\program files\cygwin\bin
> was not set in the environment.
> So you might try to add a folder to your PATH, which contains your make.exe,
> gcc.exe and so on. If that doesn't work, you can install cygwin, set the
> PATH and try again.
> Furthermore I added a new variable named MAKE to the environment which
> contains the location of the make file: c:\program
> files\cygwin\bin\make.exe.
>
> I hope this helps!
> Steffen
>
> "Li Lirong" <lirong@hotpop.com> schrieb im Newsbeitrag
> news:dabf8b$jjq$1@news.eclipse.org...
>
>>I was wondering if anyone could give me some help on how to get CDT to
>>work on Win2k with mingw.
>>
>>I have Eclipse 3.1 and CDT 3.0 RC1 installed. when I creat a new
>>project I get this error:
>>"Error launching 'cygpath' command"
>>
>>Thanks,
>>Lirong
>
>
>
|
|
|
| Re: mingw/cdt [message #148156 is a reply to message #148144] |
Tue, 05 July 2005 01:58 |
| Eclipse User |
|
|
|
Originally posted by: plankton.softwitch.net
they are Same as far as I know. anyway, I used mingw without cygwin for
some purpose. eclipse shows warning about cygpath(not error), but it
works. if you want to use mingw only, just ignore that warning.
Li Lirong wrote:
> Hi,
> Thank you for your reply. I installed cygwin and the problem is solved.
> But... is the c++ compiler come with cygwin the same as the mingw one?
>
> Thanks,
> Lirong
>
> Steffen Heinzl wrote:
>
>> I have installed cygwin, which uses the mingw compiler, too (as far as I
>> know). I got this error message when the path to c:\program
>> files\cygwin\bin
>> was not set in the environment.
>> So you might try to add a folder to your PATH, which contains your
>> make.exe,
>> gcc.exe and so on. If that doesn't work, you can install cygwin, set the
>> PATH and try again.
>> Furthermore I added a new variable named MAKE to the environment which
>> contains the location of the make file: c:\program
>> files\cygwin\bin\make.exe.
>>
>> I hope this helps!
>> Steffen
>>
>> "Li Lirong" <lirong@hotpop.com> schrieb im Newsbeitrag
>> news:dabf8b$jjq$1@news.eclipse.org...
>>
>>> I was wondering if anyone could give me some help on how to get CDT to
>>> work on Win2k with mingw.
>>>
>>> I have Eclipse 3.1 and CDT 3.0 RC1 installed. when I creat a new
>>> project I get this error:
>>> "Error launching 'cygpath' command"
>>>
>>> Thanks,
>>> Lirong
>>
>>
>>
>>
|
|
|
| Re: mingw/cdt [message #148181 is a reply to message #148156] |
Tue, 05 July 2005 10:40 |
| Eclipse User |
|
|
|
Originally posted by: dschaefer.rogers.com
Warning! They are *not* the same. Out of the box, the cygwin version of
gcc links in the cygwin set of DLLs that provide the "emulation" layer
that allows Linux APIs to work on Windows. These DLLs are GPL and the
licensing dictates that everything that loads them must be GPL as well.
However, the mingw compiler is there. Make sure you use -mno-cygwin as
an argument to your compile commands. The mingw compiler links in the
Microsoft C Runtime and has some emulation for some of the Linux APIs
but not a lot of them.
Cheers,
Doug
P.S. There is a bug open on the cygpath warning. You shouldn't need to
install cygwin to use MinGW/MSYS.
jiyul wrote:
> they are Same as far as I know. anyway, I used mingw without cygwin for
> some purpose. eclipse shows warning about cygpath(not error), but it
> works. if you want to use mingw only, just ignore that warning.
>
> Li Lirong wrote:
>
>> Hi,
>> Thank you for your reply. I installed cygwin and the problem is
>> solved. But... is the c++ compiler come with cygwin the same as the
>> mingw one?
>>
>> Thanks,
>> Lirong
>>
>> Steffen Heinzl wrote:
>>
>>> I have installed cygwin, which uses the mingw compiler, too (as far as I
>>> know). I got this error message when the path to c:\program
>>> files\cygwin\bin
>>> was not set in the environment.
>>> So you might try to add a folder to your PATH, which contains your
>>> make.exe,
>>> gcc.exe and so on. If that doesn't work, you can install cygwin, set the
>>> PATH and try again.
>>> Furthermore I added a new variable named MAKE to the environment which
>>> contains the location of the make file: c:\program
>>> files\cygwin\bin\make.exe.
>>>
>>> I hope this helps!
>>> Steffen
>>>
>>> "Li Lirong" <lirong@hotpop.com> schrieb im Newsbeitrag
>>> news:dabf8b$jjq$1@news.eclipse.org...
>>>
>>>> I was wondering if anyone could give me some help on how to get CDT to
>>>> work on Win2k with mingw.
>>>>
>>>> I have Eclipse 3.1 and CDT 3.0 RC1 installed. when I creat a new
>>>> project I get this error:
>>>> "Error launching 'cygpath' command"
>>>>
>>>> Thanks,
>>>> Lirong
>>>
>>>
>>>
>>>
>>>
--
Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa Lab
Kanata, Ontario, Canada
|
|
| |
| Re: mingw/cdt [message #148218 is a reply to message #148193] |
Tue, 05 July 2005 15:55 |
| Eclipse User |
|
|
|
Originally posted by: dschaefer.rogers.com
Yes, so far it seems to be harmless. I haven't found anything that
doesn't work.
Also, take a look at _mingw.h in /mingw/include. There is a
#undef __attribute__
that is screwing up a hack we have in the parser to handle
__attribute__. Simply commenting it out allows completion and search of
functions found in the header files.
Cheers,
Doug
Patrick Turley wrote:
> Doug Schaefer wrote:
>
>> Warning! They are *not* the same. Out of the box, the cygwin version
>> of gcc links in the cygwin set of DLLs that provide the "emulation"
>> layer that allows Linux APIs to work on Windows. These DLLs are GPL
>> and the licensing dictates that everything that loads them must be GPL
>> as well.
>>
>> However, the mingw compiler is there. Make sure you use -mno-cygwin as
>> an argument to your compile commands. The mingw compiler links in the
>> Microsoft C Runtime and has some emulation for some of the Linux APIs
>> but not a lot of them.
>>
>> Cheers,
>> Doug
>>
>> P.S. There is a bug open on the cygpath warning. You shouldn't need to
>> install cygwin to use MinGW/MSYS.
>
>
> Doug - thanks for the information. Just to be clear, are you saying
> that the cygpath warning is harmless? That is, things are working fine
> despite this warning?
--
Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa Lab
Kanata, Ontario, Canada
|
|
|
| Re: mingw/cdt [GPL licencing statement] [message #163380 is a reply to message #148218] |
Tue, 07 February 2006 14:29 |
| Eclipse User |
|
|
|
Originally posted by: chris.alex.thomas.gmail.com
just a small point, but.
linking against a DLL which is GPL, doesnt mean your code has to be GPL
also because it's a dynamic link, no code is copied into the executable
of your program, so you are not bound by the GPL. You are only bound by
the GPL if you statically link against a GPL library, which results in
parts of the GPL code being INSIDE your executable, or other parts of
code which are NOT GPL, in that case, you are in violation of the GPL.
But, if your proprietary, closed source codebase, opens a GPL licenced
DLL and accesses exported methods to perform functionality using the
dlopen or LoadLibrary type APIs, the codebase is NOT required to become GPL.
In simpler terms, your code is ONLY in violation of the GPL if you mix
your code and GPL code together, in that case, your code has to be GPL
also, but if you're code does NOT mix with GPL code, but uses it across
a DLL interface, from whatever platform you wish to use, you are free to
licence however you want.
HOWEVER, there is one exception here, that is if you link against a GPL
licenced DLL, but you use AN IMPORT library to do it instead of the
dlopen/LoadLibrary APIs, you are statically linking against a GPL import
library, subjecting your code to the GPL
Just thought I would clear that up, since I'm reading on a similar topic
and read that misinformation.
chris
Doug Schaefer wrote:
> Yes, so far it seems to be harmless. I haven't found anything that
> doesn't work.
>
> Also, take a look at _mingw.h in /mingw/include. There is a
>
> #undef __attribute__
>
> that is screwing up a hack we have in the parser to handle
> __attribute__. Simply commenting it out allows completion and search of
> functions found in the header files.
>
> Cheers,
> Doug
>
>
> Patrick Turley wrote:
>> Doug Schaefer wrote:
>>
>>> Warning! They are *not* the same. Out of the box, the cygwin version
>>> of gcc links in the cygwin set of DLLs that provide the "emulation"
>>> layer that allows Linux APIs to work on Windows. These DLLs are GPL
>>> and the licensing dictates that everything that loads them must be
>>> GPL as well.
>>>
>>> However, the mingw compiler is there. Make sure you use -mno-cygwin
>>> as an argument to your compile commands. The mingw compiler links in
>>> the Microsoft C Runtime and has some emulation for some of the Linux
>>> APIs but not a lot of them.
>>>
>>> Cheers,
>>> Doug
>>>
>>> P.S. There is a bug open on the cygpath warning. You shouldn't need
>>> to install cygwin to use MinGW/MSYS.
>>
>>
>> Doug - thanks for the information. Just to be clear, are you saying
>> that the cygpath warning is harmless? That is, things are working
>> fine despite this warning?
>
>
|
|
|
| Re: mingw/cdt [GPL licencing statement] [message #163407 is a reply to message #163380] |
Wed, 08 February 2006 01:08 |
| Eclipse User |
|
|
|
NO!
See http://www.gnu.org/licenses/gpl-faq.html#TOCMereAggregation where it
states:
+++++++++++++++++++++++
If modules are designed to run linked together in a shared address
space, that almost surely means combining them into one program.
+++++++++++++++++++++++
Also, http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins says
+++++++++++++++++++++++
"Can I release a non-free program that's designed to load a GPL-covered
plug-in?"
It depends on how the program invokes its plug-ins. If the program uses
fork and exec to invoke plug-ins, then the plug-ins are separate
programs, so the license of the plug-in makes no requirements about the
main program.
If the program dynamically links[*] plug-ins, and they make function
calls to each other and share data structures, we believe they form a
single program, which must be treated as an extension of both the main
program and the plug-ins. In order to use the GPL-covered plug-ins, the
main program must be released under the GPL or a GPL-compatible free
software license, and that the terms of the GPL must be followed when
the main program is distributed for use with these plug-ins.
If the program dynamically links plug-ins, but the communication between
them is limited to invoking the `main' function of the plug-in with some
options and waiting for it to return, that is a borderline case."
+++++++++++++++++++++++
[*] note that here, "dynamically links" refers to runtime
dlopen/LoadLibrary dynamic linking. The sort of dynamic linking
involved when using import libraries [whether explicitly or created
on-the-fly by ld.exe] is covered by the "shared address space" concept.
Thus, your application code + my GPL DLL == one program in a shared
address space. Also, since this topic arose specifically with respect
to the cygwin1.dll, why don't we see what
http://cygwin.com/licensing.html says?
+++++++++++++++++++++++
The Cygwin API library found in the winsup subdirectory of the source
code is also covered by the GNU GPL (with exceptions; see below). By
default, all executables link against this library (and in the process
include GPL'd Cygwin glue code). This means that unless you modify the
tools so that compiled executables do not make use of the Cygwin
library, your compiled programs will also have to be free software
distributed under the GPL with source code available to all.
+++++++++++++++++++++++
The exception referred to above is that any *open source*
(http://www.opensource.org/docs/definition_plain.html) application code
may be linked against the cygwin1.dll and redistributed under the
application's original open source license, and not specifically the
GPL. Proprietary application code is right out, unless you purchase a
proprietary cygwin license from http://www.redhat.com/software/cygwin/
Christopher Thomas wrote:
> just a small point, but.
>
> linking against a DLL which is GPL, doesnt mean your code has to be GPL
> also because it's a dynamic link, no code is copied into the executable
> of your program, so you are not bound by the GPL. You are only bound by
> the GPL if you statically link against a GPL library, which results in
> parts of the GPL code being INSIDE your executable, or other parts of
> code which are NOT GPL, in that case, you are in violation of the GPL.
>
> But, if your proprietary, closed source codebase, opens a GPL licenced
> DLL and accesses exported methods to perform functionality using the
> dlopen or LoadLibrary type APIs, the codebase is NOT required to become
> GPL.
No, this is wrong. See the "shared address space" above. (Also,
specifically in the cygwin case, how exactly are you going to use the
dlopen() methods exported by cygwin1.dll without linking to the glue
code in libcygwin.a?)
> In simpler terms, your code is ONLY in violation of the GPL if you mix
> your code and GPL code together, in that case, your code has to be GPL
> also, but if you're code does NOT mix with GPL code, but uses it across
> a DLL interface, from whatever platform you wish to use, you are free to
> licence however you want.
>
> HOWEVER, there is one exception here, that is if you link against a GPL
> licenced DLL, but you use AN IMPORT library to do it instead of the
> dlopen/LoadLibrary APIs, you are statically linking against a GPL import
> library, subjecting your code to the GPL
No, this has nothing to do with it. ld can link directly to the DLL as
if an import library were used (by generating the code thunks on-the-fly
at link time). In this case, you'd STILL be subject to the GPL, because
your program is a single address space that contains both your app and
the linked-to GPL'ed library. As the GPL FAQ says, the question is
really: do the non-GPL and GPL components communicate "at arms length".
Using a fat API is intimate; using a skinny API is borderline;
fork/exec is OK.
> Just thought I would clear that up, since I'm reading on a similar topic
> and read that misinformation.
It's not misinformation. It's accurate, as detailed in the GPL FAQ.
Further, in the specific case that caused this topic to arise on this
thread, it's also accurate with respect to cygwin1.dll. No linkee
non-Open-Source-software to cygwin1.dll.
--
Chuck
|
|
|
Goto Forum:
Current Time: Thu Jul 17 02:15:28 EDT 2025
Powered by FUDForum. Page generated in 0.32154 seconds |
Home