Some MinGW basics

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Some MinGW basics

John Emmas
I'm in the final stages of converting a large Linux app to run on Windows.  Through personal preference I'm building with Visual C++ but I'd like to keep the source code so that it's still buildable with gcc - whether on Linux, Cygwin, MinGW or whatever.

Linux and Cygwin aren't a problem because I have both at my disposal.  However, I've no familiarity with MinGW so I wondered if someone can answer these questions..? They might seem a bit basic to you guys....

1)  Paths - when dealing with absolute paths, does mingw expect them to be in Windows format (with a drive letter at the start) - e.g. "C:\Documents and Settings\some_file".  Or does it favour Linux/Cygwin style paths - e.g. "/usr/local/some_file".

2)  Which of these is supported by mingw - fork() / exec() / spawn().  If not supported directly, are they supported by external libs?

3)  Does mingw support the kind of functions commonly found in unistd.h - e.g. symlink() / readlink() / unlink() etc?  Again, if not supported directly, are they supported by 3rd party libs.

Thanks,

John
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

Chris Wilson-4
Hi John,

On Wed, 27 Apr 2011, John Emmas wrote:

> I'm in the final stages of converting a large Linux app to run on
> Windows.  Through personal preference I'm building with Visual C++ but
> I'd like to keep the source code so that it's still buildable with gcc -
> whether on Linux, Cygwin, MinGW or whatever.
>
> Linux and Cygwin aren't a problem because I have both at my disposal.
> However, I've no familiarity with MinGW so I wondered if someone can
> answer these questions..? They might seem a bit basic to you guys....
>
> 1)  Paths - when dealing with absolute paths, does mingw expect them to
> be in Windows format (with a drive letter at the start) - e.g.
> "C:\Documents and Settings\some_file".  Or does it favour Linux/Cygwin
> style paths - e.g. "/usr/local/some_file".
>
> 2)  Which of these is supported by mingw - fork() / exec() / spawn().
> If not supported directly, are they supported by external libs?
>
> 3)  Does mingw support the kind of functions commonly found in unistd.h
> - e.g. symlink() / readlink() / unlink() etc?  Again, if not supported
> directly, are they supported by 3rd party libs.

MinGW, unlike Cygwin, is NOT a compatibility layer. It is a different
compiler, that's all. So the answer to all the above questions is "if and
only if it works with msvcrt.dll" and therefore "ask MSDN".

The questions that might help you more are like this:

* Does your app compile and run with the original MSVCRT C library?

* Does it use any non-standard MSVC preprocessor syntax?

* Does it use any MSVC #defines to build on Windows?

* Does it use MFC or ATL? (neither are supported using MinGW as far as I
know)

* Does it have a Makefile?

* Have you actually tried to compile it with MinGW gcc.exe instead of
cl.exe to see what happens?

* How do you deal with the lack of fork(), symlink() and readlink() when
compiling with MSVC? The same should apply to MinGW.

Cheers, Chris.

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

lrn-2
In reply to this post by John Emmas
On 27.04.2011 10:57, John Emmas wrote:
> 1)  Paths - when dealing with absolute paths, does mingw expect them to be in Windows format (with a drive letter at the start) - e.g. "C:\Documents and Settings\some_file".  Or does it favour Linux/Cygwin style paths - e.g. "/usr/local/some_file".
MinGW tools expect DOS-style paths (c:\windows\...).
Msys tools expect *nix-style paths (/c/windows/... or /usr/local/...).
Msys will watch process invocations by all Msys tools (including the
shell) and will mangle the command line, substituting *nix-style paths
for DOS-style paths (see [1] for details).
Most (IME) *nix-originated autotools-using projects can not be compiled
without using a shell, therefore some kind of Msys shell is mandatory
(not sure about non-Msys shell implementations such as zsh), which means
that path mangling will be involved. Otherwise (for projects that have
their own custom-built Windows/MinGW makefiles or that use buildsystems
capable of generating makefiles and that ship them) you might be able to
compile with MinGW only and just stick to DOS-style paths everywhere.

The programs compiled with MinGW expect DOS-style paths.
> 2)  Which of these is supported by mingw - fork() / exec() / spawn().  If not supported directly, are they supported by external libs?
fork() is not supported
exec() is supported by MS C Runtime (though there are differences
between POSIX exec() and MSVCR exec())
spawn() is supported by MS C Runtime (again, there are differences)
"MS C Runtime" here means that MinGW doesn't have to do anything to
support these, they are just forwarded to MSVCR*.
> 3)  Does mingw support the kind of functions commonly found in unistd.h - e.g. symlink() / readlink() / unlink() etc?  Again, if not supported directly, are they supported by 3rd party libs.
See [2] for a very recent discussion related to symlinks.
In addition:
Neither MinGW nor Msys tools support symlinks. Also, since both link to
msvcrt instead of msvcrtXX, they, in some cases, might not work with
symlinks transparently as you would have wanted. Or might work with
symlinks transparently as you would have not wanted.
For example:
rm -rf /somedir
will delete somedir and all of its contents. Even if /somedir is a
symlink to c:\foodir. Which means that c:\foodir will be empty after that.
Or this:
If you symlink /mingw/lib/libws2_32.a to C:\Windows\System32\ws2_32.dll
(gcc can link to DLLs directly, but this requires altering
library-finding logic; by linking ortodox library names, such as
lib/libfoo.dll.a or lib/libbar.a to actual DLLs you can have direct
linking without hacking anything), binutils might think that libws2_32.a
has size = 0, because stat() from non-symlink-aware msvcrt will say so.

Some of that changes if you compile against msys-1.0.dll, but that is
for Msys tools only, and if you want to go that far, you'd be better off
with Cygwin.

[1] http://www.mingw.org/wiki/Posix_path_conversion
[2] http://comments.gmane.org/gmane.comp.gnu.mingw.user/36205

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

John Emmas
Many thanks for that comprehensive reply.  Up until now I've assumed from various things I've read that mingw apps are closer to Windows apps whereas Cygwin apps are closer to *nix apps.  i.e. mingw apps won't support fork(), won't support symlink() etc and will tend to work with Windows style paths.  Fortunately, it looks like I've been doing the right things so far, but I thought I'd better check!

John
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

John Emmas
Of course, MinGW apps and Cygwin apps ARE Windows apps - but you probably knew what I meant....  :-)
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

John Emmas
In reply to this post by Chris Wilson-4
Thanks Chris.  That's a long list of questions so just FYI....

> * How do you deal with the lack of fork(), symlink() and readlink() when
> compiling with MSVC? The same should apply to MinGW.
>
For symlink() and readlink() I've provided my own approximations.  For fork()/exec() I've substituted spawn().  It seems like spawn() would be the correct way to go for MinGW too, although I now suspect that the app wouldn't build under MinGW for other reasons, namely....


> * Does it have a Makefile?
>

No.  The original build system was scons.


> * Does it use MFC or ATL? (neither are supported using MinGW as far as I
> know)
>
That's quite interesting...  The app I'm talking about is Ardour and I do know that others have tried building it with MinGW (unsuccessfully, from what I can gather).  It does use ATL quite extensively, so maybe that was the problem.


> * Does your app compile and run with the original MSVCRT C library?
>
No.  I'm using MSVC 8.0.  Just out of interest, why is MinGW sticking with the old CRT from MSVC 6.0?  Is it just tradition?  Contrary to popular belief, newer versions of MSVC are much more standards compliant (in certain areas, anyway - one of which is ATL).  There's still very little C99 support of course but CRT 8.0 and later are light years ahead of version 6.0.  Is that the kind of move that would benefit MinGW?  Or even be practical??

John
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

lrn-2
On 27.04.2011 14:00, John Emmas wrote:
>> * Does it have a Makefile?
> No.  The original build system was scons.
Scons works well enough with MinGW. You just have to force it to use
mingw toolchain (on Windows it will look for MSVC toolchain by default).
>> * Does it use MFC or ATL? (neither are supported using MinGW as far as I
>> know)
> That's quite interesting...  The app I'm talking about is Ardour and I do know that others have tried building it with MinGW (unsuccessfully, from what I can gather).  It does use ATL quite extensively, so maybe that was the problem.
Probably.
>> * Does your app compile and run with the original MSVCRT C library?
> No.  I'm using MSVC 8.0.  Just out of interest, why is MinGW sticking with the old CRT from MSVC 6.0?  Is it just tradition?  Contrary to popular belief, newer versions of MSVC are much more standards compliant (in certain areas, anyway - one of which is ATL).  There's still very little C99 support of course but CRT 8.0 and later are light years ahead of version 6.0.  Is that the kind of move that would benefit MinGW?  Or even be practical??
msvcrt was used because it isn't affected by XML manifests and SxS
madness, AFAIR. msvcr100 (which isn't affected by these things as well)
might be used instead in future, see [1]

[1] http://comments.gmane.org/gmane.comp.gnu.mingw.user/36183

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

John Emmas

On 27 Apr 2011, at 11:11, LRN wrote:

> msvcrt was used because it isn't affected by XML manifests and SxS
> madness, AFAIR. msvcr100 (which isn't affected by these things as well)
> might be used instead in future, see [1]
>
> [1] http://comments.gmane.org/gmane.comp.gnu.mingw.user/36183
>
That seems like it would be a useful step forward.  I hope it works out okay if the MinGW team decides to go down that route.

John
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

Tor Lillqvist
In reply to this post by John Emmas
(This response is just my educated guess, I am not a MinGW maintainer)

> Just out of interest, why is MinGW sticking with the old CRT from MSVC 6.0?

msvcrt.dll is not "from MSVC 6.0". That is just FUD. msvcrt.dll is
shipped as a new version with each version of the Windows OS, and
exists even as a 64-bit version on 64-bit Windows. If it was "from
MSVC 6.0" that would hardly be the case, would it?

>  Is it just tradition?

Partly yes, and maybe because people haven't contributed suitably
clean-room-engineered and suitably licensed headers to match the other
runtimes.

Also 1) it is "good enough" in many (most?) cases. Much of the new and
additional stuff in the newer MSVC-version-specific CRTs are, well,
compiler-specific anyway,

2 ) It makes it so much easier to distribute MinGW-built software as
you don't have to distribute a MSVC-version-specific CRT with your
software (if that would even be allowed by its license, always an
interesting question), or instruct the end-user where to get them,

If msvcrt.dll was "obsolete", why would Microsoft keep using it
themselves for stuff like notepad and other applications that are part
of the OS?

--tml

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

Chris Wilson-4
In reply to this post by John Emmas
Hi John,

On Wed, 27 Apr 2011, John Emmas wrote:

>> * Does your app compile and run with the original MSVCRT C library?
>>
> No.  I'm using MSVC 8.0.  Just out of interest, why is MinGW sticking
> with the old CRT from MSVC 6.0?  Is it just tradition?  Contrary to
> popular belief, newer versions of MSVC are much more standards compliant
> (in certain areas, anyway - one of which is ATL).  There's still very
> little C99 support of course but CRT 8.0 and later are light years ahead
> of version 6.0.  Is that the kind of move that would benefit MinGW?  Or
> even be practical??

More information about why MSVC 6.0 and MSVCRT are still popular, and the
problems with manifests and redistributables, is available here:

http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/

Cheers, Chris.

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

Keith Marshall
In reply to this post by John Emmas
On 27 April 2011 11:23, John Emmas wrote:
> On 27 Apr 2011, at 11:11, LRN wrote:
>
>> msvcrt was used because it isn't affected by XML manifests and SxS
>> madness,

That isn't the reason, at all.

See Tor Lillqvist's comment regarding your original misconception of the
relationship between MSVCRT.dll and any particular version of MSVC.

MinGW uses MSVCRT.dll because it is a fundamental component of the
operating system; therefore, its use is permitted by the GPL -- GCC, on
which MinGW is founded is a GPL tool chain.  Although you are entitled
to distribute MinGW built applications without them being constrained by
the GPL, we are not entitled to distribute non-free components as part
of the tool chain itself.

MSVCR[67891]*.dll are NOT fundamental OS components.  IIRC, they are not
even redistributable, unless you are building your code with MSVC, and
you have PURCHASED an MSVC licence from Microsoft. Thus, we CANNOT
legally (AIUI: IANAL) make MinGW in any way dependent on any of them.

>> AFAIR. msvcr100 (which isn't affected by these things as well)
>> might be used instead in future, ...
>>
> That seems like it would be a useful step forward.  I hope it works
> out okay if the MinGW team decides to go down that route.

It's hardly likely.  That would fall under the same licensing
restriction as any of the other MSVCR[6789]*.dll variants, AFAICT.

YOU are welcome to deploy code which depends on these more restrictively
licensed MSVCR*.dll variants, but the responsibility for ensuring proper
licence compliance is yours; it isn't our responsibility to police it.
If you wish to follow that path, see:

  http://www.mingw.org/wiki/SpecsFileHOWTO

(in particular, my comments below the main article).

--
Regards,
Keith.

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

Earnie Boyd
In reply to this post by lrn-2
LRN wrote:
> If you symlink /mingw/lib/libws2_32.a to C:\Windows\System32\ws2_32.dll
> (gcc can link to DLLs directly, but this requires altering
> library-finding logic; by linking ortodox library names, such as
> lib/libfoo.dll.a or lib/libbar.a to actual DLLs you can have direct
> linking without hacking anything), binutils might think that libws2_32.a
> has size = 0, because stat() from non-symlink-aware msvcrt will say so.
>

Binutils will find ws2_32.dll if you include -L c:\Windows\System32 (or
whatever the directory name is on your PC) in the link command when you
specify -lws2_32 so there is no need to create this reparse point.

--
Earnie
-- http://www.for-my-kids.com

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

lrn-2
On 27.04.2011 15:50, Earnie wrote:

> LRN wrote:
>> If you symlink /mingw/lib/libws2_32.a to C:\Windows\System32\ws2_32.dll
>> (gcc can link to DLLs directly, but this requires altering
>> library-finding logic; by linking ortodox library names, such as
>> lib/libfoo.dll.a or lib/libbar.a to actual DLLs you can have direct
>> linking without hacking anything), binutils might think that libws2_32.a
>> has size = 0, because stat() from non-symlink-aware msvcrt will say so.
>>
> Binutils will find ws2_32.dll if you include -L c:\Windows\System32 (or
> whatever the directory name is on your PC) in the link command when you
> specify -lws2_32 so there is no need to create this reparse point.
>
Would it find it have priority over libws2_32.a (or libws2_32.dll.a,
which doesn't exist, but let's suppose it does).

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

Earnie Boyd
LRN wrote:
> On 27.04.2011 15:50, Earnie wrote:
>> Binutils will find ws2_32.dll if you include -L c:\Windows\System32 (or
>> whatever the directory name is on your PC) in the link command when you
>> specify -lws2_32 so there is no need to create this reparse point.
>>
> Would it find it have priority over libws2_32.a (or libws2_32.dll.a,
> which doesn't exist, but let's suppose it does).

See http://sourceware.org/binutils/docs/ld/WIN32.html (section: "direct
linking to a dll")

It would find ws2_32.dll in the c:\windows\system32 directory first and
use that instead of the c:\mingw\lib\libws2_32.dll.a because -L
c:\windows\system32 is searched for libraries first.  Otherwise if an
import interface file exists in the directory with the DLL it will
prefer the interface file.  The library file order in the directory
search paths is as follows.  Once it finds the library the search for
the library ceases so that the first one found is used.

libxxx.dll.a
xxx.dll.a
libxxx.a
xxx.lib
<prefix>xxx.dll (*)
libxxx.dll
xxx.dll

(*) Replace <prefix> with what ever you specify with
--dll-search-prefix.  If no --dll-search-prefix is given then none is
search for.

--
Earnie
-- http://www.for-my-kids.com

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

John Emmas
In reply to this post by John Emmas

On 27 Apr 2011, at 11:00, John Emmas wrote:

> The app I'm talking about is Ardour and I do know that others have tried building it with MinGW (unsuccessfully, from what I can gather).  It does use ATL quite extensively, so maybe that was the problem.
>
Oops, how silly of me...  Ardour uses STL of course, not ATL.  I'm forever getting them mixed up!

I just took a look at the T&C's for Microsoft's Redistributable packages.  It seems that anyone is allowed to download them for personal usage but if you aren't covered by an alternative license (e.g. the one for Visual Studio) you aren't permitted to download them for commercial gain.  So MinGW is probably wise to stick with MSVCRT.dll and its contemporaries.  I guess it'll be around for some time to come but surely a day will come when Windows starts shipping without it.  Is there a case for MinGW to develop its own CRT library, rather than continuing its dependence on Microsoft?  I guess malloc() and stuff would be quite difficult without some reliance on Microsoft's CRT?

John
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

Earnie Boyd
In reply to this post by John Emmas
John Emmas wrote:
>> * Does it use MFC or ATL? (neither are supported using MinGW as far as I
>> know)
>>
> That's quite interesting...  The app I'm talking about is Ardour and I do know that others have tried building it with MinGW (unsuccessfully, from what I can gather).  It does use ATL quite extensively, so maybe that was the problem.
>

I suggest you search the net for mingw+atl.  OpenOffice for instance
deals with the lack of ATL in MinGW.  And I find attempts to port WTL, a
ATL drop-in replacement, to MinGW.

--
Earnie
-- http://www.for-my-kids.com

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

lrn-2
In reply to this post by John Emmas
On 27.04.2011 18:43, John Emmas wrote:
> Is there a case for MinGW to develop its own CRT library, rather than continuing its dependence on Microsoft?  I guess malloc() and stuff would be quite difficult without some reliance on Microsoft's CRT?
On Dec 29 2010 in #mingw-w64 @ irc.oftc.net i've had this conversation
(not a quote, slightly edited typos and conversation flow):

* vityan * I have plans to make more real-libc for Mingw-W64 and will
base it upon FreeBSD's libc 7.0 runtime library code due to its
license(and quite good functionality).
* NS_mb * look at ironcrate in our repo
* NS_mb * Kai started on a libc for windows
* NS_mb * afaik, from scratch
* vityan * Hmmm... I see - it's almost empty
* LRN * You can easily get libc routines that work with strings, math
and stuff from other OSes. But I/O, processes and other things are
OS-dependent, you'll have to re-implement all that on top of WinAPI
and/or Native API
* LRN * Because on Linux libc will often just make a syscall - and that's it
* vityan * LRN - most of the stuff(stdio,buffer copying and other) can
be written in C/asm. OS related stuff(mainly *NiX syscalls) will be
replaced by Native NT API. I'll avoid Win32 API in my libc
* vityan * I also plan to provide native fork which is not part of MS C
runtime nor the Win32 API.
* LRN * Well, good luck. I'll certainly appreciate a free-software C
runtime library for NT
* NS_mb * vityan: feel free to contribute to ironcrate :)
* vityan * As ironcrate is almost empty it's more willing to continue on
my wlibc :D
* vityan * My base is BSD's libc so it will progress my better(lots of
stuff already present under liberal license)
* vityan * I hope i'll not need to use init code from... libcmt sources :(
* vityan * iconv should be integrated into libc to provide independent
locale support
* vityan * in will be one libc.dll library
* vityan * + libm.dll and possibly ported libdl
* vityan * Main goal is to implement basic libc with support to all
funcs included in latest MSVCR runtime. Later various devs can be
interested in extending it and adding some POSIX stuff as OPTIONAL
extension.
* vityan * Posix extension will allow creation of cygwin64/msys64 based
on it but that will not happen any time soon(and i'm quite limited in
time actually)

for Ironcrate see [1]

Haven't heard about this from him since. But he's still around (last
seen ~2 weeks ago).

Also, some years ago (don't remember the date) i've asked a ReactOS dev
.... KJK::Hyperion, if i remember correctly, about CRT, and he said that
ReactOS will have to implement its own C Runtime eventually. Obviously,
no one knows when that "eventually" will be.


It should be noted that MinGW cites its reliance on msvcrt as an
advantage (links to msvcrt, which is already available, as opposed to
Cygwin, which dooms applications to carrying cygwin-1.dll around). Not
sure if they will gladly give it up.

[1]
http://sourceforge.net/apps/trac/mingw-w64/wiki/libw64crt%20Documentation

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

Earnie Boyd
In reply to this post by John Emmas
John Emmas wrote:
> I just took a look at the T&C's for Microsoft's Redistributable packages.  It seems that anyone is allowed to download them for personal usage but if you aren't covered by an alternative license (e.g. the one for Visual Studio) you aren't permitted to download them for commercial gain.  So MinGW is probably wise to stick with MSVCRT.dll and its contemporaries.  I guess it'll be around for some time to come but surely a day will come when Windows starts shipping without it.  Is there a case for MinGW to develop its own CRT library, rather than continuing its dependence on Microsoft?  I guess malloc() and stuff would be quite difficult without some reliance on Microsoft's CRT?

They would have to rewrite the whole of the Windows API to get rid of
MSVCRT.DLL.  I don't think they would think it wise to do that.  It sure
makes no business sense.  MSVCRT.DLL is not the old CRTDLL.DLL and
rather stands for MicroSoft Visual C RunTime which can be any version of
Visual C distributed with the OS Version.  The newer the OS the newer
the MSVCRT version is used.  For an interesting read take a look at the
output of ``objdump -x $SYSTEMROOT/system32 | less''.

--
Earnie
-- http://www.for-my-kids.com

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

Earnie Boyd
In reply to this post by lrn-2
> On 27.04.2011 18:43, John Emmas wrote:
>> Is there a case for MinGW to develop its own CRT library, rather than continuing its dependence on Microsoft?  I guess malloc() and stuff would be quite difficult without some reliance on Microsoft's CRT?

No, it isn't our purpose.  However, if you find an alternative you can
use it instead.  Keith has already pointed to a wiki document on
changing the GCC specs file.

--
Earnie
-- http://www.for-my-kids.com

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Some MinGW basics

lrn-2
In reply to this post by Keith Marshall
On 27.04.2011 15:13, Keith Marshall wrote:

> On 27 April 2011 11:23, John Emmas wrote:
>> On 27 Apr 2011, at 11:11, LRN wrote:
>>
>>> msvcrt was used because it isn't affected by XML manifests and SxS
>>> madness,
> That isn't the reason, at all.
>
> See Tor Lillqvist's comment regarding your original misconception of the
> relationship between MSVCRT.dll and any particular version of MSVC.
>
> MinGW uses MSVCRT.dll because it is a fundamental component of the
> operating system; therefore, its use is permitted by the GPL -- GCC, on
> which MinGW is founded is a GPL tool chain.  Although you are entitled
> to distribute MinGW built applications without them being constrained by
> the GPL, we are not entitled to distribute non-free components as part
> of the tool chain itself.
>
> MSVCR[67891]*.dll are NOT fundamental OS components.  IIRC, they are not
> even redistributable, unless you are building your code with MSVC, and
> you have PURCHASED an MSVC licence from Microsoft. Thus, we CANNOT
> legally (AIUI: IANAL) make MinGW in any way dependent on any of them.
These are the terms for MSVCR100 (partially, open up vcredist_ARCH.exe
in 7zip to find the whole EULA):
You may not
• disclose the results of any benchmark tests of the software to any
third party without Microsoft’s prior written approval;
• work around any technical limitations in the software;
• reverse engineer, decompile or disassemble the software, except and
only to the extent that applicable law expressly permits, despite this
limitation;
• make more copies of the software than specified in this agreement or
allowed by applicable law, despite this limitation;
• publish the software for others to copy;
• rent, lease or lend the software;
• transfer the software or this agreement to any third party; or
• use the software for commercial software hosting services.

Well, you can't redistribute vcredist without a special license, but
that's old news. Downloading it from MS is a burden, but not an obstacle.
All other terms do not apply (directly) to MinGW, as far as i've been
able to learn (IANAL, obviously, but regarding 'commercial software
hosting' there was an answer on MS forum from MS employee, and it says
that this youmaynot refers to redistribution).

As for GPL restriction on not using proprietary components - except when
they are normal part of the OS, here's what is in GPLv2 on this:
...need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.

GPLv3:
The "System Libraries" of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
"Major Component", in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it.

For reference:
Windows 7 Ultimate x86 comes with these pre-installed:
msvcr90 (SxS)
msvcr80 (SxS)
msvcrt40
msvcrt40 (SxS)
msvcrt20
msvcrt20 (SxS)
msvcrt
msvcrt (SxS)
Updates (even SP1) don't seem to bring anything newer (although "newer"
here is msvcr100, which will probably only come in with SP2 or Windows 8)

Windows XP Pro SP3 comes with these pre-installed:
msvcrt40
msvcrt20
msvcrt
msvcrt (SxS)
MSVCR70 (not pre-installed, but it comes with .NET 1.1, which is bundled
on XP Pro CD, not sure if that counts).
Updates (updates only, no new IE or tools) will bring you:
msvcr71 (as part of .NET 1.1 SP1 update, i think)

And, of course, you'd get all relevant versions of msvcrXX with any of
MS compiler suites. So, obviously, msvcrXX doesn't qualify as a system
library neither by GPLv2, nor by GPLv3 standards.

Although IANAL.

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe