CHDK Forum
CHDK Development => General Discussion and Assistance => Topic started by: Microfunguy on 17 / November / 2012, 18:32:35
-
In order to speed-up batch compiling, I have copied the pre-built compiling environment and my own project files to two faster PC's, one WinXP Pro SP3 and the other Win7 Home Premium.
I get the same problem with both.
However, to make the test less dependent on the project files on each PC, I have also tested with the files on a mini USB drive, to no avail.
The Makefile is far older than the CHDK version but works fine and is attached.
With the USB drive, topdir = H:\SDM_1.86_Mercurial
For convenience, I run from a BAT file in which I have "gmake PLATFORM=s95 PLATFORMSUB=100k fir".
The first operation is 'version' and it responds with :-
**** Build: 148
i was unexpected at this time
gmake: ***[all-recursive] Error 255
The 'clean' command then runs and issues the same error.
If I connect the USB drive to my other WinXP PC and run the BAT file everything works fine.
Any ideas ?
David
-
the BUILD_NUMBER variable some how has ended up with a newline in it?
-
version.inc contents have certainly been changing for some reason.
Sometimes everything appeared between inverted inverted commas, other times the version number disappeared.
Not sure why the BUILD_NUMBER is then echo'd back to version.inc.
Maybe a long time ago there was an option to increment build number that I removed.
Regardless,it works on other PC's.
I copied the pre-built environment folder to my DropBox and then copied from there on the other PC's.
I will try copying via a mini USB drive instead.
-
Using a hex editor, I make sure the version.inc entry ends with 0x0A.
Running the BAT fails as above, BUILD_NUMBER displayed is empty.
In addition, version.inc has increased in size by one byte ... a carriage return (0x0D) has been inserted before the 0x0a.
EDIT
Even when I remove the line that echo's to version.inc, it fails at the point where it displays BUILD_NUMBER.
It fails to detect BUILD_NUMBER.
Can it be anything to do with file permissions ?
-
version.inc is just a plain text file and whether it ends in newline or carriage-return+newline shouldn't make any difference... I don't think it's failing in 'version'. If your BAT file is not just the gmake one-liner, it might have something relevant.
Compare the output of 'path' on the working and non-working machines to see if there's a difference.
-
If your BAT file is not just the gmake one-liner, it might have something relevant.
@microfunguy : I was wondering that too - can you post your batch and makefile.inc files?
Compare the output of 'path' on the working and non-working machines to see if there's a difference.
You might even go one step farther and compare the output of "set" to see if any environment variable are different ?
-
See post below.
-
SUCCESS !
The path to the gcc\bin folder was \gcc\bin\
It now works.
EDIT
But not with the faster Win 7 machine.
zsh fails on nearly every operation.
-
I believe the old gcc3 pre-built environment has never worked on vista or later. You can get a working gcc4 environment from chdkshell.
edit:
btw, if compile speed is your only concern, you will find linux much faster than windows, even on lower spec hardware or in a VM on the windows box. For example, my lowly 1.8ghz amd athlon laptop running linux builds faster than my win7 sandy bridge i5 desktop. Of course, setting up the build environment is likely to be a lot more work...
-
You can get a working gcc4 environment from chdkshell.
I installed it and tried doing the A620 100f build but it gave problems.
It tried to use the old 'zsh' (renamed by GrAnd to 'sh') but zsh is unstable on Win 7 and 64-bit is not supported anyway.
So, I try installing the following simply to get the bash.exe executable :-
https://github.com/bmatzelle/gow/issues/59
Even though in makefile.inc I set SH = bash, sh.exe (zsh) was used.
So, I renamed it sh.exe and when it got to the 'which' command :-
SORT := $(dir $(shell which uniq.exe | sed 's_$(OLDSEPARATOR)_$(NEWSEPARATOR)_g'))/sort.exe
it simply displayed usage information an endless number of times.
if compile speed is your only concern
you will find linux much faster than windows
Hmmmm .. I sense a LOT of pain.
I may try it, I know someone who is quite expert with Linux and only yesterday suggested I install it.
For now, I just want to get gmake working with bash.exe.
-
It tried to use the old 'zsh' (renamed by GrAnd to 'sh') but zsh is unstable on Win 7 and 64-bit is not supported anyway.
To use the chdkshell gcc4 toolchain on win7, you just need your path set appropriately to not pick up the bad sh. I do most of my development like this. In my setup, this means having D:\chdk\chdkshell\gcc4\bin at the front of the path
sh --version gives
GNU bash, version 3.1.0(1)-release (i686-pc-msys)
-
sh --version gives
GNU bash, version 3.1.0(1)-release (i686-pc-msys)
I do get that but when I compile I get errors :-
========== D:\CHDKSHELL\TRUNK\TRUNK300\BIN\LOGS\ERR-A620-100F.TXT ==========
arm-elf-gcc: Wl,--start-group: No such file or directory
arm-elf-gcc: Wl,--end-group: No such file or directory
D:\CHDKSHELL\gcc\bin\gmake.exe[1]: *** [main.elf] Error 1
gmake: *** [all-recursive] Error 1
If I type gmake from a command line I get :-
arm-elf-gcc.exe:CreateProcess:No such file or directory.
-
I'm not sure if it's relevant, but you are still using gmake.exe from the gcc3 binaries. I would suggest removing that from your path completely.
-
Well, I restarted the PC to make sure PATH was updated, not sure if you have to do that with Win7.
chdkshell still gives the error and in addition it was paused by Avast anti-virus popping up to say that cc1.exe did not seem to be malicious.
So, I changed the path to \gcc\bin to use 3.4.6.
Remember, my Makefiles have not been updated in any way for later gcc versions.
Entering gmake from command line resulted in ubasic, math and font libraries being built but it then failed on stubs_entry.s reporting unexpected end-of-file.
I have compared it with the copy on my normal-work PC and it is identical.
-
Well, I restarted the PC to make sure PATH was updated, not sure if you have to do that with Win7.
You can just set the path in the particular command prompt window you are working it, no need to mess with the system path or reboot.
chdkshell still gives the error
I was not suggesting you use chdkshell. Rather, I was suggesting you should use the gcc4 toolchain it includes.
So, I changed the path to \gcc\bin to use 3.4.6.
To the best of my knowledge no one ever got this toolchain to work correctly on vista and later. That is one of the primary reasons chdkshell started including gcc4
-
I was not suggesting you use chdkshell. Rather, I was suggesting you should use the gcc4 toolchain it includes.
OK, I will follow-up on that 'tomorrow' as the PC is now downloading the 750 MB Ubuntu ISO.
Then I will get VirtualBox.
-
OK, I will follow-up on that 'tomorrow' as the PC is now downloading the 750 MB Ubuntu ISO.
Then I will get VirtualBox.
I have a copy of the tool chain used in the autobuild (props to hacki). All it took was the appropriate changes to the PATH variable to point at the toolchain first to make it "just work" under Linux. Let me know if you want to use that ?
-
All it took was the appropriate changes to the PATH variable to point at the toolchain first to make it "just work" under Linux. Let me know if you want to use that ?
Many thanks, that will avoid most of the pain.
-
I was not suggesting you use chdkshell. Rather, I was suggesting you should use the gcc4 toolchain it includes.
OK, I am now doing that and on entering the gmake command I get the error reported in previous post after stubs_entry.S :-
/bin/sh: -c:line 1:
syntax error: unexpected end of file
The line ending is 'line feed' (0x0A) as expected.
-
The fact that the error comes from sh means the error is in the command passed to sh (presumably by make or one of the commands invoked by make) not in stubs_entry.S itself.
As an off the top of my head guess, it might be something to do with line ending styles. The CHDK svn is set to keep all the makefiles in unix (LF only). The tools included with the different toolchains may affected differently by varying line endings.
-
/bin/sh: -c:line 1:
syntax error: unexpected end of file
Make sure the last line of stubs_entry.S also has the proper 0x0A line ending.
hth,
wim
-
Make sure the last line of stubs_entry.S also has the proper 0x0A line ending.
It does and there is not a single occurence of 0x0D 0x0A in the file.
I am not generating this file, it already exists.
David
-
@Microfunguy
My regular gcc 4.5.1 toolchain (prebuilt from the CHDK-DE (http://forum.chdk-treff.de/download_chdkde.php) site) is able to compile the SDM 1.85 source after replacing a few backslashes in some #include directives.
To build, I'm using a command line like this: env PATH=~/bin/arm-elf451/bin:$PATH make fir, so I can choose a certain toolchain by modifying PATH on the command line. This assumes that the prebuilt archive is unpacked into the bin subdirectory inside HOME.
-
I can choose a certain toolchain by modifying PATH on the command line.
Thanks, I was hoping to try that today but have been pre-occupied trying to install OSX Snow Leopard in VirtualBox on a 64 bit AMD PC .. so far without success.
-
[Thanks, I was hoping to try that today but have been pre-occupied trying to install OSX Snow Leopard in VirtualBox on a 64 bit AMD PC ..
Really ? Why ? I thought you were working on getting a linux distro running on Vbox to increase your build speed ?
-
I thought you were working on getting a linux distro running on Vbox to increase your build speed ?
I am.
The Linux distro installed fine.
For some reason, when I change directory to my SDM project files and type command 'make PLATFORM=s95 PLATFORMSUB=100k fir' it cannot find arm-elf-gcc.exe despite path in rc.local starting '/home/build/toolchain/bin'.
I will try adding path to bash.rc (I think) or typing directly as suggested by srsa_4c.
In addition, I still need to fix the 'unexpected end of file' with stubs_entry.s on Windows 7.
-
For some reason, when I change directory to my SDM project files and type command 'make PLATFORM=s95 PLATFORMSUB=100k fir' it cannot find arm-elf-gcc.exe despite path in rc.local starting '/home/build/toolchain/bin'.
what do you see if you type the following on the command line (case matters) ?
echo $PATH
I will try adding path to bash.rc
.bashrc
...or typing directly as suggested by srsa_4c.
PATH=/home/build/toolchain/bin:$PATH
-
what do you see if you type the following on the command line (case matters) ?
echo $PATH
Setting PATH from the command line, that now reports the required path.
On running make, subdirectories tools,lib and lib/font give error 'unterminated quoted string'.
That seems to be at arm-elf-gcc 2:
Trying to compile CHDK gives similar error messages.