[Coco] making nitros9 on MinGW
William Astle
lost at l-w.ca
Thu Jul 18 23:25:55 EDT 2013
This might be a case of a 64 bit windows behaving different than a 32
bit windows. You get some weird results if you install 32 bit software
on a 64 bit windows - things like binaries going into "C:\Program Files
(x86)" or some such.
It could also be that the wrong version of hg is installed, or a broken
version of it.
It's probably safe to just do:
PATH="/usr/local/bin:/mingw/bin:/bin:$PATH" - duplicate entries in the
PATH variable shouldn't be a problem and whatever is in the windows
directories probably isn't going to collide. Doing it that way forces
the mingw file system paths to the start of the PATH while keeping
everything else that was in there before.
Note that "export" isn't needed because PATH is already exported (or at
least it should be).
On 2013-07-18 17:57, Aaron Wolfe wrote:
> On Thu, Jul 18, 2013 at 7:36 PM, Bill Pierce <ooogalapasooo at aol.com> wrote:
>>
>> Aaron,
>> I followed your instructions to the "t".
>> Once I enter:
>>
>> export PATH="/usr/local/bin:/mingw/bin:/bin:/c/Windows/system32:/c/Windows:/c/ProgramFiles/Mercurial"
>>
>
> is there really a space between Program and Files in your path? there
> should be.
>
>> and then:
>>
>> hg clone http://lwtools.projects.l-w.ca/hg/lwtools
>>
>> I get:
>>
>> hg.exe - Entry Point Not Found
>> The procedure entry point wcsncpy_s could not be located in the dynamic link library ntdll.dll
>>
>> Each cmd was copied and pasted direct from your instructions in the wiki.
>>
>> So what is my problem?
>>
>
> Unknown. The guide is a work in progress and I appreciate knowing it
> did not work. I have followed the process on a clean (vm) Win8 and an
> XP machine so far and both worked fine, but that doesn't even begin to
> cover every possible configuration.
>
> Does typing 'hg' at a regular DOS prompt (cmd.exe) work?
>
> What is the path in a brand new MinGW shell before changing it? To
> see type: echo $PATH
>
> The reason we change the path at all is that MinGW by default puts '.'
> (the current directory) as the first path entry. This mimics
> Windows/DOS behavior, but it breaks unixy things like the NitrOS9
> build process. make gets all kinds of crazy if current dir is at the
> head of the path and you try to build 6809 binaries with the names of
> common unix tools :)
>
> Let's figure it out and improve the guide
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
More information about the Coco
mailing list