#92217 - Henochius - Wed Jul 12, 2006 3:12 am
Hello, I have recently downloaded DevKitARM 19a, it is able to parse my sources OK but then when it finishes I get:
collect2: CreateProcess: No such file or directory
and the .ELF file is not created. This seems to happen on the example sources too.
Does anyone know what this error message means? There's seems to be no documentation available for DevKitARM, it would be good if the developers of it had seen fit to at least provide an explanation of the error codes...!
Thanks.
#92231 - wintermute - Wed Jul 12, 2006 6:08 am
#93122 - Henochius - Mon Jul 17, 2006 2:16 am
Installed MSYS and put it first in the path; the error still occurs though.
#93123 - wintermute - Mon Jul 17, 2006 2:20 am
#93125 - Henochius - Mon Jul 17, 2006 2:27 am
c:\e\gba\arm
#101415 - Henochius - Tue Sep 05, 2006 7:31 am
Reinstalled Windows completely, reinstalled latest DevKitPro using the automatic installer, tried compiling, still the same old shit.
Is this bug ever going to be fixed or what?
#101427 - Optihut - Tue Sep 05, 2006 12:10 pm
Are you able to compile the examples? Some general advice about devkitpro can be found in this thread.
#101429 - gmiller - Tue Sep 05, 2006 1:34 pm
I assume that the msys is installed in a location that has no spaces in it as well. I have students install this stuff every month and I see errors like this when either the location is bad (spaces in the path) or the environment variables are not correct. I will post mine from my laptop later.
#101435 - Henochius - Tue Sep 05, 2006 2:27 pm
There's no spaces in any of the paths, so we can safely rule that out.
As for the environment variables, maybe they are the problem, but aren't they supposed to be set up automatically by the installer?
#101461 - gmiller - Tue Sep 05, 2006 7:22 pm
I do not think the environment variables get their by default bit my class uses a custom installer because of needing a fixed "tested" release each class.
Here are my environment variables:
| Code: |
DEVKITARM /c/devkitPro/devkitARM
DEVKITPPC /c/devkitPro/devkitPPC
DEVKITPRO /c/devkitPro
DEVKITPSP /c/devkitPro/devkitPSP
PATH c:\devkitPro\msys\bin;(more ...)
|
Just remember that the "/" is used in the DEVKIT ones and the "\" is used in the PATH.
This may not help but it should confirm the setup ...
#101716 - Henochius - Thu Sep 07, 2006 4:56 pm
Still no joy :-( <sigh>
> "make"
> Failed to create process: The operation completed successfully.
> Process Exit Code: 0
> Time Taken: 00:00
The examples in the other thread seem to be for DS, I'm developing for GBA, so is it still relevant (the thread I mean, not the GBA :-) ?
#101733 - gmiller - Thu Sep 07, 2006 8:01 pm
try looking at the path variable at the prompt one of these two should show it to you:
or
you can see from the "msys" command prompt where it finds make by doing this:
| Code: |
gmiller@GD ~
$ type make
make is /bin/make
gmiller@GD ~
$
|
Are you doing this development under Windows?
BTW: I am targeting GBA currently so our targets are the same.
#101977 - Henochius - Sat Sep 09, 2006 1:06 pm
>Are you doing this development under Windows?
Yes, until there is an AmigaOS version available.
PATH=C:\E\GBA\DKP\MSYS\BIN;C:\WINDOWS\C:\WINDOWS\COMMAND;
MSys doesn't work (so I can't try what you suggested), I get "Cannot find rxvt or sh.exe binary -- aborting".
<rant>
I don't understand WHY these paths should even be necessary? That sort of crap was left behind in the 1980s. It means the program can't be as easily installed, moved or uninstalled, it means you can't have spaces in the pathname, etc. Why does it need all these UNIX crapplets anyway?? Why hasn't it been ported properly? it seems to be only "half-ported" if it needs all this legacy UNIX stuff just to compile a straightforward C program.
What's wrong with using relative paths!? Or even looking in the current directory for this stuff would be better than this kind of foolishness!!
I have used various compilers and none of them have ever required half this much nonsense.
</rant>
#101980 - gmiller - Sat Sep 09, 2006 2:13 pm
The path to it can not have and spaces in it either and that location is where make and some of the other general tools are located. The PATH is used by windows for all kinds of things and not just microslop tools. The PATH on my machine is pretty long and changing it would break all kinds of other code. The PATH just tells the order and places to search for utilities. If the msys install modified your path automaticly you would not even know about the need. If you want to see things break try moving product directories in "Program Files" and see what happens. There are lots of absolute directories for tools and such but user code can be relative from a fixed point or just relative from the current working directory.
| Code: |
C:\Documents and Settings\gmiller>echo %PATH%
C:\Program Files\Intel\VTune\CGGlbCache;C:\Program Files\Intel\VTune\Shared\Bin;
C:\Program Files\Common Files\Intel\Shared Files\IDVC;C:\Program Files\Intel\VTu
ne\Analyzer\Bin;c:\devkitPro\msys\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\
System32\Wbem;C:\Program Files\ATI Technologies\ATI.ACE\;c:\Program Files\Micros
oft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\
C:\Documents and Settings\gmiller>
|
Your make utility and rxvt should be in your msys/bin directory. Since there is a mixture of case sensative and case insensative searching going on I suggest making the cases match exactly in the PATH variable.
#101994 - tepples - Sat Sep 09, 2006 4:55 pm
Despite what wintermute recommends, I don't use MSYS's shell with devkitARM r19b. I just do it the old fashioned way that I've been using since devkitPro r8: use a batch file to put devkitPro, MinGW, and MSYS at the head of my PATH
| Code: |
@echo off
set DEVKITARM=/c/devkitPro/devkitARM
set DEVKITPRO=/c/devkitPro
set PATH=C:\devkitPro\devkitARM\bin;E:\mingw32\bin;C:\devkitPro\msys\bin;%PATH% |
and then call make from the Windows Command Prompt.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#101995 - gmiller - Sat Sep 09, 2006 4:57 pm
I use VisulHam or VS2005, but when those do not work I use msys to check.
#102045 - wintermute - Sun Sep 10, 2006 4:54 am
| Henochius wrote: |
PATH=C:\E\GBA\DKP\MSYS\BIN;C:\WINDOWS\C:\WINDOWS\COMMAND;
MSys doesn't work (so I can't try what you suggested), I get "Cannot find rxvt or sh.exe binary -- aborting".
|
That suggests a problem with your mys installation, both rxvt.exe & sh.exe should be found in the msys/bin folder.
The path you show here is messed up, there should be a semi-colon after the first c:\windows\ part. That may actually be the source of all your problems.
| Quote: |
I don't understand WHY these paths should even be necessary? That sort of crap was left behind in the 1980s.
|
Huh? So why is there still a path which points to windows components if it was left behind?
| Quote: |
It means the program can't be as easily installed, moved or uninstalled, it means you can't have spaces in the pathname, etc. Why does it need all these UNIX crapplets anyway?? Why hasn't it been ported properly? it seems to be only "half-ported" if it needs all this legacy UNIX stuff just to compile a straightforward C program.
|
The gnu compiler collection happens to be primarily a unix toolchain and there's been quite a lot of work done by many people to enable it to run in a native windows environment. There are several thousand people using the devkitPro toolchains with none of the problems you seem to be experiencing.
| Quote: |
What's wrong with using relative paths!? Or even looking in the current directory for this stuff would be better than this kind of foolishness!!
I have used various compilers and none of them have ever required half this much nonsense.
</rant> |
Funny, almost every compiler I've ever used has required paths to be set.
Open a dosbox and paste the output of the set command.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#102821 - Henochius - Sun Sep 17, 2006 7:27 am
>Huh? So why is there still a path which points to windows components if it was left behind?
For legacy compatibility with the DOS command line. I've never seen any application that requires it. And I've installed hundreds.
>The gnu compiler collection happens to be primarily a unix toolchain and there's been quite a lot of work done by many people to enable it to run in a native windows environment. There are several thousand people using the devkitPro toolchains with none of the problems you seem to be experiencing.
Well, I used your installer and it didn't work. So there is clearly a bug. Maybe it doesn't affect all users but it certainly affects some. I have noticed other threads with similar issues. So to say "several thousand" people are using it doesn't mean it is bug-free, it seems there is a substantial number who CANNOT use it because of the buggy installer. Or whatever the problem is.
And the work of "many people" doesn't seem to have resulted in a proper Windows port, if it still needs all this half-assed UNIX crap.
>What's wrong with using relative paths!? Or even looking in the current directory for this stuff would be better than this kind of foolishness!!
How hard would it be to change it to do this? Surely it would be trivial.
>Funny, almost every compiler I've ever used has required paths to be set.
None I have ever used have required it. Including some that were even based on gcc, eg. StormC.
#102844 - Two9A - Sun Sep 17, 2006 10:16 am
Could I suggest the following. If you're such an expert in Windows toolchain development that changing the code to your liking would be trivial, do it. It's opensource, after all.
#102861 - tepples - Sun Sep 17, 2006 2:49 pm
I could get GCC to work from the Windows Command Prompt with no PATH changes but with a rewritten makefile, unless a rewritten makefile is considered taboo.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.