Web lists-archives.com

[Mingw-msys] [mingw - MSYS] missing networking on new install

On Mon, Jun 11, 2012 at 1:39 PM, Damon Register
<damon.w.register@xxxxxxxx> wrote:
> On 6/7/2012 1:11 PM, Earnie Boyd wrote:
> That wasn't really my goal. ÂMy ultimate goal is to create my own
> uname function using Windows methods as you suggested.

Then you need to be in a MinGW build environment to provide that
function and not an MSYS build environment.

> Sure, that is the ultimate goal. ÂI still would like to know, is it not true
> that the current uname.exe provided by msys is built with the msys
> toolset? ÂSince I have been able to rebuild msyscore and coreutils,
> using the msys environment, I have to conclude the answer is yes.

The uname.exe program provided by MSYS depends on the MSYS runtime
which implements the uname() function.

> Â>> Can you please tell me what I would have to do to the coreutils makefile to make it
> Â>> link to the library containing GetEnvironmentVariable?
> Â>
> Â>Yes, GetEnvironmentVariable is a Windows API and which isn't intended
> Â>to be used with the MSYS/Cygwin runtime. ÂHowever, the emulation must
> Â>use it so there are special instructions for adding the appropriate
> Â>libraries when MSYS itself is built.
> So would I be correct in understanding that it is built into the
> runtime app like uname.exe but not available for linking into my
> own app?

As stated previously uname.exe depends on the MSYS runtime so uname()
function is given.  The MSYS runtime depends on some of Windows API
and uses LoadLibrary/GetProcAddress to provide those functions.

> What are those special instructions? Âhow do I link to get that
> GetEnvironmentVariable function available to coreutils, specifically
> to the uname.c ? ÂCome to think of it, if my goal is supposed to be
> to create a new uname.exe using windows methods, wouldn't I need
> access to windows functions such as GetEnvironmentVariable?

Again, MSYS provides GetEnvironmentVariable to itself via
LoadLibrary()/GetProcAddress().  The coretuils uname.c depends on the
MSYS runtime to provide the functions it needs.

> Â>I think your best bet will be to port ghostscript to windows methods.
> Â>I think that it has been done already, maybe you just need to follow
> As far as Ghostscript goes, you are probably right. ÂAt this point I just
> hate admitting defeat on the uname side. ÂI would really like to know
> how to make coreutils link with GetEnvironmentVariable such that I can
> do some tampering to get a uname.exe that does what I want and in the
> process I hope to learn enough of how it works to be able to port it to
> a regular windows app that can be built with mingw environment.

A native uname.exe is most likely doable but you'll need to be in a
MinGW build environment to create one.

-- https://sites.google.com/site/earnieboyd

Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Mingw-msys mailing list